Hello! I’ve recently installed Darktable 5.2 as I wanted to process a few pictures of my baby. After playing a bit with the processing settings, I got this in the software (zoom to fit, and 100% zoom):
I am not sure if this will fix the problem but set the profile to sRGB (web safe) for Jpg images as they are usually viewed on the web. Hopefully that is problem.
Perhaps the issue isn’t the export but the view on screen. As far as I know Linux with wayland is not color managed. Should an export profile be added to the workflow for the image for proper display space representation? I don’t see that module listed.
On my screen, the export example is significantly more saturated (HSL) when viewed in the GIMP and the HSL Saturation map extracted and compared with the screenshot HSL saturation map.
My mistake, dt 5.2 but my point remains that the too-saturated example image was posted with an embedded sRGB profile; so maybe that is not the problem
There is an “Output color profile” that is enabled (and cannot be disabled), set to sRGB. I tried to set it to Adobe RGB and got the same result.
No, I did not have it activated. I activated it and played around, and if I change “display profile” from “system display profile” to “sRGB”, I get the same oversaturated look. If I switch to “Adobe RGB” it’s better, but in any case, the export is still over saturated.
You should check the output of darktable-cmstest. Search the forum to see how to do that with an AppImage.
It is possible that your display profile is set wrong, so you get a pale view in darktable (which uses the profile), causing you to make oversaturated edits. Then, when you view the export in non-colour-managed viewers that drive your display as sRGB, you get oversaturation.
If you import the exported JPG back into darktable, does it look like the raw, or does it look oversaturated? If it looks like the raw, then I’m fairly sure it’s a colour management issue.
Another possible factor:
The darkroom preview does not always match full-resolution processing (you work on a downscaled version to speed things up). There’s a button to turn on full-resolution processing in zhe darkroom.
Similarly, for downscaled exports, unless high quality resampling is enabled, downscaling happens early an final results may change, depending on export resolution.
I always export with high quality resampling enabled, and often check in the darkroom with the button I mentioned above, before I trigger the expert. If both are in HQ mode, and there are no colour management problems, the exported result should match the darkroom view.
Then from another terminal, go to that directory, find the binary and run it:
$ cd /tmp/.mount_xxx
$ cd usr/bin/
$ ./darktable-cmstest
This is what I get:
darktable-cmstest version 5.2.0
this executable was built with colord support enabled
darktable itself was built with colord support enabled
primary CRTC is at CRTC 0
/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so
eDP-1 the X atom and colord returned different profiles
X atom: _ICC_PROFILE (0 bytes)
description: (none)
colord: "/home/pieq/.local/share/icc/edid-6f14eff48df3e205411940f0482ac113.icc"
description: Built-in display
Better check your system setup
- some monitors reported different profiles
You may experience inconsistent color rendition between color managed applications
I tried to go in GNOME Settings and change the color profile from “Automatic - built-in display” to “Standard Space - sRGB” or “Standard Space - Compatible with Adobe RGB (1998)”, but nothing changes.
When I import the Jpeg back into DT, it looks like the raw, so you’re right, it’s a color management issue!
How can I fix this, though?
And most importantly: I want to get a book printed with these pictures. How can I make sure I’m not gonna end up with a badly saturated result on paper?
(sorry, my knowledge of color management is close to zero…)
Proofs…Or a test print. You will also be dealing with a completely different way of creating the colours, with its own colour spaces (YMCK, in general). That means you may have to check more than just the saturation (brightness is often an issue).
I just opened the images from another computer with a different screen (still Ubuntu 24.04, still GNOME, still Wayland, and same AppImage of DT 5.2), and this time the original Raw and the exported Jpeg look OK!
I guess I’ll continue my processing on this machine/screen, and hope for the best for the printed results!
