Gamut Checker and display profiles

Software darktable
1

EDIT: TLDR for clarity - Where in the pixel pipe does the Gamut Check tool get its values? Is it before or after converting to the display color space?

I am hoping to get a confirmation, or correction, on proper settings when using the gamut checker

I think both the display profile and the softproof profile need to be set to the profile you are intending to check for out of gamut pixels. Much like we need both display and softproof set when using the color picker.

So if you want to check for out-of-gamut colors in the sRGB space, you need both your display profile and softproof profile set to sRGB.

Is that correct?

I ask because I get different results when the display profile is set to system display, sRGB, or aRGB (but softproof stays the same)

2

Gamut data if you use the gamut icon uses the softproofing profile…If things are changing when you change your display profile you might have a problematic display profile it should not change things…

If you check gamut with the overexposure warning and set it to saturation any channel or full etc…it uses the histogram profile to assess gamut limits

2 Likes
3

I am interested in the where in the pipe the module derives the “measured/calculated” data it then checks against the softproof profile. I have updated my post to be clearer. Thanks!

4

I have answered my own question.

Edit: If changing the display profile changes the gamut checker output, then obviously it gets its values post transform from the working profile.Which makes sense from a process standpoint…and if I had more sleep maybe I would have recognized that before posting.

As for which profile to use, I no longer think it even matters for me. Knowing a pixel is going to be OOG is not particularly relevant to anything because it will be pushed into gamut on export.

But in the interest of others curiosity, my uneducated guess is that (like the color picker) if you want to see which pixels are OOG then setting display to the target (softproof profile) may be beneficial if/when you have a display which is not going able to show the target color space with any accuracy.

Also, anyone who uses a hardware calibrated monitor needs to set the display profile to the target (softproof) profile unless you have already set that profile in your OS settings.

3 Likes
5

Please share your answer so that others may benefit from it.

1 Like
6

Done

7

Here is a post in one of the central threads around which many other ones occurred about gamut, color picker values and histogram profiles and display profiles…

You would have to read and follow all the branches to get the current state of things but I believe the pipeline has been modified wrt the interplay of the display profile color picker and histogram profile so that it is better than it once was but it has not changed and so certain display profiles because of how and where it is in the processing pipeline can introduce clipping. If you simply set your working, display, and histogram profile all to linear rec2020…there is a data pass through…the image will not look correct but this is to test the data. Now change your display profile back to system or your chosen icc profile and watch the histogram and picker values…if the change your display profile is clipping data…often those that use certain luts as part of the profile can be problematic

1 Like
8

Perhaps you can elaborate, in concrete terms, why any of that is of particular relevance to the gamut check specifically? It might prove useful for people who come across this thread in the future.

9

I have to dash now…but as I said there is a lot of work on this …I am not up on the current situation in the code but if you are changing your display profile between linear rec2020 and your display profile and the picker values/histogram are changing your display profile is introducing clipping and this will impact data shown by the gamut overlays as they rely on the histogram and softproofing profiles… what I was trying to explain might happen is shown here…

But as I said you would have to work through the current changes in the code to see where it stands …many profiles are unbound and will not create issues others can… I think steps were introduced to minimize the number of cases where this would happen but its worth checking just to know if your profile impacts the results or not…a developer that has forked DT has made some changes to this in his fork to simplify this…something similar may come to DT or it may not…

1 Like