Bug #9260

Colorspace of exported images

Added by Thomas Heßling over 7 years ago. Updated about 7 years ago.

Closed: won't fix
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
other GNU/Linux
hardware architecture:



this is not really a bug with Darktable but an incompatibility with 3rd party software / services. It occured to me when I ordered several prints from Saal-Digital (a print service with color-management support). I exported several images with Darktable's built-in AdobeRGB profile and was quite surprised that the printed images looked very dull (low color-saturation and some false colors) when compared to the softproof I did in Darktable (my monitor is calibrated btw). While looking for the cause I noticed that the Windows photo viewer shows exactly the same bad images. My guess is, that neither the photo viewer nor Saal correctly determine the embedded color profile and therefore assume sRGB. Other image viewers work fine, though.

To test this I exported the exact same image with the original "Adobe RGB (1998)" profile I downloaded from Adobe and now the Windows image viewer shows the correct image. So far I have not ordered more prints from Saal but will do so next week and report the results.

Has anyone else observed something this? I could not find anything about it.


Sample_Darktable_AdobeRGB.jpg (1000 KB) Sample_Darktable_AdobeRGB.jpg with original Adobe RGB (1998) Thomas Heßling, 02/16/2013 10:01 PM
Sample_Darktable_AdobeRGB.jpg (1000 KB) Sample_Darktable_AdobeRGB.jpg with Darktable's integrated AdobeRGB Thomas Heßling, 02/16/2013 10:01 PM
scans.jpg (676 KB) scans.jpg Thomas Heßling, 02/22/2013 05:21 PM


#1 Updated by Pascal de Bruijn over 7 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

This issue was fixed in version 1.1. Please update to a current version of Darktable.

#2 Updated by Thomas Heßling over 7 years ago

This happened with Darktable 1.1.2, right now I'm using 1.1.3 and the Windows image viewer is still affected.

#3 Updated by Pascal de Bruijn over 7 years ago

  • Affected Version changed from 1.0.3 to 1.1.3

Oh, the bug metadata said the affected version was 1.0.3 thus my response. I'll update that then.

For 1.1 and higher we've been quite meticulous about reproducing the original sRGB and AdobeRGB as closely as we can.

Which brings to mind, which exact version of lcms2 are you using Darktable with?

Would you mind uploading some samples broken and working to illustrate the issue.

#4 Updated by Thomas Heßling over 7 years ago

Oh, maybe I selected the wrong version, sorry for that.

I attached two sample images, one with the original AdobeRGB and one with the builtin profile.

Just to clarify, I don't think there's anything wrong with the builtin AdobeRGB profile as such. With a properly working image viewer, say Gimp, Geeqie or even color-managed Firefox, both images do look exactly the same. But some other viewers seem to not accept the builtin profile, such as the windows photo viewer. If it was just this one I wouldn't care, but since the print service I used had the same problem there might be more to it.
The version of lcms2 I'm using is 2.2+git20110628-2.2 (from Debian testing).

Thanks for your help!

#5 Updated by Thomas Heßling over 7 years ago

Hello again,

just a small update. I received the prints from Saal that I send to them with the original AdobeRGB profile. This time the prints look correct. A scan from both versions is attached, the left one is with Darktable's profile and the original one on the right. The colors seems dull on the left one while the right is as intended. I've also contacted Saal's support to see if they know what's going on.

#6 Updated by Pascal de Bruijn over 7 years ago

  • % Done changed from 100 to 50
  • Target version set to Candidate for next minor release
  • Assignee set to Pascal de Bruijn
  • Status changed from Fixed to In Progress

In the meanwhile I contacted Marti Maria, and he pointed me to a freely available ICC validator. The only thing the validator noticed that we were missing the required cprt (copyright) tag.

So we added a cprt tag for correctness sake:

But it does make me wonder if that would be problematic for Saal, as the copyright tag has no technical relevance for the colorspace itself, it's just metadata.

#7 Updated by Thomas Heßling over 7 years ago

Thanks for still looking into this. I just received an answer from Saal. According to them the profile name has to be exactly "Adobe RGB (1998)" in order to be recognized.

#8 Updated by Pascal de Bruijn over 7 years ago

Wow, that's worse than I could have imagined :(

We purposefully didn't use identical strings, to make it easier to identify our profiles from the real ones :(

I've committed the logical work around for the "issue" identified by Saal:

I'll probably have builds (including the above fix) on my Darktable Unstable PPA in a few hours or so.

Could you work out with Saal to actually test this, so we can be sure the issue is resolved?

#9 Updated by Pascal de Bruijn over 7 years ago

  • % Done changed from 50 to 0
  • Status changed from In Progress to Closed: won't fix

I was particular cautioned about the above change by someone who had actually contacted Adobe about redistributing an unofficial Adobe RGB clone earlier. And he was told that "Adobe RGB" was a trademark.

All instances of the name "Adobe RGB" in the text are references to the Adobe RGB (1998) color space and
color encodings as defined by Adobe, unless otherwise stated. The name "Adobe RGB (1998)" also is used as
a software product trademark for Adobe's implementation of the Adobe RGB (1998) ICC profile. Adobe does
not permit the use of the Adobe RGB trademark for software, hardware, or other related products from
companies other than Adobe, unless the company has obtained a prior written license from Adobe to do so.
Companies who are not Adobe licensees but who claim to have technology that is compatible with
Adobe RGB (1998) ICC profile software may claim, if true, that their products are "compatible with the
Adobe RGB (1998) ICC profile" as long as nothing in the circumstances would create consumer confusion.
Keep in mind that you must sign a supplementary license agreement with Adobe if you are interested in
distributing the Adobe RGB (1998) ICC profile software embedded or as a bundle with a camera, display or
other hardware device or software application.

So I guess that forces us to be incompatible with Saal I'm afraid.

#10 Updated by Pascal de Bruijn about 7 years ago

This is a little less drastic, but probably still compliant with Adobe trademark policy:

#11 Updated by Thomas Heßling about 7 years ago

And yet another thing to be cautious about thanks to stupid trademarks... great! ;-)

Also available in: Atom PDF

Go to top