Color balance RGB, Hue change, Gamut... Queries

RawConvert · July 6, 2021, 10:34pm

… and Playraw if you fancy

I was processing this recent pic and decided I’d try changing the colour of the flowers to match the brick wall, as an exercise. I used the color balance rgb module and changed the hue shift.

I noticed a few things I don’t understand, hopefully someone might be able to explain.

Firstly, I’m wondering why it’s so hard to control the gamut of the flowers. I have an exposure mask on them and have reduced exposure by nearly 2/3rds EV. In col.bal.rgb (same mask) I have global saturation fully left and global brilliance appreciably left. Filmic sat. is only 3%. Yet the flowers are fairly OOG, as below. I’m puzzled why the wall is ok but not the flowers; the flowers don’t look more vibrant/colourful than the wall to me.

Then I tried the color picker. The window frame, which looks quite bright to me, gives about 240 for the R channel (G,B lower). The flowers give up to 273. The brick up to only 236. Seems weird, perhaps one of those illusion things?

If the Hue slider is now moved to say -138 to make blue flowers, things seem to go a bit haywire. There are burnt out areas at (255,255,255) and large negative R values where blue, eg (-369,165,200). This seems odd.

Lastly it says in the manual that “The global color picker works in display RGB color space”. Doesn’t that mean if you change the display profile (right click of the softproof button) then you should get different numbers? But I don’t. Does the color picker show you pipe values just before Output Color Profile module, converted to display profile?

All this is with dt 3.6.0.

Here is the raw and my XMP -
03218.CR2 (60.3 MB)
03218-statue-flowers.xmp (53.6 KB)

Licensing: May not be reproduced outside of the Pixls.us platform

priort · July 7, 2021, 4:02am

Picker will show you the histogram colorspace…it does run through display first so really the only true way (unless this has been fixed to show gamut ) is to set your display profile and histogram profiles to be the same so for instance rec2020…your image will not look good on the screen but the gamut will now be accurate…part of the explanations can be found here…I am not sure how easy this will be to correct going forward until this processing order is modified.

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.

anon41087856 · July 7, 2021, 7:22pm

Ain’t no conversion about gamut that doesn’t state the gamut of what space. “Gamut” is not an absolute thing, it’s relative to a particular color space.

The fact that a RAW image exceeds sRGB/Rec 709 gamut is a non-information. In darktable, we take great care of honoring Rec 2020 gamut because it’s fairly close to the whole visible locus, so anything out of Rec 2020 has good chances to not even be a visible color. That’s why we care.

But then, your pipeline can and will leak outside of your printer’s gamut and sRGB. That’s how it is. The question is : does the CMS do its job at remapping properly to output space ?

That gamut alert you show us is using a very particular space defined in a ICC profile chosen in the “softproof profile” option. Depending on the space selected there, what you show might or might not be concerning.

RawConvert · July 7, 2021, 10:33pm

I should have said, the softproof (and histogram) profile is sRGB web safe. The display profile is AdobeRGB. Working profile is default, linear rec2020 with gamut clipping off. I haven’t digested the github item above, tonight has been football!

I set preferences to use little CMS with a perceptual output profile. Is that what you’re referring to when you say “does the CMS do its job”? And who can answer your question? - I can’t!

anon41087856 · July 7, 2021, 10:44pm

So…

Nothing to be concerned about then. sRGB is going to be exceeded if you shoot raw, that’s business as usual.

If you don’t see suddent hue shifts in the middle of what should be smooth colorful gradients, then it does its job.

The general rule is to stop being concerned about the gamut as long as nothing visually weird happens in the screen. All the little scopes, alerts and clipping warnings help to diagnose problems when you see them happen, they are not excuses to make up issues on matters you half-understand when everything looks good otherwise.

RawConvert · July 7, 2021, 11:11pm

…but I’d like to 3/4 understand, or more…
And it doesn’t all look good otherwise. I mentioned blue. With hue around -100 this is the result -

Why have the flowers gone so bright? They are now burnt out with the clipping indicator (next to raw indicator) set to Luminance confirming that. But the flowers are not burnt out at various other hues. Perhaps I don’t understand, but I would have thought changing hue would not much affect brightness/luminance.

anon41087856 · July 8, 2021, 12:02am

I have to check what exactly happens, but there is no guaranty that same luminance and chroma at different hue are still in gamut.

See The sRGB book of color - Aurélien PIERRE Engineering

If you start at a redish-orange hue (sitting on that yellow hill) and swap hue to move left (to blue) at same chroma (parallel to x axis), you end on top of the blue valley, aka out of sRGB gamut. In that case it’s possible that filmic simply clips to white or near-white.

Color spaces don’t care about visual properties of color (chroma, hue, luminance). That’s only for you and possibly the GUI controls. The max chroma available in-gamut is different depending on hue, so shifting hues at same chroma and luminance is not necessarily gamut-safe.

nish · July 8, 2021, 12:26am

Would it make sense to have some type of hue “rotation” slider that normalizes chroma based on that graph? It could be useful in situations like these.

Maybe I’ll even take a stab at it, I’ve been meaning to find a reason to gain familiarity with the codebase.

afre · July 8, 2021, 1:03am

The image reminds me of the aftermath of an artillery game I used to play in computer class.

RawConvert · July 8, 2021, 11:14am

Thanks for the explanation. So I’ve made one change, put Global Chroma nearly fully left, and now I have Hydrangeas (sort of) -

@nish , Yes, I think so. Or color balance rgb could perhaps have an option to automatically adjust the chroma as you change hue?

anon41087856 · July 8, 2021, 12:22pm

It’s a lot more complicated than that, because that graph depends on the lightness too : checkout the ones around 20-40% lightness, the valleys and peaks are not at the place anymore.

Also these graphs are produced in display-referred (bounded to 100% display luminance) while color balance works in scene-referred.

Color balance RGB works in Rec2020 and already has chroma clipping in Rec2020, which is irrelevant for the current problem. The problem here is with the output RGB space (sRGB), which is no concern of the pipeline, since the pipeline is a master. The last step of water-tightening for darktable will be a proper internal gamut mapping at output color space conversion. Hopefully for Christmas…

nish · July 8, 2021, 11:57pm

Ah I see what you mean, so it makes sense for gamut mapping to handle this. Thanks for the explanation!