Darktable exported images are darker than viewing within Darktable

I may be missing something obvious, but images that I export from Darktable appear darker than when viewing in darkroom. I am exporting with sRGB profile and no styles applied to jpg.
Here’s an example viewed in Gwenview with Darktable on the right.

I’ve found if I set contrast to -0.10 in the basic settings and export, it almost matches the 100% preview in darkroom.

This is in Darktable 3.4 on Linux.

Are you using the softproof feature with the profile set to sRGB to inspect the file before exporting from darktable?

Is gwenview finding your display’s profile correctly?

Thanks, softproof seems to be the answer!
I had not really noticed the issue before and have never used the softproof feature, I now know!

@paperdigits: Your answer revives a question I have had: I take it that after inspecting in softproof, I would make adjustments while in softproof to obtain, in this case, the contrast wanted. Why then don’t we edit from start to finish in softproof?

2 Likes

If you’re only targeting one color space for an output, then sure, just have softproof on all the time.

But if you have more than one, you’ll get higher quality results going from the pipe color space down sampled to the output space.

It the same reason why we don’t just work in an 8 bit pipeline the whole time.

1 Like

I don’t understand what steps this is describing; I wonder if you would explain, please?

To elaborate: I switch to softproof and make desired adjustments. Then I switch out of that and go to lighttable to export a jpg. That’s what you mean by down sample?

Our working color space is generally Rec2020, which is a large or wide gamut of color. Our output color space is generally much smaller. When values in a photo hit the limit of their gamut, they can’t to any higher, you get gamut clipping. This is the same as when you clip the highlights in your raw file, you hit the ceiling, you can not record any higher value. If we just worked in sRGB all the time, we would regularly go out of bounds with out values. By working in a larger gamut space, we literally have more colors to push in our edit.

We get better fidelity going from larger to smaller, we down sample. Its that way with all the things: color gamuts, pixel size, bit depth.

Look at this plot of rec 2020 vs sRGB

2 Likes

Thank you. I understand: the down sample happens when the export to jpeg is made.

Wasn’t sure whether to start a new thread or just add to this…

Using the softproof option, the image does not look like the output exported as 8bit jpg srgb. Darktable 3.6.
Is there a setting I’m missing?

Is your display profile set up correctly? Try the command-line utility darktable-cmstest. For me, it prints:

$ ./darktable-cmstest 
darktable-cmstest version 3.7.0+358~geb1ddbe1a
this executable was built with colord support enabled
darktable itself was built with colord support enabled

primary CRTC is at CRTC 0
CRTC for screen 0 CRTC 1 has no mode or no output, skipping
CRTC for screen 0 CRTC 2 has no mode or no output, skipping
CRTC for screen 0 CRTC 3 has no mode or no output, skipping

DP-2    the X atom and colord returned the same profile
        X atom: _ICC_PROFILE (967072 bytes)
                description: [...]
        colord: [...]
                description: [...]

Your system seems to be correctly configured

But, if I force a broken config, it’ll tell me:

DP-2    the X atom and colord returned different profiles
        X atom: _ICC_PROFILE (0 bytes)
                description: (none)
        colord: ...
                description: ...

Better check your system setup
 - some monitors reported different profiles
You may experience inconsistent color rendition between color managed applications

Is colour management correctly configured in Gwenview?
Does KDE use the same rendering intent (way of converting image colours to display colours) as darktable? I left Gwenview at defaults, I think (at least I don’t remember if I ever configured these settings), and it uses perceptual:
image

However, perceptual is a weird beast, AFAIK relative colorimetric is a safer option.
In darktable, you can set this if you enable LCMS2 in the config (normally it’s disabled, I think because it is slower and usually the differences are negligible). Which rendering intent is used if that option is disabled is not documented:
https://www.darktable.org/usermanual/3.6/en/special-topics/color-management/rendering-intent/

More info on rendering intents:

Thanks for the reply. I did have the errors regarding colour profile using the cmstest, I hadn’t installed colord-kde. I’ve installed this and applied the icc profile using this and now in darktable shows it to be configured correctly. This has not changed the difference of Darktable rendering and the jpg rendering in Gwenview, Ristretto or GPicView (lxde).

Gwenview is set to ‘perceptual’, I tried the ‘relative colourmetric’ option but it didn’t obviously change the look.

OK. If you re-import the exported JPG into darktable, is there a difference between how darktable renders the JPG from how it appears in e.g. Gwenview?

  • If yes → rendering issue
  • If not → darktable output issue (in that case, you may still try enabling LCMS2 in darktable and fiddling with the output rendering intent). You can take a snapshot of the raw in darktable, then switch to the re-imported JPG, and do the comparison directly there (just like when you compare a snapshot to a given state of the history), to rule out all other factors.

With the raw file, have you tried if proofing with sRGB produces the look in darktable that you see in e.g. Gwenview? Some subtle shift is inevitable when going through colour space conversions.

Hopefully, someone who actually has a clue about colour management will also chime in. :slight_smile:

Importing the jpg back into Darktable, the processed original raw file (with softproof enabled, srgb) looks the same as the exported jpg.

Is this a Daraktable rendering issue or a colour management issue with the other applications?

[Edit]
Opening the jpg in Firefox looks much closer to the rendering in Darktable but not exactly the same, seems a little darker in Firefox. As in my previous post, the rendering in Gwenview, Ristretto or GPicView look the same and are much darker than the Darktable or even Firfox rendering.

Ristretto and GPic are not color managed. I’m not sure if gwenview supports it either.

@bug2k19
Consider posting the raw, with license, and sidecar so others can see what they get.

Gwenview is colour managed. See screenshot from above, repeated here for clarity:

  • you can set the rendering intent
  • Gwenview expects the display profile to be correcty set (last option, Colour profile)

Having looked at https://en.wikipedia.org/wiki/Comparison_of_image_viewers there is no mention of Gwenview being colour managed, but it shows Geeqie and digiKam are. I’ve installed those and the exported jpg looks just like the jpg is rendered from within Darktable. So this does not appear to be an issue with Darktable but rather the lack of colour management in the image viewers.

Thanks kofa for the image of the preference dialog, these were checked as shown and exhibited the same differences. I then unchecked the last option ‘Colour Profile: Apply only the profile embedded in the image file’ and now the image is really close to the Darktable rendering, close enough not to cause any issue. Thanks for the tip.

Glad you were able to get it to work.
I’ve been playing with Firefox, prompted by this:

You can read about colour management in Firefox here:

and

With gfx.color_management.enablev4 = true, and all other gfx.color settings left at default values, my Firefox 89.0.2 passes the test pages Is your system ICC Version 4 ready? and Browser color management test. Some comments on a forum I’ve never heard of claim that gfx.color_management.native_srgb should also be set to true.

However, I’m unable to get ‘Picture A’ (supposedly Adobe RGB) to display the text from the page

Interestingly, downloading the PNG and opening it in the Gimp display a homogeneous magenta rectangle, just like Firefox. In darktable, if input color profile is set to embedded ICC profile or Adobe RGB (compatible), I also get a magenta rectangle. Assigning sRGB reveals the text. In Gwenview, I was unable to get it to show the text. In Geeqie, the text is visible. Anyway, I don’t want to hijack your thread.
Edit: opened a new thread to discuss that image → the AdobeRGB image simply had colours outside the sRGB gamut.

2 Likes