[crazygringo]

Agreed. The hue changes completely from blue to cyan.

If that's a correct implementation of OKLCH, then it's not something I would ever touch. Something seems to be deeply wrong with however they're calculating hue.

HSL/HSV have issues with perceptual lightness. But not with hues. The hue is constant and doesn't need any correction depending on saturation or lightness.

[nojs]

I think you do usually want to rotate the hue a bit when changing the lightness though. It’s a difficult thing to get right and one of the reasons the tailwind builtin colour palettes are so useful.

[crazygringo]

You don't. That's not something graphic designers ever do as compensation for perceptual uniformity.

I looked into it a bit more, and it turns out it's a result of OKLCH easily producing colors out of gamut, and then choosing to sacrifice hue accuracy for better saturation accuracy.

That's a fundamental design flaw if you ask me. Changing hue is completely unacceptable in my book.

[nojs]

In "Refactoring UI" [1] (by the creators of tailwind) they recommend when designing your shades for a single base colour:

> Since different hues have a different perceived brightness, another way you can change the brightness of a color is by rotating its hue.

> To make a color lighter, rotate the hue towards the nearest bright hue — 60°, 180°, or 300°.

> To make a color darker, rotate the hue towards the nearest dark hue — 0°, 120°, or 240°.

> This can be really useful when trying to create a palette for a light color like yellow. By gradually rotating the hue towards more of an orange as you decrease the lightness, the darker shades will feel warm and rich instead of dull and brown

You could argue whether this is "perceptual uniformity" or something else, but the fact is that to create a realistically useful colour palette with a bunch of shades, you definitely cannot simply use HSL, keep the hue constant, adjust S/L. It's not that easy (and OKLCH doesn't make it that easy either).

1. https://www.refactoringui.com/

[dwringer]

sRGB is already not perceptually uniform. These hue changes already happen. Just because the H value in HSL/HSV doesn't change doesn't mean there's no perceptual hue shift when adjusting lightness/value.

[crazygringo]

I don't know what you're talking about -- that isn't true.

There is absolutely no perceptual hue shift in the HSL/HSV models depending on saturation and lightness/value, or when they get translated into sRGB. That's the entire point of HSL/HSV, to isolate hue and hold it constant.

HSL/HSV are not perceptually uniform in terms of brightness when hue is changed, or even brightness linearly. But hue is hue. Perceived hue does not change based on brightness or saturation.

[dwringer]

There most definitely is perceptual hue shift in HSL (and HSV); it's illustrated quite well at [0](The blog of the creator of OKLab), particularly in [1], an image showing S and L axes while leaving H fixed.

[0]https://bottosson.github.io/posts/colorpicker/

[1]https://bottosson.github.io/img/colorpicker/hsl_blue.png

[crazygringo]

Well I'll be damned, you're right -- I'm playing with it in Photoshop now, and it seems to be exclusive to hue values of 233-270, in the transition from blue to purple, and nowhere else. Matches what [0] says -- "This is particularly obvious for deep blue and purple colors."

So first, thank you for the correction. It's fantastic to learn something new. And second, do you have any idea why the OKLCH example on the page is so atrociously bad? The way blue changes to cyan is even worse than the HSL/HSV difference of blue-purple. It's like the cure is worse than the disease. If they were so concerned with hue fidelity in the first place, I'm surprised they wound up producing an end result just as bad.