What are OKLCH colors?

> In the example above, you can see that the OKLCH colors maintain consistent blueness across all of the shades, while in the HSL example, the lighter shades drift to purple and the darker ones muddy out towards grayish.

There is a very clear shift towards green in the OKLCH lightness value change example, enormously more so than any purple vibe in the HSL example.

Clearly being able to select colours of the same perceptual intensity has value, but some of the claims here as to the benefits are exaggerated.

You can see why by looking at the Hue chart for this color:

https://oklch.com/#0.7684,0.1754,218.1,100

To increase brightness past the limit of the Hue band for the color, the rendered output color on a display shifts cyan due to the limited brightness range of a saturated blue in the Display P3 color space. OKLCH is, when varying brightness along a gradient, Saturation-invariant rather than Hue-invariant; whether that effect is desirable is a matter of aesthetic preference, but after decades of Hue-invariant desaturated web color, it’s certainly refreshing to have a choice about which compromised invariance to take.

https://news.ycombinator.com/item?id=44588388

Science recently invented a much-deeper blue LED than we have now, so I expect in a decade or two, whatever ends up succeeding Display P3 will be much more able to represent that gradient without cyan-shift, and all of the years of OKLCH gradients created before that time will end up showing a more accurate blue gradient with only the colorspace change. In the meantime? Do whatever’s aesthetically pleasing; there is no Right Answer in design :)

ps. One could argue that a post-OKLCH colorspace should not accept the binary decision of Hue or Saturation invariance, and instead should be Saturation-invariant to the display’s native limit and then transition smoothly to Hue-invariance at that threshold. I believe that’s a Difficult Problem in color profile specification terms, since it isn’t just pre-calculating the changeover threshold for all monitors (not to mention, do you change blue sooner or same as red, etc) but it’ll be a while longer before I’m versed enough in ICCv4 to explain that perception. It sure would make for an interesting experimental DisplayCAL target, though!

> You can see why by looking at the Hue chart for this color

This misses the point: the example claims the hue isn't shifting, when it very clearly is. It's not a question of why.

The hue isn’t shifting in OKLCH at all; also, it’s definitely shifting when OKLCH is rendered to Display P3 or sRGB. This is normal and expected behavior for colorspace gradients when rendered to device profiles? But I suspect I’m too close to the problem to see what’s not explained properly, apologies.

No, it's not normal or expected for hue to change when rendering to a limited gamut.

It's normal and expected for saturation to change. And for brightness to get clipped. But not for hue to change.

That's the critique of OKLCH here, that changing hue is a bizarre and undesirable choice.

Your viewpoint of there being one true way of spectrum gradation under restricted device domains is not universally agreed upon; neither among designers, nor among the ‘normal’ population. No other way is the one true way, either! What works well for a PC sRGB display will be drab and lifeless on a laser cinema projection systems. Printers have faced this problem for centuries and innovated to use glass (long ago) and brushed-metal prints (more recently) as a way to regain control of luminosity independent of saturation and to express their design in less restrictive ways. The only ‘normal’ in this scenario is the shared agreements we make, and the primacy of sRGB’s desaturated brights as the sole exclusive agreement is ending.

(Since this reminded me of it, a random pro tip: For those using macOS Terminal.app, you can redefine the 16 ANSI colors using the full P3 colorspace, so long as you use the full GUI color picker rather than the sRGB-limited #rrggbb entry method. Access to improved saturation helps the eye distinguish different shades in the dim and bright color sets more effectively without having to alter their brightness. It won’t improve the limitations of ANSI color as a whole — the insistence on Luminosity = f(R,G,B) is baked into everyone’s assumptions quite deeply thanks to sRGB! — but it does at least mean you can have seven equidistant and non-desaturated, non-sRGB colors at two levels of brightness for syntax highlighting and other typical 16-color uses.)