←back to thread

What are OKLCH colors?

(jakub.kr)
856 points tontonius | 1 comments | 25 Aug 25 06:32 UTC | HN request time: 0s | source
Show context
fidotron ◴[25 Aug 25 10:56 UTC] No.45012490[source]▶
> 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.

replies(4): >>45013045 #>>45014039 #>>45014182 #>>45015574 #
crazygringo ◴[25 Aug 25 14:09 UTC] No.45014039[source]▶
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.

replies(1): >>45014278 #
nojs ◴[25 Aug 25 14:31 UTC] No.45014278[source]▶
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.
replies(1): >>45014468 #
crazygringo ◴[25 Aug 25 14:47 UTC] No.45014468{3}[source]▶
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.

replies(2): >>45017295 #>>45020835 #
dwringer ◴[25 Aug 25 18:35 UTC] No.45017295{4}[source]▶
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.
replies(1): >>45017928 #
crazygringo ◴[25 Aug 25 19:29 UTC] No.45017928{5}[source]▶
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.

replies(1): >>45017993 #
dwringer ◴[25 Aug 25 19:34 UTC] No.45017993{6}[source]▶
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

replies(1): >>45018605 #
1. crazygringo ◴[25 Aug 25 20:28 UTC] No.45018605{7}[source]▶
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.