[css-color] Add OKLab, OKLCH

[svgeesus]

For the background and explanation of why to add this feature, please see this Color Workshop presentation which has a video presentation, plus associated slides and transcript. You can just skim the slides/transcript if you are pressed for time.

Having done so, and given the rationale presented, the specific proposal is to add OKLab as follows: Edit: items re-ordered so highest priority is first.

CSS Color 4

1. in the gamut mapping section, require gamut reduction to use OKLCH chroma reduction and deltaE OK, rather than CIE LCH chroma reduction and deltaE 2000. This is both better and faster. If we don't do this, I am not confident of being able to write a satisfactory gamut mapping section in CSS Color 4. See examples below
2. in the interpolation section, for non-legacy color formats, if the host syntax does not specify a colorspace, change lab to oklab as the default. If we don't do this, color interpolation in gradients, animations and transitions will not be as good, and will sometimes give surprising hue shifts.
3. add oklab() and oklch() (as well as the existing lab() and lch() which are still useful) and add their implementation to the sample code. Not doing this means we have a colorspace of proven usefulness, implemented inside the browser, but we deny users access to it.

CSS Color 5

4. add oklab and oklch as defined color spaces which can be used in color-mix(). Depends on 3.
5. add oklab() and oklch() to Relative Color Syntax. Depends on 3.

@argyleink @una @tabatkins @LeaVerou

[svgeesus]

Note - the gamut mapping section does not yet exist, because gamut mapping in CIE LCH gave unacceptable results in the 270-330 degree hue range and also because deltaE 2000 is complex, but is needed for good results and deltaE 76 is fast but not good enough.

Using OKLCH and deltaEOK (which is the simple root-rum-of-squares) gives better results and is computationally simple.

[argyleink]

lgtm, nice attention to detail

[facelessuser]

Curious, would it use the new lightness discussed here? https://bottosson.github.io/posts/colorpicker/#intermission---a-new-lightness-estimate-for-oklab Or would it be based on the original Oklab work that doesn't adjust the lightness?

[svgeesus]

The new Lr lightness estimator brings in a dependency on viewing conditions, which the original OK L did not have; and which is an advantage of the original OK L especially if it allows extension to HDR or at least EDR. Lr also adds a little computational complexity.

I would like to examine it some more and also see how it impacts deltaE, but my initial impression is to stick with the original OK L. I'm very open to thoughts on which would be the better option though.

[facelessuser]

I would like to examine it some more and also see how it impacts deltaE, but my initial impression is to stick with the original OK L. I'm very open to thoughts on which would be the better option though.

Makes sense. I've only played with Lr to experiment with Okhsl and Okhsv, but use it in no other way. So there may be good reasons to avoid it if using it for distancing. I also hadn't thought of implications in regards to HDR. Something to experiment with though.

[tabatkins]

I quickly read thru the slides, and didn't catch this detail - can you elaborate on why we'd want to add these in addition to the existing lab()/lch(), rather than just changing those functions to use the OKLab space? Is there a good reason to keep the existing Lab functions?

[svgeesus]

why we'd want to add these in addition to the existing lab()/lch(), rather than just changing those functions to use the OKLab space? Is there a good reason to keep the existing Lab functions?

Good question, and the main reason I suggest keeping them around is because there is lots of hardware (instrumentation, like spectrophotometers) and software which generates Lab (or LCH, or both) values. The secondary reason is that Lab and LCH have decades of user experience with them, while OKLab/OKLCH have less than a year.

So:

• to specify a color, people can continue to use lab() and lch() because that is convenient for them. They can read out a value from Photoshop or Krita or whatever and use it directly. In much the same way they can continue to use a98rgb() despite display-p3 being a more popular choice nowadays.
• for general interpolation, if the host syntax doesn't specify, then the default changes from Lab to oklab because that will generally give better results; but you can still get lab if you want it, by specifying explicitly.
• for gamut mapping, we just go straight to oklch because it is strictly better.

[tabatkins]

My issue is just that, given a choice between "lab" and "oklab", where the two look practically identical in most cases, people will naturally reach for "lab". We should bless the shortest, most convenient names with the most preferred syntaxes, even if we allow other types in other ways. (And in particular, we've accidentally set a precedent of all the specialized color functions have three-letter names. That probably can't persist forever, but for now, at least, "oklab" would join "color" as looking a little out-of-place and possibly "advanced".

Presumably we'd be able to offer the old Lab via color()? (Not LCH, tho.)

[Crissov]

Three letters you say?

• oklab => okl(<percentage> <number> <number>)
• oklch => okl(<percentage> <percentage> <angle>)

But this idea was already dismissed for cie(). #4481

cie() = cie( /* Lab */ [<percentage> && <number>{2}] 
           | /* Luv */  <percentage>{3} 
           | /* LCH */ [<number>{2} && <angle>] 
           [ / <alpha-value> ]? 
           ) 

okl() = okl( /* Lab */ [<percentage> && <number>{2}] 
           | /* LCH */ [<number>{2} && <angle>] 
           [ / <alpha-value> ]? 
           ) 

[svgeesus]

we've accidentally set a precedent of all the specialized color functions have three-letter names

I don't think any precedent has been set.

[facelessuser]

So, I am curious. It seems there is talk about using chroma reduction using Oklch for gamut mapping/reduction. I was playing around with this and was noticing some interesting things when gamut mapping using this method. Granted, maybe I'm doing something wrong here. This is based on the same algorithm used in color.js for Lch chroma and using the currently specified ∆Eok in that library.

When using something like display-p3, things get mapped very similar as they do with Lch vs Oklch, granted I think their blue range is very similar. But when using something like rec2020 which has a wider blue range, the mapping gets dull blues. (oklch chroma reduction on top).

This doesn't happen as much with greens and lesser with reds. Now granted there doesn't seem to be an official algorithm posted yet, and so I'm more curious if all these edge cases have been evaluated. Maybe the actual algorithm that is to be used compensates for this. I'm more curious if it improves in some places, but lesser in others, or if there is a better algorithm (different from the CIELCH one used on colorjs.io) that is planned to be used that works well with Oklch?

It's possible I'm just not implementing correctly, and in that case, I will wait patiently to better understand how the reduction is actually done, or keep plugging away to see what I'm doing wrong 🙂.