[css-color-4] Update ΔEOK to be even more perceptually uniform

[foolip]

In a discussion with @bottosson, I learned that he considers the scale of the a and b coordinates a mistake in the design of Oklab. Orthogonality between L, a, and b was a design goal, but the scale of the coordinates was not carefully chosen. They should be roughly doubled to make a change in a or b as noticeable as the same change in L.

I don't think this is documented anywhere, so I'm hoping for confirmation here. Perhaps I've also misunderstood.

If correct, then it's too late to change the coordinates, but ΔEOK should probably take this into account. An update to the preceding prose would also be needed, but I'm leaving that until the math itself is confirmed to be correct, in case it's not.

[bottosson]

This was discussed previously back in 2021: #6642 (comment)

The linked comment and the next few ones after it provide more details.

[foolip]

Thank you @bottosson! Quoting what I think are the most important bits.

First @bottosson said:

I unfortunately didn't spend that much time calculating and validating that scaling factor when I first derived Oklab since I was mostly focused on the orthogonality between L, C and h (and I didn't expect it to become so widespread so quickly), and it seems like it is off by quite a bit.

I've recently done some tests with color distance datasets as implemented in Colorio
and on both the Combvd dataset and the OSA-UCS dataset a scale factor of slightly more than 2 for a and b would give the best results (2.016 works best for Combvd and 2.045 for the OSA-UCS dataset).

Then @svgeesus said:

• scaling OKLab a & b relative to L solely based on deltaE 2000 comparisons on the neutral axis picks the point of maximum CIELAB a & b asymmetry
• scaling based on some dataset of color pairs will depend on the distribution of mean chroma in that data set

Finally @bottosson said:

Small scale color distances show very strong elongation of spheres into ellipses:

[...]

It is also possible to much closer match the small color difference dataset as well, by introducing chroma compression, similar to what both CIEDE2000 and Ciecam02/16-UCS do, but that also adds quite a bit of complexity and assumptions on viewing conditions, this performs worse for tasks such as color interpolation

The discussion was in the context of changing Oklab, and that's no longer possible. For computing color distance, however, what's the takeaway from this? Is the "right" scale definitely something close to 2, or is "chroma compression" necessary to avoid the "very strong elongation of spheres into ellipses"?

[svgeesus]

For computing color distance, however, what's the takeaway from this? Is the "right" scale definitely something close to 2, or is "chroma compression" necessary to avoid the "very strong elongation of spheres into ellipses"?

