From Facebook Developer Wiki

[edit] No support for .ico?

There seems to be no support for .ico format. Facebook image caching will replace any .ico with empty spacer .gifs.

[edit] Size limits?

Anyone else had problems with size limits for <img> srcs?

I tried using a file on my (slow) server. It was only 40,874 bytes, not big. I tried recompressing to 30kb, this didn't help.

Making it more lossy, I managed to squeeze it to 5kb, and it worked. (Ironically when facebook displays the picture using its servers, it is 30kb!)

Is there a known size limit? Or is it just a server timeout? I'm serving my test page from a dialup connection! So it's quite slow!

Anyway, I might experiment to try to find a limit. Just letting others know.876395601 22:25, 31 July 2007 (PDT)

(I have had success with imgs of 9.8kb and 19.7kb so far).

hmm, according to FB, isn't the limit 5MB?

[edit] Dynamic Images

For my application (a game) I've been dynamically generating PNG images (the current board). The URL for the image is something like app.py/board?id=73&move=2. Although I send back the right data from my server, the image arrives back at my client GZIPped and undisplayable. My hypothesis is that Facebook is running Apache with mod_deflate and mod_deflate is compressing the image because it can't identify it as an image. The only way I've been able to make this work is to change my URL to /board_73_2.png and go direct to my server rather than through Facebook. I suspect that if I took out the .py I could go to app/board_73_2.png through the Facebook server. I don't know enough about mod_deflate to know whether it can be configured to compress based on the MIME type rather than on the URL.

Did you try explicitly setting the content type? I dont know how it works for Python, but in PHP I write:

header('Content-Type: image/png');

682630665 06:24, 14 July 2008 (PDT)

I find that dynamic images are working for me, but I ran into a different issue. Sometimes my dynamic images were not generating on the profile, and instead rendered as a safe_image.php that was 1px by 1px. The GET parameters that I passed in the image source were the culprit. Instead of putting & (ampersands) to delimit GET parameters, put &amp; (HTML ampersand entity) instead. Example:

--Konr Ness 14:11, 12 May 2008 (PDT)

[edit] Image Maps

It seems image maps aren't allowed. It's not obvious to me why that would be. It'd be very convenient to designers of games if they were. I guess Facebook would need to go through and rewrite all the URLs, but that can't be too hard?

[edit] About cachebreakers

To FB staff: There wouldn't be a need for cachebreakers if you gave us the option for images not to be automatically cached on the profile. What's your incentive in not letting us serve the profile box images from our servers? Are you just concerned about time to load these images being inferior to what you can achieve with cached ones? If that's the case, then you've just seen the amount of overhead caused by not letting app developers have images on the profile served from their hosting. Let developers have images on the profile box that don't go through your caching process and I bet you most of the "abuse" problems you've seen with cachebreakers and the like will go away.

To FB staff II: i'm sorry to say that article conveys no new infomration and no practical solution. The problem is that your image caching code is badly broken, seems to be written without understanding of image processing. In no particular order

1. severe bugs in recognizing GIF/PNG transparency, with background painted into ugly black
2. cached images disappear for no apparent reason, and repeated refershImgSrc()are not bringing them back.
3. GIFs loose all animations AFTER going to storage server (they are fine via safe_image.php)
4. severe and UNNECESARY quality loss on force caching PNGs into GIFs. please read up on Quantization or just use something out of the box
5. stripping out IE "filter" CSS extension on images, makes PNGs unsupportable for IE6

While theoreticaly image caching layer is nice idea for loadbalancing and secuirty, what you practically have today is some sort of cruel application vandalizer. no wonder everybody is inventig tricks to prevent their apps from being vandalized by this "caching".

I'm guessing Facebook doesn't allow images to be served to profile pages direct because the app owner could track which IPs are visiting which profiles.

[edit] To Facebook Staff III

Apart from the reasons already mentioned, there's another valid reason why a developer may not want an image to be cached. In leiu of full javascript support inside of FBML, some web analytics packages support tracking user activity via small transparant images that ping a URL on the tracker's server when loaded. The Facebook image cache renders this kind of tracking completely useless however, and further, none of the benefits of caching that are described apply in this case (the developer *wants* the hit to his server every time a user views the page, there is no visible image actually being shown to the user so it doesn't matter if the cache behaves correctly, etc.).

The tracking thing is doubly important right now, given that the app-stats provided by Facebook are currently buggy and sporadic at best, so the platform shouldn't be doing things that render it impossible. I think at the very least, there should be a <fb:nocache> tag that developers can elect to use, where any content placed between <fb:nocache> and </fb:nocache> is not ever cached, regardless of whether or not it normally would be.

[edit] give it up

they're not going to give it to you... if they allow uncached images in profiles then we could make tracking applications and this creates a privacy concern. give it up, you're wasting your time.

--11523240 19:41, 17 April 2008 (PST)

[edit] Cache refresh code doesn't work.

According to the wiki page:

"Facebook's cache of images will show a blank image if there is a problem. You can request your image be recached by using the following query. facebook.fbml.refreshImgSrc('imgURL')"

Translating this to PHP's OO notation, we get:

$facebook->fbml->refreshImgSrc('http://example.com/test.jpg');

On executing this line in my PHP file through Facebook's server, I get:

Fatal error: Call to a member function refreshImgSrc() on a non-object in /home/example.com/test/index.php on line 19

I'm just going to use the cachebreaker URLs. This thing doesn't work.

[edit] You're calling it wrong

As your quoted error message says, $facebook->fbml is a non-object. The refreshImgSrc() method is a member of the $facebook->api_client object. Call it this way and you should be fine:

$facebook->api_client->fbml_refreshImgSrc('http://example.com/test.jpg');

I'm dynamically generating an image for use in fb:swf's imgsrc, and updating the cache when profile FBML changes. I haven't had any problems with the cache becoming stale.

--502190772 17:16, 3 December 2007 (PST)

No longer deprecated

Note: Despite Facebook's previous announcement, this function is no longer going to be deprecated. [[1]]

[edit] Self-closing tags

One place where this caching is far less robust than the browser's interpretation is if you omit the space at the end of a self-closing tag. While all browsers I've seen are perfectly happy with that, the image caching no longer understands the img tag and doesn't load the image which can cause significant confusion 36910256 07:25, 8 January 2008 (PST)

[edit] Images loaded via CSS

Images loaded via CSS styles (eg, 'background: url(http://example.com/image.png)') appear to be pulled directly from the example.com server, and not cached. Is this correct behaviour? Is there a way to encourage the caching of these images?

[edit] Resize Image While Caching

Is there a way for the image to be risized to a specific size while it's being cached? Maybe through some GET parameters?

[edit] Image Rendering

If Facebook weren't using GD-JPEG V1.0 and started using the current release, maybe some of the issues here could be resolved. There are new features to the current stable release of GD JPEG and it is compatible with more image formats. Not only that, but it is obviously more stable with bug fixes.