[refulgentis]

It's sort of way outrun it's initial premise: it's lightness channel is inverted compared to every other color space, and it's L has nothing to do with LCH or LAB. It's success brought more intellectual poverty, unfortunately. The initial blog post needs a laundry list of corrections, it goes off the rails when it starts making claims about accuracy based on gradients using CAM16 UCS.

[AprilArcus]

Have the errata been collected anywhere?

[refulgentis]

No, it's a really interesting situation, doesn't directly claim to have lightness like Lab/LCH, or that there's something fundamentally good about having a blue-yellow gradient. But the L thing is crucial for WCAG (c.f. article), and designers, and the blue/yellow stuff is interesting.

- it's _not bad_ Its better than HSL in that its lightness is correlated to "true lightness", and it's __much__ simpler to implement than a more complex thing like HCT's CAM16 x L. That's about 500 LOC, versus 15 I'd guess. And substantially faster too, few mat muls in each direction.

- Oklab L is not L: The problem for engineers and designers: no relation to LAB L*/XYZ Y, so no correlation to WCAG.

The problem on the designers end: it's not a linear ramp in dark to light visually. This usually goes unnoticed in a cross-disciplinary scenario unless you're really going deep into color, designers are used to working under eng. constraints.

- Color space accuracy / blue and yellow gradient:

It's a warning sign, not a positive sign, if a color space _isn't_ gray in the middle of a blue to yellow gradient. They're opposites on the color wheel and should cancel out to nothing. Better to instead note the requirement that you don't want gray gradients, and to travel "around" the colorspace instead of "through" it, i.e. rotate hue to make the gradient, travelling along the surface of the colorspace, rather than going into the color space, reducing colorfulness.

[arthur2e5]

> Oklab L is not L: The problem for engineers and designers: no relation to LAB L*/XYZ Y

That should not be considered a bug by itself. CAM16-UCS lightness J also does not depend only on XYZ Y.

> no correlation to WCAG

Y does not necessarily have to be the standard used by WCAG (see CAM argument). And a stick that's a little skewed is still very well correlated with an upright stick, statistically speaking.

> The problem on the designers end: it's not a linear ramp in dark to light visually.

Now that is the actual issue which has nothing to do with which variables L depends on. The L_r (lightness with reference) derived from L is designed to deal with that: https://bottosson.github.io/posts/colorpicker/

[refulgentis]

> That should not be considered a bug by itself. CAM16-UCS lightness J also does not depend only on XYZ Y.

I avoided the word bug, I believe. Let's say someone else claims it is. I would advise it is not a bug, but the absence of a feature. And that I'd struggle to come up with a good reason to switch away from HSL without that feature. If you're just picking colors, HSL is fine. The process advantage and magic is built-in "oh I know this color passes a11y with this one without guessing" is ___huge___. At least at BigCo, you can't skip a11y.

> Y does not necessarily have to be the standard used by WCAG (see CAM argument).

Sure, but it is used by WCAG and that's important: see above. Also, there's a reason Y has survived since 1900, and it's not because it's an arbitrary decision.

> And a stick that's a little skewed is still very well correlated with an upright stick, statistically speaking.

I assume it's a reference to the shape of Oklab's L, but I'm not sure if you meant that, so apologies if this sounds aggressive because it's not what you meant / I'm repeating another comment: Oklab's L is not Lab's L, and it's not close, and when you plot Oklab's L versus any other color spaces its very oddly shaped. This isn't a problem for an engineer or color scientist, but it is a problem for a designer.

> Now that is the actual issue which has nothing to do with which variables L depends on.

I agree that if we say "well WCAG could use any lightness measure" and decide we'll switch away from HSL to an arbitrary color space because the science on spatial frequency might be rewritten or WCAG may divorce itself from it completely, that we can completely write off a11y as a non-goal.

[arthur2e5]

> Also, there's a reason Y has survived since 1900, and it's not because it's an arbitrary decision.

1931. And Y is known to be problematic since Judd (1951) and Vos (1978), with the latest approach being the Stockman & Sharpe 2005 "fundamental" redefinition. This error has real bearing on how narrow-spectrum display works.[1]

[1]: https://sensing.konicaminolta.asia/wp-content/uploads/2018/0...

> I assume it's a reference to the shape of Oklab's L... not close

The "a little skewed" refers to the shape of the L (or CAM "J") axis projected into the 3D XYZ space, not how the values are scaled in 1D (which I have addressed separately as L_r). They will not perfectly match the Y axis and appear bent, even skewed, because they don't just mathematically depend on Y. But they will be quite close and score a good (> 0.90, I guess) correlation coefficient over a set of color samples because they are trying to model the same aspect of human vision. That is still good correlation, and given the limited nature of gamuts you'd still be able to derive some sort of "this much difference means at least this much ratio".