The drawbacks of CAM16-like chroma compression (complexity, makes it worse for tasks like color interpolation (gradients color-mix()) seem to argue for the simpler uniform scaling.

I would like to see some experimental implementation and, ideally, results on other datasets including those with higher mean chroma, before a decision is made.

[svgeesus]

Needs more discussion and experience before this change is merged

[foolip]

I would like to see some experimental implementation

Do you mean implementation of this color distance method, or something that demonstrates that 2 is roughly the right number?

[svgeesus]

I mean something that demonstrates that 2 is the right number, for all real physical colors. We don't want to be changing the scaling factor again in a couple of years.

Sadly since @bottosson commented in 2021, colorio has become coloria and now requires a $50 per year license.

[foolip]

Some of this is unfamiliar territory to me, so let me first explain why I sent this PR.

I found it fascinating to learn from @bottosson that actually the a and b scales hadn't been carefully chosen, so Oklab isn't as perceptually uniform as it could be. And the shape of an RGB gamut or any volume in Oklab space is going to be wider and not as elongated as current visualizations. I'd like that nugget of information to be more easily discoverable from someone reading up on Oklab, and in particular anyone thinking about distances in the space.

Since we're only talking about compensating for the scale in ΔEOK and not changing Oklab itself, what are the consequences/risks? I think the only use of it is in https://drafts.csswg.org/css-color-4/#css-gamut-mapping, and that JND would need to be adjusted if we want the change to be a no-op. Are there others users of ΔEOK already that need to be aware of the change?

On the right number, I found it compelling that two different datasets gave very similar numbers, but don't know what's in those datasets. AFAIU, by including higher chroma samples in the dataset, the number would be different because those MacAdam ellipses are more stretched out. So the distribution of samples in the dataset is going to determine the number, but is there really an objectively correct distribution to use?

If we're not going to adjust for chroma compression with a non-linear function, is anchoring to "all possible surface colors" perhaps better than "all physically real colors"?

Or very concretely, if we had a coloria license, what dataset should be tested?

[svgeesus]

We have now tracked down the COMVB dataset (which is actually a merger of four earlier datasets). No-one seems to have the Xu et. al WCG dataset.

On the right number, I found it compelling that two different datasets gave very similar numbers, but don't know what's in those datasets.

It is, so around 2 would be a good starting point, but they are all standard-gamut colors, no wide gamut colors.

About changing the definition of DeltaEOK:

I think the only use of it is in https://drafts.csswg.org/css-color-4/#css-gamut-mapping, a

The only use of it in CSS, yes. CSSWG does not own DeltaE OK.

Are there others users of ΔEOK already that need to be aware of the change?

Certainly. And such a change would need to be made with @bottosson involvement and, ideally, announcing that change. I would also suggest calling it something like DeltaE OK2 to make it an opt-in rather than a possibly surprising change as people using it update their libraries.

[foolip]

I like the suggestion of making ΔEOK2 so that there's no ambiguity about what just "ΔEOK" means.

Are there additional datasets which could be tested here? Or something else I can do to make progress on this?

[svgeesus]

If we're not going to adjust for chroma compression with a non-linear function, is anchoring to "all possible surface colors" perhaps better than "all physically real colors"?

The Web is typically not consumed as printed media or physical objects. P3 screens are now widespread, and even sRGB has colors outside Pointer's gamut.

Here is BT Rec.709 which has he same primaries as sRGB

and here is DCI P3 which has the same primaries as Display P3

[svgeesus]

Here is the coverage of COMBVD (in black) compared to the two Xu et al WCG datasets (in red and green). Gamut of sRGB and P3 as guides.

[svgeesus]

I compared DeltaE vs DeltaE2 on the Sharma color-difference dataset

The CIEDE2000 Color-Difference Formula: Implementation Notes, Supplementary Test Data, and Mathematical Observations, G. Sharma, W. Wu, E. N. Dalal, Color Research and Application, vol. 30. No. 1, pp. 21-30, February 2005

[foolip]

Very cool, @svgeesus, putting the theory to the test. I'm not sure how to read the figure, does it reveal which method is "more perceptual" or "better" in some sense?

[svgeesus]

No, that one is just a simple sanity test of one against the other.

Next I intend to compare both against DeltaE 2000; greater correlation would imply greater perceptual uniformity as DeltaE 2000 is generally agreed to be very uniform (but also very complex and slow).

I have Implemented DeltaEOK2 in color.js so that it can be tested, including in gamut mapping.

[bottosson]

Certainly. And such a change would need to be made with @bottosson involvement and, ideally, announcing that change. I would also suggest calling it something like DeltaE OK2 to make it an opt-in rather than a possibly surprising change as people using it update their libraries

I think it makes sense to look at creating a "DeltaE OK2" since the error is as large as it is. I'm happy to announce the new distance once settled.

Regarding wide gamut colors: This will end up with some kind of tradeoff, if not introducing chroma compression. Without chroma compression tuning for differences close to a,b=0,0 will result in a different scale than tuning for higher chroma colors, and I don't think introducing chroma compression makes sense, it goes against the simplicity of Oklab.

I'm not convinced that it is best to tune for some kind of average across all possible colors rather than to just focus on more commonly occurring colors. Even if displays eventually reach the limits of the gamut of possible colors, the most common colors, and the ones where color distance will matter the most will be commonly occurring colors, those we see all the time in photos, graphical design etc, real world materials etc.

[foolip]

@svgeesus would you like me to send a PR adding ΔEOK2 as a new definition instead?

[svgeesus]

The PR is trivial and is not the limiting factor here.

@bottosson I started to investigate Macadam limits to generate a set of real-world (surface) colors. I was planning to generate perturbations in, say, CIECAM16 and then compare the deltaE 2000 of those pairs with the deltaOK and proposed deltaOK2; assumption being that a higher correlation meant it was a better distance metric. Does that seem a good approach?

[bottosson]

The PR is trivial and is not the limiting factor here.

@bottosson I started to investigate Macadam limits to generate a set of real-world (surface) colors. I was planning to generate perturbations in, say, CIECAM16 and then compare the deltaE 2000 of those pairs with the deltaOK and proposed deltaOK2; assumption being that a higher correlation meant it was a better distance metric. Does that seem a good approach?

Yeah, should work well to check the overall performance.

If you want to tune the constant rather than just check it, you need quite careful with the selection of test colors. Shouldn't matter much if just validating though.