Out-of-gamut colours with CAM16 to RGB conversion?

[priikone]

I was playing around with the CAM16 example code in https://colab.research.google.com/drive/1NRcdXSCshivkwoU2nieCvC3y14fx1X4X#scrollTo=bmNd5PS2iGZw trying to see how low a lightness value I need to get those same dark blues we see with RGB at 0.5, and this is what happened with 0.05:

CAM16 = colour.convert(RGB, 'RGB', 'CAM16')
CAM16_UL = colour.CAM16_Specification(
    np.full(CAM16.J.shape, 0.05), CAM16.C, CAM16.h)
RGB_PU = colour.convert(CAM16_UL, 'CAM16', 'RGB')
colour.plotting.plot_image(colour.cctf_encoding(RGB_PU));

and with 0.01:

So I'm wondering if this is an issue with the conversion, or with that particular example code, or with the CAM16 implementation? But, I see same thing with CIECAM02 as well...

[KelSolaar]

Hi @priikone,

The values are seemingly out-of-gamut which is quite common for CIECAM02/CAM16. I will take a look a bit later!

Cheers,

Thomas

[KelSolaar]

I spent some time looking at that and would need to spend some more but I could not really find anything defective so far, the automatic colour conversion graph also generates the same result than the manual path.

My gut feeling is that the model will not allow for very dark and fully saturated colours to be represented without some defects as they are outside the datasets used to fit the model. If you were to desaturate the strip, e.g. 25% saturation, it is much more stable:

[priikone]

Yeah, I played around with desaturation as well and doing that seems to work. It does behave strangely though, going very easily out of gamut if lightness is low. Without desaturating I see the blues start to go out of whack already around 25% lightness it seems...

I tested also with RawTherapee which supports CIECAM02, and seems it enforces some limits to avoid most issues but with that as well it's easy to push saturated colors, especially the blues, and it seems the lightness is never allowed to go really low to cause more issues. And I'm pretty sure it does some clipping as well...

I did try to change both lightness and brightness at the same time but it seems the brightness (Q) is ignored in Colour. There's example code at https://observablehq.com/@jrus/cam16?collection=@jrus/color that seems to handle all parameters. Seems like #418.

Edit: well, it seems the J and Q aren't meant to be modified at the same time, and same goes for C, s and M...

[KelSolaar]

Yes, we don't put any limits on the parameters so it is a bit to the user to find those, as for the parameters handling, I know we need to add some more conversion variants, just never had the time to come to it (nor the need).

[KelSolaar]

Closing this one for now! Feel free to add comments and I will re-open!