irregular sRGB gamut boundary in OKLCH

When plotting L,C gamut slices I noticed an odd irregularity in the gamut boundary, in OK LCH. I didn’t see the same irregularity in CIE LCH. The code is

        let swatch = new Color("oklch", [lightness, chroma, hue]);
        let rgb = swatch.to("sRGB");
        // console.log({swatch, rgb});
        if (rgb.inGamut("srgb")) {
            fill = rgb.toString();  // .to("srgb");
        }

I suspect this is due to the inGamut() call, rather than being an irregularity in OKLab/ OK LCH itself.

[facelessuser]

Yeah, it seems confined to a very small hue range and a small band within that very small hue range, so probably maybe not a huge deal, but yeah, not ideal either though.

I’ve personally constrained my color library to use LCh by default (for now), only because its weaknesses are well known in relation to gamut mapping. OkLCh is kind of new in this area, and I don’t think it has been stressed enough to know where all its weaknesses are. I know I created another issue over at the CSSWG related to some unexpected behavior with OkLCh and gamut mapping: https://github.com/w3c/csswg-drafts/issues/7071. This also may not be a huge deal in most cases, but I did find it unexpected.

With that said, I think Oklab works pretty well for color interpolation at least 🙂.

[ardov]

Yep, it’s definitely not a big deal. I tried it with oklch(30.57% 0.22 264.09). The binary search chroma reduction algorithm jumps over #000296 and stops at #001788. So it reduces chroma to 0.18 instead of 0.21. The difference is so subtle I can hardly see it 😅