Feature #9406

Facebook Album Refresh button

Added by Vlad Berditschewski about 7 years ago. Updated about 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
hardware architecture:


When a photo is uploaded to a facebook web album, the following problems occur:

1. The picture size is always reduced, even if the "max size" setting in the global options dialog is bigger then the standard facebook size. If you upload photos in a browser, there is a "high quality" checkbox. If checked, the picture size is not reduced. I'm not sure, if the facebook API has a similar option, but if it has, it should be always used by darktable.

2. The saturation is reduced, at least for photos converted from AdobeRGB to sRGB. I'm not sure, if it's a darktable or facebook bug, because I encountered this problem only on facebook, but if you export a photo to disk (sRGB output profile), open it in gimp, save the file and then upload it to facebook, the saturation is not reduced. It seems that facebook does not correctly understand the color profile attached by darktable.

3. The facebook module has a combobox with a list of existing facebook albums, but there is obviously no possibility to refresh this list. A refresh button should be added near the combobox.


#1 Updated by Pascal de Bruijn about 7 years ago

1. I can reproduce that our uploads are being limited to 960x, and we should probably look into HQ upload possiblities in the future. However high quality uploads also do limit the resolution (2048x IIRC), but it would still be a significant improvement.

2. From my experiments it seems Facebook automatically converts all images to their own variant of sRGB, which totally makes sense for web-use. Which is also why we call our sRGB entry "(web-safe)". Typically it makes very little sense to upload anything but sRGB to the web in general (except for a few cornercases). While we could consider limiting the facebook exporter to sRGB, it may potentially and unnecessarily limit some future use-case, considering we default to sRGB and it's already clearly marked as the web-safe option, implementing such a limit is something I'd be conflicted about.

3. The current way to refresh is logout/login I guess (which is a bit of a nuisance). And indeed a refresh button would be nice.

#2 Updated by Vlad Berditschewski about 7 years ago

1. Yes, facebook always reduces image size to 2048px and also recompresses JPEGs so that the resulting file size is something about 200K, even in "high quality" mode. But it's still much better than the default.

2. Maybe my description was not clear enough. Of course, I do not upload AdobeRGB images to facebook, I let darktable convert them to sRGB before uploading. But the problem is that an sRGB image exported by darktable and uploaded to facebook looks different compared to the same image viewed by the same browser directly (or uploaded to any other site) - on facebook it's significantly less saturated. I'm not quite sure yet, what's the reason of this difference. I'll do some more testing here. The most strange thing is that if I open the image in GIMP and save it before uploading to facebook, it looks the same as viewed directly. Also, if I strip EXIF tags my imagemagick before uploading, no desaturation occur.

#3 Updated by Pascal de Bruijn about 7 years ago

  • Subject changed from Facebook upload problems to Facebook HQ upload
  • Tracker changed from Bug to Feature

1. Agreed.

2. Then where does AdobeRGB come into the picture? Are you shooting/processing AdobeRGB JPEGs instead of RAW? Are you sure Darktable recognizes your JPEGs as AdobeRGB (check input color profile)?

Darktable embeds a proper sRGB ICCv2 profile when exporting sRGB images and darktable applies the system display profile when viewing images in darkroom mode. GIMP for example does not apply the system display profile by default.

Please do read these:

#4 Updated by Pascal de Bruijn about 7 years ago

  • Subject changed from Facebook HQ upload to Facebook Album Refresh button

I looked into the upload code, and the HQ upload issue was actually much simpler than anticipated.

So future releases of Darktable will allow image uploads up to 2048px.

#5 Updated by Vlad Berditschewski about 7 years ago

Thanks for fixing the resolution issue!

I did some more testing to track down the desaturation problem. It occurs only under certain circumstances.

- the original photos were shot as JPEG with AdobeRGB color space
- darktable recognizes them correctly as AdobeRGB
- my display is calibrated and profiled, the system profile is correctly used by darktable, everything looks perfect on screen
- the output profile is sRGB
- the exported image looks almost the same in gimp (gimp is configured to use the system profile), but if I open the file in GIMP, it says: "the image has an embedded color profile: sRGB. Convert the image to the RGB working space (sRGB built-in)"?
- the exported image looks ok in any non color managed viewer I tried if the monitor is switched to sRGB mode (of course, colors are not the exactly same in this case, but ok)

The problems arise, when I upload the image to facebook. After some experimenting I found out that the problem occurs only if Firefox is set up to use the system profile. The config variable "gfx.color_management.display_profile" is set to the same profile that is used by darktable, gfx.color_management.mode is set to 2 (default), which means "apply color profile for tagged images only". Most people probably don't use color profiles in Firefox, so they will never notice the problem.

It sounds very strange, but seems to me that facebook applies the color profile twice: when the image is uploaded and when it is displayed. I did the following observations:

- If you download an image from facebook and compare it with the "original" image exported by darktable, you will notice that the colors are different. The facebook version is desaturated.
- If you see the facebook image in Firefox, Firefox renders it using the specified color profile, which is actually the right way. However, since the image stored on the facebook server seems to be damaged, the colors displayed in Firefox are not correct.

I found a workaround for this problem: I set gfx.color_management.mode to 0 (which means disabling color management) before uploading the images to facebook. Now, if I view them in Firefox they look exactly the same way as with any non color management viewer on Linux. Of course, they look oversaturated on a wide gamut monitor, but this behavior is expected. If switch my monitor to sRGB mode, the images look ok. If I activate color management in Firefox now, the images will look correctly in the monitor native color space (i.e. almost the same as in Darktable).

Another workaround: open the image generated by Darktable in Gimp. When Gimp asks the question (see above), say "Convert". Now save the JPEG and upload it to facebook. This method works even with activated color management in Firefox.

So, it seems to me that the facebook upload tool is buggy and applies a color profile to images on upload, where it should not. Maybe darktable should convert the images to sRGB like gimp and not only embed the color profile, when the export target is facebook?

#6 Updated by Pascal de Bruijn about 7 years ago

@Firefox, "apply color profile for tagged images only" is universally wrong. If a display profile is configured it should be applied to all images at all times.

Facebook doesn't apply any profile at all. From my experiments it seems to convert uploaded images to it's own variant of sRGB, which is actually pretty sane behavior.

The conclusion that any profile is being applied twice, is almost always wrong, I've never seen something like this happen.

Firefox' color manamagent options should not affect any images being uploaded, really. Since it's just a file transfer, so Firefox isn't even aware it's an image.

Darktable embeds a proper sRGB profile into images it exports, as it should.

(Also keep in mind if you have a ICCv4 and/or LUT based display profile some applications may not apply it properly).

Also available in: Atom PDF

Go to top