[css-color-4] Expected behavior around lightness 0 or 100% in Oklab/Oklch/Lab/LCH?

[foolip]

When adjusting lightness in Oklab/Oklch/Lab/LCH, what is expected behavior?

This is related to handling out-of-gamut colors, because:

• As lightness decreases we reach imaginary colors with no physical meaning.
• As lightness increases we reach real colors that cannot be shown on most displays.

I'm filing a new issue, because since Chrome 120, lightness exactly equalling 0 or 100% are mapped to black and white respectively. This led to a discontinuity and browsers now handle these cases differently:

https://wpt.live/css/css-color/oklab-l-almost-0.html (subtle difference)
https://wpt.live/css/css-color/oklab-l-almost-1.html (very apparent difference)

See also results on wpt.fyi

In web-platform-tests/wpt#45073 (comment), @svgeesus explained that the spec previously "effectively mandated a discontinuity", but that's no longer the case, so Chrome appropriate fails these tests now.

Oklab gradients with endpoints close to 0/100% are also affected. Demo at https://codepen.io/foolip/pen/zYXZPYr, with Chrome rendering inlined here:

Lightness 0-100%:

Lightness 0-99.9%:

Lightness 0.1-100%:

Lightness 0.1-99.9%:

In Firefox and Safari, all gradients look like the last case.

The fastest way to get back to an interoperable state would be to revert the Chrome change, so that all browsers do channel clipping, but ideally the behavior would only change once. I'm filing this issue as background reading for the breakout session planned on March 27.

[romainmenke]

If I recall correctly it should actually be displayed equivalent to linear-gradient(to right, black, oklab(0.5 0.15 0.15), white)

Linear interpolation between oklab(0 0.15 0.15) and oklab(1 0.15 0.15) is oklab(0.5 0.15 0.15) It is not oklab(0.5 0 0).

oklab(0 0.15 0.15) should only be displayed as black as a result of gamut mapping.
It is not interpolated as if it were black. Same for white.

If correct, according to the specification, then it would be good to add this to the examples. Best if confirmed by others.

[romainmenke]

Also worth mentioning that the problems in implementations aren't limited to oklab, oklch, lab, lch.

linear-gradient(to right, color(display-p3 0 -1 0), color(display-p3 2 1 1))

Becomes really funcky:

I know these specific values aren't mathematically around 0 or 100%, but these values are 0% and 100% lightness in sdr. This is all the same underlying problem. If you do not implement gamut mapping, various parts of the specification fall apart.

I don't think it is that interesting to investigate all the ways implementations are broken because they did not follow the specification.

If eventually it is decided to not do gamut mapping then we have to take a very large step back and revisit everything in css-color-4 and css-color-5 and try to get working features of these. So either we do get gamut mapping and this issue goes away, or we don't get gamut mapping and then we have a much larger issue.

[foolip]

My focus here is on the desired behavior of the syntax that has already shipped, and how to get back to an interoperable state ASAP. I understand that chroma reduction is one possible answer to the problem, but I'd like to discuss desired behavior of Oklab/Oklch/Lab/LCH independent of how it's achieved.

To visualize the space these gradients are in, here are Oklch hue slices where I've marked the line between oklab(0 0.15 0.15) and oklab(1 0.15 0.15) with a straight line. It's all outside the sRGB gamut, so the results depend...

With channel clipping:

With chroma reduction:

(These are from https://foolip.github.io/okplay/slice/ with editing.)

My observations:

• There are very visible lines in both cases, so gradients won't be smoothly varying
• Channel clipping makes the space more HSV-like and chroma reduction makes it more HSL-like

The feedback I've heard from @argyleink is that the HSV-like effect of channel clipping makes it easier to make vibrant gradients, which makes sense since the top right will always be very saturated. It does result in visible hue shifts however.

[foolip]

If I recall correctly it should actually be displayed equivalent to linear-gradient(to right, black, oklab(0.5 0.15 0.15), white)

@romainmenke Do you know where this is spec'd? That wouldn't be a straight line in Oklab space, it would be two line segments.

[romainmenke]

How is this not a straight line?

• start oklab(0 0.15 0.15)
• mid oklab(0.5 0.15 0.15)
• end oklab(1 0.15 0.15)

Because gamut mapping (as specified) happens after, it is only then that oklab(0 0.15 0.15) becomes black and same for white.

That is also why I wrote displayed equivalent and did not write that that would be the actual or computed value.

[romainmenke]

Channel clipping makes the space more HSV-like and chroma reduction makes it more HSL-like

The feedback I've heard from @argyleink is that the HSV-like effect of channel clipping makes it easier to make vibrant gradients, which makes sense since the top right will always be very saturated. It does result in visible hue shifts however.

Yes, it makes it easier, but gamut mapping doesn't make vibrant gradients impossible.

We really have to be careful to keep priorities in order here.
Needs of the end user outweigh those of the author, ...

---

There are very visible lines in both cases, so gradients won't be smoothly varying

Can you elaborate on the visible lines when using gamut mapping?

Do you have source code that could be verified by others.
Maybe there is a bug somewhere, would be good to rule that out :)

