Using CIECAM to bring out-of-gamut RGB into gamut

[faern]

Back in comment #32 (comment) you wrote about three ways to bring a WideRgb value back into the valid RGB range (bring it into the RGB gamut):

• The simplest would be to clamp the out-of-range R, G, or B value, either on <0.0 or >1.0 values.
• The second approach would be to transform all R, G, and B values by using an offset and scaling, effectively desaturating the colors and scaling the luminance.
• A third one would be to convert an XYZ or RGB value to a CIELAB or CIECAM value, and scale the chroma value down, keeping the hue value the same, until the RGB value is within gamut. Hue lines are not straight lines in the CIE xy color diagrams...

The first two options are covered by WideRgb::clamp and WideRgb::compress respectively. I'm now looking into the third option as a way to improve the rendering of my chromaticity diagram. I would love to add a method for this third option onto WideRgb so it becomes part of the library.

I'm toying with this at the moment to try to understand more about CIECAM. I'm rendering the "hue lines" to try to understand them. But I get weird results. I'm probably just doing something fundamentally wrong. I'm opening this issue to try to understand what, in order to be able to implement and contribute something like WideRgb::constrain_keeping_hue() -> Rgb.

Here is my code for taking an XYZ value and lowering the chroma until no RGB value is negative. And drawing a line along the chromaticity coordinates visited along the way. I then run this for a set of XYZ values along the observer's spectral locus.

The abort condition or the step size is not important right now, but rather the fact that it starts out far outside the chromaticity diagram, and then when passing the boundary it does so in a very different spot than the original XYZ value. This means that if I convert an XYZ value to CIECAM16 and then back to XYZ again, I never get the same result back, no matter the chroma used (even the original chroma). Why not?

fn compute_ciecam_hue_line(xyz: XYZ, observer: Observer) -> Vec<Vertex> {
    let xyzn = observer.xyz_d65();
    let viewconditions = ViewConditions::default();

    let xyz_to_vertex = |xyz: XYZ| {
        let chromaticity = xyz.chromaticity();
        Vertex {
            position: [chromaticity.x() as f32, chromaticity.y() as f32],
            color: [0.5, 0.5, 0.5],
        }
    };

    let mut vertices = vec![];
    // Start with the original XYZ value
    vertices.push(xyz_to_vertex(xyz));

    // The lightness and hue stay fixed. We only lower the chroma.
    let [lightness, mut chroma, hue] =
        CieCam16::from_xyz(xyz, xyzn, viewconditions).unwrap().jch();
    loop {
        let cam = CieCam16::new([lightness, chroma, hue], xyzn, viewconditions);
        let xyz = cam.xyz(None, None).unwrap();
        vertices.push(xyz_to_vertex(xyz));

        // When there are no negative RGB values, we stop.
        if xyz.rgb(None).values().iter().all(|&v| v >= 0.0) {
            break;
        }
        chroma *= 0.95;
    }
    vertices
}

[faern]

I just sampled the xyz values to compute the hue lines from with Observer::xyz_at_wavelength. But I notice now that if I append a .set_illuminance(100.0) before converting to CIECAM, then it actually starts at the spectral locus edge instead of starting by shooting out from it. But only for values not close to the locus endpoints. At the endpoints it still behaves weird, even more weird than before:

[faern]

My use case is only to draw the chromaticity diagram. For that I can imagine other solutions than a hue-preserving WideRgb -> Rgb conversion method. But I still think it would make sense for the library to provide such a to-gamut-conversion method.

Another method for drawing my diagram was to go the opposite direction. Loop through all hues (0..=360) and for each of them start with chroma = 0 and increase the chroma until I hit the edge of the spectrum locus. But the hard part with that solution is to figure out when you cross the spectral locus and should stop. Is there some nice trick for doing that maybe?

[harbik]

I suspect the problem in your example is that the XYZ start values at the ends of the spectral locus are invalid, probably because the Y values are too high. That leads to invalid JCh values, too, since they’re derived from those XYZs.

The best way to make sure your XYZ and derived JCh values are valid is to generate the XYZ values from actual spectral data. On an sRGB display, in the use case you have here, you could take the D65 illuminant and apply a narrow-band Gaussian filter—say, with a full width at half maximum (FWHM) of approximately 5 nm. Then use the Observer::xyz method with D65 and the filter to calculate XYZ values along the spectral locus, and from there get the corresponding valid JCh values.

Once you’ve got valid JCh values for the spectral locus, you can safely reduce chroma and convert them to chromaticities to get valid paths. Starting from the spectral locus is the right approach, in my opinion. If you go the other way—starting with JCh values where chroma is zero—you’ll likely run into the same issue, because not all JCh values represent real, physical colors.

[faern]

I suspect the problem in your example is that the XYZ start values at the ends of the spectral locus are invalid, probably because the Y values are too high. That leads to invalid JCh values, too, since they’re derived from those XYZs.

What defines a "valid" XYZ value? I simply get mine by iterating over the locus wavelength range and sampling Observer::xyz_at_wavelength(wavelength). This essentially becomes the color matching function values for a given wavelength. Are these raw CMF-values not valid tristimulus values?

