Possible Darktable 4.8.1 Export Issue - Flatpak Version

Perhaps something that @paperdigits can help with.

I am currently using Darktable 4.8.1 (Flatpak) on Linux Mint 22 and think I may have an issue with with the Export module. Any time I export a jpg from the RAW file it appears to disregard the selected output profile and use sRGB(WebSafe). If I select AdobeRGB as the export profile (or any other profile) it appears as if sRGB was used. If I export a tif image the export appears to respect the selected profile - this is only an issue with jpg exports.

I use AdobeRGB because it suits my workflow for printing. I create jpgs to post online and find the output sRGB jpg is significantly more saturated than the Darktable edit which is why I use the AdobeRGB profile during export. I can switch my display to sRGB and the jpg output does match, but I don’t think this should be necessary.

I have reviewed earlier edits and don’t think this was the case with previous versions of Darktable. I switched to the flatpak version because Linux Mint is still using Darktable 4.6 and that is when I started noticing the problem.

Any suggestions?

This should be fine, I do the same thing.

For the web, you should use sRGB not Adobe RGB (It wasn’t clear to me if that is what you’re doing).

That is not the correct way to verify your color pipeline is correct.


Can you please:

  1. Post a screenshot of your export module
  2. Use exiv2 or exiftool to verify what color profile is being embedded into your jpgs
  3. Say what image viewing app you’re using and clarify if it is color managed
  4. if you image viewing app is not color managed, use one that is, such as Geeqie.

As requested

Using Geequie the sRGB image shows Color Space as sRGB. The AdobeRGB Color Space shows Uncalibrated. The two images look identical.

My normal workflow had been to export jpgs with sRGB for web display but I started trying AdobeRGB because sRGB seemed more saturated than I had come to expect with other editors (Windows/Commercial).

I will probably go back to editing in AdobeRGB and export to sRGB for the web.

Did you turn on color management in Geeqie?

Adobe RGB isn’t good for the web; most things aren’t color managed and assume sRGB anyway.

How about:

Is the Exif Window in Geequie not providing the same info as exiftool?

The color management in Geequie is (and was) turned on. The images appear identical.

From exiftool for the AdobeRGB image

Profile Creator : Little CMS
Profile ID : 0
Profile Description : Adobe RGB (compatible)

for the sRGB image

Profile Creator : Little CMS
Profile ID : 0
Profile Description : sRGB

So this is not happening, right? The correct profile is referenced from each file from what I can tell.

You are correct - that is not what is happening.

I thought that was happening because the two jpg versions of the exported image are identical. I was expecting the AdobeRGB version to be a little less vibrant than the sRGB version. If I export an AdobeRGB tif it is less vibrant and matches the AdobeRGB RAW file.

If you look at the gamut plot of sRGB vs Adobe RGB, you’ll see there shouldn’t be a huge difference, mostly in greens: https://img.fixthephoto.com/blog/images/gallery/news_preview_mob_image__preview_250.jpg

This doesn’t sound right either.

It sounds like you need to look at your whole color management pipeline.

The rendering intent can make a big difference, you have it set to “image” but you probably almost always want “perceptual.”

You’ve also made reference to setting your monitor to sRGB and editing in Adobe RGB, neither of which are things you’d be doing if color management is working correctly.

I’ll have a look at all my color management settings and correct them. I think things got a little messed up trying to isolate this issue. I always use perceptual for rendering intent but did switch to image to see if it affected the jpg output.

Yes, its certainly an easy thing to mess up, I do that regularly and just start over :smiley:

1 Like