Possible case of filmic's preserve chrominance not applied in exporting

[kofa (István Kovács)]

I sweep L and h, and use a simple binary search to find the C such that converting to sRGB I get at least one RGB component very close to 0 or 1 (but strictly >=0 and <=1). I store those maxC values in an array indexed by L and h.

Then, I take the Rec2020 pixel values, convert them to LCh, replace C with the minimum of C and maxC[L][h], and convert this to sRGB. Because of inaccuracies, I actually use a slightly reduced maxC, but may switch to actually solving maxC for each out-of-gamut pixel individually.

Sorry if this is nonsense: business coder playing with colours here.

[RawConvert (Andrew)]

@kofa

Sorry if this is nonsense

No not at all, interesting, and I know what a binary search is!

[kofa (István Kovács)]

@RawConvert

I know what a binary search is

I didn’t mean to imply you didn’t. I meant to say I’m the one out of his league.

[kofa (István Kovács)]

I didn’t mean to change darktable processing. I’m just playing around, and learning about colour. Specifically, how one could map any image from Rec2020 to sRGB.

[priort (Todd Prior)]

@RawConvert

why is the histogram profile involved in gamut checking? (Clipping shown by the Clipping button, whether “full gamut” or “saturation only”, depends on hist. profile)

I think we also still have this issue with the display profile being wedged in between the working and histogram profile in series so unless you set your working, display and histogram profiles all to say rec2020 which will make the image look off but will show the true clipping if any other wise its getting truncated at the display profile and not actually based on what you set for the histogram profile…

[priort (Todd Prior)]

This is a good tool to check your output if you are trying to do it…

Online Color Converter - Colormath

[kofa (István Kovács)]

Yes, I’ve used it to provide test data.

[RawConvert (Andrew)]

@kofa

I didn’t mean to imply you didn’t.

No worries, I didn’t interpret it that way!

[flannelhead (Sakari)]

Nice experiments @kofa ! Hope you found the exercise educational. Perhaps others would be interested to see the code Some time ago I did almost the same experiment. Just beware of CIELAB, though - even if it’s supposed to correct for perceptual phenomena regarding hue, it actually makes the Abney effect like distortions in the blues even worse than they would be with a chromaticity linear approach.

Related to the discussions in this thread, on my side I’ve been prototyping the idea of having a separate module for ”gamut mapping” or whatever you might call it. It would find its place in the pipeline right before the output color profile module. Having it as a module would have several good outcomes

1. Users of sigmoid and basecurve would benefit from it
2. The destination color profile could be selectable independent of the current display / export profile. Users of wide gamut monitors would benefit from being able to see the result of mapping to sRGB.
3. Some tuneability could be added. For example, the tradeoff between chrominance and luminance in the highlights which would be clipped. This could help with things such as sunflower images washing out.
4. Last but not least, it would allow also having modules applied after filmic / sigmoid / basecurve and still getting the benefit from the gamut guard.

When it comes to design constraints, I firmly believe this module should be chromaticity linear. Any creative distortions (such as making the highlights of a sunset image yellowish) can be achieved elsewhere.

There are right now experiments regarding this kind of a transform in the Blender community. I’m following this closely and contributing my own ideas to the discussion. Let’s see what eventually comes out of it.

What @RawConvert said about the gamut check tools in darktable has been baffling me. I ought to check what is actually happening there. I believe part of this is that the display profile is always (sadly) involved in the measurements done in darktable (including color pickers) but it doesn’t explain everything. It is correct, however, that at least the gamut check that’s behind the exposure indicator button is made against the histogram profile. I believe this is also stated in the manual.

[kofa (István Kovács)]

Thanks for the kind words.

Mapping to output gamut

Hi, I’ve got away from the daily job, and now have some to play. The outcome is a bit of (Java) code (I’m a business dev, sorry). It’s not something useful, it’s just a learning tool for me. Since I’m a silly old man, it’s hard for me to keep track of the type of data an array of numbers represents, so I wrapped everything into objects. Yep, I know it’s baroque. Anyway, Java arrays are also not too efficient, being full-fledged objects with all the overhead that comes with it. The code is her…

[afre (Alan)]

@flannelhead

I’ve been prototyping the idea of having a separate module for ”gamut mapping” or whatever you might call it. It would find its place in the pipeline right before the output color profile module.

Excellent. Users will benefit from it. That was what I was hinting at earlier.

[priort (Todd Prior)]

@flannelhead

What @RawConvert said about the gamut check tools in darktable has been baffling me. I ought to check what is actually happening there.

I would have to go back and find the thread. I had asked about this sort of thing a good while back. I am not sure it was its own thread but after some experimenting I found if I recall that the actual gamut checker is using the softproofing profile to determine gamut and the exposure gamut checking uses the histogram profile. I wasn’t sure why they would be different but I guess if it were not for the display profile one could roughly give you gamut of the pipeline if you set the display temp to rec2020 and the gamut with your softproofing profile set to sRGB would show gamut of output if it was to sRGB??