[argyleink]

the HSV-like effect of channel clipping makes it easier to make vibrant gradients

it's also as screens get better, the gradient's vibrance gets better too. it feels like a future proofed vibrant gradient / color request, rather than one I have to hold its hand for each gamut increase.

it's nice to request a super vibrant color and let devices grow into it, define once instead of multiple times. the author intent is, i want a vibrant color for this screen, do what you can, and do it as vibrant as you can (since i asked for vibrance).

[foolip]

@romainmenke

How is this not a straight line?

I took linear-gradient(to right, black, oklab(0.5 0.15 0.15), white) to mean oklab(0 0 0) for black and oklab(1 0 0) for white.

Can you elaborate on the visible lines when using gamut mapping?

If you drag around the hue in https://foolip.github.io/okplay/slice/ with "reduce chroma" you'll be able to see a triangle shape moving around, which corresponds to the edge of the sRGB gamut.

The source for that demo is https://github.com/foolip/okplay/blob/main/slice/slice.js. I've also added Color.js as an option and it also has these effects. (The difference is that "reduce chroma" just bisects for 10 iterations which should get closer to the gamut hull than with the JND stop condition.)

[romainmenke]

you'll be able to see a triangle shape moving around, which corresponds to the edge of the sRGB gamut.

I see it now :)

To me this feels more like a bug, something that could/should go away by improving the specified gamut mapping algorithm.

Whereas clipping is very crude and can easily give you weird results.
And clipping doesn't leave any room for improvement.

Gamut mapped:

Clipped:

[facelessuser]

I think you will always be able to pick out a triangle using this method, how could you not? There is a region where, suddenly, the chroma no longer changes. If you zoom out like this, how are your eyes not going to see this?

You are plotting in OkLCh, and any gamut in this space produces a triangle hue slice. Within that triangle, the chroma and lightness changes, but then outside the gamut, only lightness changes.

When you plot things like this, your eye will pick that out. Even if you smooth the edges, you'll just make a blurry triangle. We are zoomed so far out that we can see everything, and we want to tell our eyes to not see where the chroma stops changing, it just not possible.

[facelessuser]

I do think that better chroma reduction techniques can reduce this. I'm not sure if it can perfectly be eliminated. Especially when you take a large bird's eye view like this. It is easier to see the imperfections this far out.

[facelessuser]

As an example, here we use a little more accurate chroma reduction approach than CSS MINDE which reduces the triangle more, but we still get a triangle.

But again, we are so zoomed out that we can easily pick out the changes. But let's take a slice, now it is hard to tell.

Let's take another slice from the far right.

Doesn't look so bad now as we can't take everything in all at once.

[foolip]

The main question remains of what behavior is desirable at or close to 100%. That area is mostly real colors (bright and colorful) with physical meaning, although some imaginary colors around yellow-green too. I think the options are:

• Whatever channel clipping results in, which is very saturated but can also have a visible hue shift. This is what has already shipped across browsers, modulo the special case at exactly 100% in Chrome.
• Reducing only chroma to preserve lightness. This results in very desaturated colors to achieve that gradient to white a la HSL. The colors can be far from the closest possible by any kind of color distance metric.
• Reducing only lightness to preserve chroma. Only sometimes possible. For imaginary colors, reducing lightness never reaches a real color, much less an in-gamut color.
• Some combination of chroma and lightness reduction to give a saturated top right corner like HSV and similar to channel clipping.

To be clear, I'm not talking about gamut mapping in general, between all possible color spaces, just how Oklab and Lab should ideally behave. I'm also not sure of the options are practical to implement in practice in a browser engine.