Question about Gamut checking

nwinspeare · April 3, 2021, 4:28pm

Hello,
I have a question about the gamut checking toggle button.
To start with, I am using the rec2020 softproof and histogram profile, display and preview display are “system display profile”
I was processing a photo of some flowers. This is a screen shot of my darktable darkroom screen.

If I toggle the gamut checking, I get this.

And if I export to a jpg in srgb I get this.

I don’t seem to be loosing any detail in the centre of the flowers, so I wonder what the gamut checking is telling me. I know from some previous discussions that I should’t bother about checking gamut if what I see on the screen looks good, and I am on board with this. I am just curious to understand what is happening and if I should make some changes to my settings.
Thanks,
Nicolas

priort · April 4, 2021, 12:48am

What gamut setting are you monitoring ?? Saturation?? Luminance??

Claes · April 4, 2021, 8:02am

Morning!

What operating system are you using?
Also: what is your system display profile actually set to?
Is it managed?

Have fun!
Claes in Lund, Sweden

nwinspeare · April 6, 2021, 9:28am

Good morning,
I don’t understand your questions, sorry.
For me the choice between saturation, luminance or any RGB channel are for the “toggle clipping indication button”, the one that is a square with the diagonal line.
The “toggle gamut checking” is the triangle with the exclamation mark and has no options for clipping. I thought it just coloured the areas that are out of gamut with respect to the softproof profile : in my case linearRec2020.

The other question " what is your system display profile actually set to? … Well, I don’t know… isn’t it the system display? I have 27" IMac that is color profile with a spyder3. Does it matter for the gamut clipping?

Sorry for my ignorance, I am here to learn.
Best regard,
Nicolas.

ggbutcher · April 6, 2021, 1:29pm

I’m not too familiar with the darktable behavior, but something to consider is that, for the software to assert some pixel is out-of-gamut, it needs to know what the destination colorspace will be. Then, “out of gamut” means, “not in the destination colorspace”.

For display, to make this work properly, you need a display profile registered with the software that closely represents your display’s color capability (gamut). That’s the consideration @Claes’ questions are addressing.

nwinspeare · April 6, 2021, 2:12pm

Ok, i understood that out of gamut was calculated between the colour coordinates (in XYZ) and the working profile (linear rec2020), not with the display.

ggbutcher · April 6, 2021, 3:36pm

I guess I’m going to have to read up on what darktable is doing, as that doesn’t seem useful to me. Knowing what is out of gamut with respect to the working profile isn’t what you are ultimately looking at.

priort · April 7, 2021, 5:03am

@nwinspeare

https://github.com/darktable-org/darktable/issues/3271#issuecomment-751944842

github.com/darktable-org/darktable

[RFC/WIP] Move overexposed before colorout

darktable-org:master ← flannelhead:overexposed-before-colorout

opened 05:44PM - 31 Jan 21 UTC

flannelhead

+1 -1

I'd like to propose moving the `overexposed` module before `colorout`, at least …for the scene-referred workflow. This PR is by no means complete but introduces a minimal change to observe the effects and benefits of doing it. ### Why? In the current module order, the `overexposed` module is placed after `colorout`. When editing an image, `colorout` uses the chosen display profile, which is likely to have a small gamut. If one wants to see examine e.g. the saturation clipping in a wider gamut (e.g. having linear Rec2020 RGB as the work space), the clipping indicator is not useful here (it won't show any clipping) because the image is already clipped to a smaller gamut in `colorout`. Let's have a look at an image where the saturation is exaggerated for illustration purposes (just a random image I had at hand, nothing special). The raw image and XMP are attached. [clipping_example_image.zip](https://github.com/darktable-org/darktable/files/5900275/clipping_example_image.zip) Here are the clipping settings: ![clipping_settings](https://user-images.githubusercontent.com/5001906/106392331-f26a6e80-63f9-11eb-84da-5be2fe457534.png) Clipping indications with `master`, when `system display profile` is used for display profile and `linear Rec2020 RGB` for histogram profile (profile settings are also shown in the image): ![clipping_1](https://user-images.githubusercontent.com/5001906/106392430-758bc480-63fa-11eb-93ec-69360da0650f.png) Notice no saturation clipping is shown. One can eliminate the clipping to a smaller gamut and see the real saturation clipping by setting the display profile to linear Rec2020, but then the preview image is obviously incorrect. ![clipping_2](https://user-images.githubusercontent.com/5001906/106392462-a10eaf00-63fa-11eb-8d02-2480a8c5ad4d.png) With this PR applied and `system display profile` selected as the display profile: ![clipping_3](https://user-images.githubusercontent.com/5001906/106392474-aff56180-63fa-11eb-88e4-722566ff1b92.png) The preview image and clipping indicators are both correct. Note: obviously device-specific display profiles are all different, but one can replicate these results also by selecting sRGB as the display profile. This change particularly affects the saturation clipping indicators. To me it makes more sense to observe the clipping before clipping the image to a smaller gamut, especially when almost all the selectable histogram profiles have a larger gamut than a typical consumer-grade display. This is the case particularly for the scene-referred workflow. A use case for observing saturation clipping in e.g. linear Rec2020 is to catch potential imaginary colors that could cause problems. Overall this move would make the clipping indicators behave better, independent of the chosen display profile, and less surprising. ### Pitfalls There are some modules that come after `colorout` but before `overexposed` in the current module order. For the scene-referred workflow: * `clahe` (which is deprecated) * `finalscale` (shouldn't affect the clipping as far as I can tell) To me it would seem fine here to move `overexposed` before these modules. For the display-referred workflow: * `channelmixer` * `soften` * `vignette` * `splittoning` * `velvia` * `clahe` * `finalscale` Some of these certainly have an effect on the colours and clipping. ### Open questions * What will happen to old edits? I suppose ones with an unmodified module order will be fine but what about those with custom module order? Can we force `overexposed` to move somehow also in these cases (as it is not user controllable anyway)? * What about the display-referred workflow? I realize having the `overexposed` module in different places for display-referred and scene-referred workflows may cause documentation issues. But the mindset is pretty different between these workflows anyway, and there are plenty of other differences that are already documented. * Could this be made a user preference, like the scene-referred vs display-referred and modern/legacy chromatic adaptation are now? * Minor aesthetic nitpick: the clipping indicator colours in `overexposed` could / should be given fixed XYZ coordinates, ideally well within sRGB, to make them constant even if the work profile changes.

I think there are some corrections coming…the thread of 3271 is very interesting esp to see even how those working on the software needed to work it back and forth to come to an agreement…

priort · April 7, 2021, 5:04am

Actually not…check the links that I provided…currently there is a bit of a weird path going through the display profile and back to the histogram profile…