Hue shift in filmic; all OK if exported in Rec2020 and reimported

[kofa73]

Describe the bug/issue
There are hue shifts with filmic and sRGB output. If the file is exported as Rec2020, and is re-imported, the image looks as expected (no hue shifts).

To Reproduce

1. Get the raw from https://discuss.pixls.us/uploads/short-url/2APfAZ1JIkXowLpfETmKyqFECLP.ARW and the attached XMP DSC09445.ARW.xmp.txt
2. Check the preview. Take a snapshot.
3. Export the image in Rec2020.
4. Import the result of the export: will look fine in the darkroom.
5. Compare with the snapshot.
6. Take another snapshot.
7. Export the image as an sRGB file
8. Import and compare with the other snapshots. There will be no/very little difference when compared with the Rec2020 export, but there is a difference when compared with the raw.

Expected behavior
No hue shift; raw preview matches preview of Rec2020 file.

Screenshots

Top: raw preview; bottom: preview of the sRGB file created from the imported Rec2020 file.

Platform
This affects all platforms, and has been a long-standing issue.

[flannelhead]

When you export to TIFF in linear Rec.2020, filmic v6 does the gamut mapping against the linear Rec.2020 instead of sRGB. In this case, that is close to a no-op. When that TIFF is imported, filmic is not activated. Essentially, these steps bypass the gamut mapping to sRGB that would have been done by filmic, and instead the out-of-gamut colors are clipped per-channel, resulting in uncontrolled hue shifts (you see the rat-piss yellow in the bottom half of the screenshot).

Whether filmic's gamut mapping generates a hue shift is a matter to be investigated. After following the pixls.us thread and doing my own tests, it would indeed seem to me that perhaps the desaturation needed to bring the bright yellow / orange highlights in the petals back in gamut, could cause a slight skew towards red. At this point I'm not yet sure where that could come from, but it probably is related to the colorspace that was chosen for gamut mapping for filmic v6. But I think further investigation is required.

[kofa73]

If I do the sRGB conversion using tificc from LittleCMS, I get slightly different colours, but still yellow -- after all, it's a backlit, yellow sunflower.
Rec2020 TIFF exported by darktable, loaded into darktable vs same tiff after tificc conversion:

Raw vs tificc result:

Krita's output vs tificc result (the sRGB2014 profile was used):

RT's output vs tifficc result (with sRGB2014 profile):

Argyll cctiff vs tifficc:

Could all those mappings be wrong?

[aurelienpierre]

Filmic gamut mapping compresses chroma at constant "hue" in Kirk/Filmlight Ych space until colors fits in gamut.

No color space is truly hue-linear, except Ebner & Fairchild IPT, which doesn't do HDR and sucks at pretty much everything else. And even then, constant hue studies do not agree with each other and hue linearity depends vastly on the observer :

from https://doi.org/10.1371/journal.pone.0119024

What ICC and other software do is RGB clipping, which they call gamut mapping by a nasty word play : the outcome is completely random. RGB clipping in such colors results in a shift to yellow (responsible for the rat-piss yellow sunset). What is done here is nail hue and luminance so we can at least predict something.

Besides, I have tested this picture with nothing in the pipeline but a single exposure module set to avoid any clipping, and it is indeed orange in these conditions, that is more red than what is shown here. Whether the yellow shift created by RGB clipping matches user expectations or not is unrelated to what the gamut mapping is programmed to do here: preserving hue. The yellow shift is actually not bad here since the flower is known as yellow, but will be detrimental for more red hues and anyway, if you look at the picture underexposed as to avoid any clipping it appears orange.

This will most likely be a won't fix unless someone finds a mistake in my implementation of Kirk Yrg/Ych. Fixing would require another color space which will probably screw up in another part of the spectrum.

[todd-prior]

Solved...sorry for the noise....

@aurelienpierre As always thanks for your comments....I was wondering along these lines...at least with this image when I was following @kofa I noticed that the lightable preview and the exported file seemed to match but the preview in DT was much more saturated...to the extent shown in some of the export comparisons shown above.... I feel like i have the thumbs set to high quality processing always and not sure I know there can be differences between the lightable preview and darkroom one... I have attached the xmp... I am wondering if you see this as well ....maybe I need to check a few more images to see if its just an anomoly ???
DSC09445.ARW - Copy.xmp.txt

PS this would be windows... Preview size in darkroom set to original and prefer performance is not selected...

Solved..its my display profile ...if I use the DT srgb for display they match...not sure how I missed that....

[github-actions]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.