take the D65 illuminant and apply a narrow-band Gaussian filter

Nice ideal. I'll try that! However, this spectrum will not represent monochromatic light obviously. So I doubt I'll end up on the spectral locus when converting to chromaticity coordinates. But I guess I can find suitable scaling factors in x and y to to translate the coordinates out to the actual spectral locus, and keep using that scaling to also project the other points as I lower the chroma 🤔

[harbik]

What defines a "valid" XYZ value?

In CIECAM appearance models, which are essentially psychological models, an XYZ tristimulus value is only considered valid if it represents a related color—that is, it’s defined relative to a reference white.

• Illuminated (or printed) media:
  Colors are created from the illuminant’s spectral power being filtered or absorbed by objects.

• Emissive displays:
  Colors are generated by mixing red, green, and blue channel values—each ranging from 0.0 to 1.0—where a value of 1.0 on all three channels reproduces the reference white.

For non-related colors, an XYZ tristimulus value is considered valid (without requiring a relation to a reference white) if its chromaticity coordinates ((x,y)) lie within the spectral locus—the boundary of physically realizable colors on the CIE 1931 chromaticity diagram. This can be considered more of a "physics model", although tristimulus values are not defined in physics - color is ultimately only a sensation in our mind.

[faern]

The best way to make sure your XYZ and derived JCh values are valid is to generate the XYZ values from actual spectral data. On an sRGB display, in the use case you have here, you could take the D65 illuminant and apply a narrow-band Gaussian filter—say, with a full width at half maximum (FWHM) of approximately 5 nm. Then use the Observer::xyz method with D65 and the filter to calculate XYZ values along the spectral locus, and from there get the corresponding valid JCh values.

I tried this, since it's a very interesting idea. Since the gaussian filter let more than a single wavelength through. I will not get monochromatic light, and thus not reach the real spectral locus. It will be somewhere closer to white. Depending on the with of the filter. But with a too narrow filter the JCh values start becoming invalid again. And no matter how wide I make the filter, at the very start and end of the spectral locus the JCh values become crazy no matter what.

See this screenshot. The pink line is the line of chromaticity coordinates I get if I use the filter Colorant::gaussian(wavelength as f64, 5.0) and obtain XYZ values with it (with light being set to D65). Then convert the resulting XYZ value to CIECAM16 and back to XYZ and take the chromaticity coordinates of that.

At the top green part, it does not not reach the spectral locus, and at the blue and red ends it yields "invalid" values outside the horseshoe.

This method also does not allow me to figure out the valid JCh values along the bottom line of the chromaticity diagram (the pink line not on the spectral locus). So I still have to figure out how to compute those :)

[harbik]

And no matter how wide I make the filter, at the very start and end of the spectral locus, the JCh values become crazy no matter what.

I've found myself in this situation quite often in the past - the XYZ values are becoming so small that color models become unstable. These can be particularly challenging to fix, especially with a model as complex as CIECAM.

This method also does not allow me to figure out the valid JCh values along the bottom line of the chromaticity diagram (the pink line not on the spectral locus). So I still have to figure out how to compute those :)

You have to take a deep blue XYZ value, and a deep red XYZ value, and mix them by using fractions: XYZ = (1-f)XYZ_b + fXYZ, and vary f between 0.0 and 1.0. Complementary wavelengths with negative values are sometimes used to get points along this line (see Dominant Wavelength (Wikipedia)):

When the chromaticity lies within the triangle with vertices at the white point, extreme spectral violet (360 nm), and extreme spectral red (780 nm), the dominant wavelength is indeterminate because the half straight line that passes through the white point and that chromaticity point intersects the limit of the visible gamut in the line of purples instead of the spectral locus. The colors on the line of purples cannot be defined by wavelength because they do not represent monochromatic light.[1]

Instead, the dominant wavelength is replaced with the complementary wavelength, which will represent the complementary color. To calculate it, the half straight line that starts on that chromaticity and passes through the white point is used; the intersection between this line and the spectral locus is the complementary wavelength. If a color doesn't have a dominant wavelength (and it is not achromatic), its complementary color will.

So a value of -520nm would be the purple color roughly in the middle of the purple line, determined by drawing a line from the spectral locus at 520nm through the white point, and extending it to the purple line. However, the CIE1931 chromaticity diagram is a very bad representation of color perception, and that is why we color circles and models such as CIELAB and CIECAM, and use hue values instead.

[harbik]

UPDATE: I’ve been working on this for the past week or so, and it turned out to be way more complicated than I thought! The draft pull request still has many changes to be made, especially in the documentation of it all.

I started with the CIELab model and managed to get a decent representation of the iso-hue lines:

To show you how the colors look, here’s the SRGB gamut:

You’ll notice that the yellow area is slightly compressed, which is because CIELAB is a perceptually uniform space. This area is super bright and would also need more CIELAB bins to plot.

The primary work I performed was to develop algorithms to obtain valid CIE Lab color values and, subsequently, associated valid XYZ values.

I appreciate @faern bringing this to my attention, as I learned a lot figuring this all out. As a result, the library will be better equipped to handle these essential colorimetry exercises.