Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What are OKLCH colors?

jakub.kr

Post reply on HN
Print view View original

71–80 of 189 posts

Re: What are OKLCH colors?

#71

Post by adrian_b »

ksec wrote: post #60
chrismorgan wrote: post #43

Earlier quoted context omitted.

It’s just completely wrong. The first uses oklch(0.65 0.20 300), comfortably inside sRGB, not even at the boundary. The second uses oklch(0.65 0.28 300), which is well outside P3 and even Rec.2020. The smallest fix would be to make the second one oklch(0.65 0.2399 300) to bring it inside P3 so the demo doesn’t get slightly warped if Rec.2020-capable (not really necessary, but preferable, I’d say), and the first #a95e…

Sort of off topic questions, do we have any upcoming colour space beyond BT2020, now that we soon have monitor that reach 100% BT2020. I did some search and it doesn't seems to be any.

For any really bigger color space, you would have to use more than 3 primary colors, which would increase a lot the cost.

Moving the monochromatic BT.2020 colors from 630 nm, 532 nm and 467 nm could get a little increase in color space coverage, but at the expense of a lower efficiency in power consumption to brightness conversion. 467 nm is not a very pure blue, but the sensitivity of the eye drops very quickly in the blue region, so a better blue would require much more power. Similarly, though not so pronounced, for a different green.

Moreover, in the green region there is a gap, both for lasers and for LEDs, where the available devices have low efficiencies for converting electrical power to light, so changing the frequency of the primary green color would have to take that into account too.

In conclusion, I believe that the BT.2020 (actually BT.2100) color space is close to the best that can be done in displays of reasonable price and energy efficiency.

A true coverage of 100% of the BT.2100 color space can be realized only with laser projectors. Any display with LEDs or quantum dots will never have really monochromatic primary colors, though a coverage of significantly more than 90% of the BT.2100 color space is not too difficult. However, the advertised percentage of the color space may be misleading, because it varies depending on the kind of color space used for computations. A coverage percentage computed in OKlab would be more informative than a percentage computed in the XYZ color space.

Re: What are OKLCH colors?

#72

Post by layer8 »

djoldman wrote: post #69
chrismorgan wrote: post #7

The “Better Gradients” thing is dodgy. OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown: linear-gradient(in oklch, #f0f, #0f0) You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow: l…

But what really is a "color gradient"? Isn't it any continuous function that starts at a specified color and ends at another specified color? How then does one say that any gradient is good or bad? Isn't the problem you are highlighting guaranteed to exist for any colorspace that defines colors outside of human perception?

A good gradient is one that takes a perceptually uniform, and typically perceptually shortest, path. The OKLCH gradient isn't perceptual uniform and appears to take unnecessary detours through other hues.

Re: What are OKLCH colors?

#73

Post by layer8 »

ta8645 wrote: post #19
chrismorgan wrote: post #7

The “Better Gradients” thing is dodgy. OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown: linear-gradient(in oklch, #f0f, #0f0) You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow: l…

Very interesting. Is this just a limitation of our current hardware? How much of this problem would still exist if everyone had a wider gamut monitor, say full DCI-P3? That still doesn't cover the full gamut of Oklch, but would it make the problem practically disappear?

The underlying problem is that the color space humans can see doesn’t have nice uniform linear boundaries. The larger your color space, the more relevant that issue actually becomes.

Re: What are OKLCH colors?

#74

Post by seanwilson »

cb321 wrote: post #68
seanwilson wrote: post #48

Earlier quoted context omitted.

Maybe you've seen this but there's also https://github.com/Myndex/bridge-pca that does the "this color pair passes both APCA and WCAG2?" check in one pass.

As per discussion of this new OKLCH idea in TFA - Are we even sure we have great formulas for measuring/defining contrast in the first place? Do you agree / disagree with any of the counterexamples over at: https://github.com/tattoy-org/contrast-experiments

I'm not following. These examples are using the WCAG2 contrast algorithm which is well known to be flawed for people interested in this stuff, especially for dark themes so there should be lots of bad examples here? APCA is supposed to improve on this (see the example graphic comparing WCAG2 and APCA): https://git.apcacontrast.com/documentation/WhyAPCA.html

> But as @c-blake has rightly pointed out, this doesn't take into account the ratio of visible background pixels to foreground pixels. For example the contrast required for a single fullstop character, ".", is goting to be diffrent from a capital, "B".

So APCA includes more guidance on font weight and font size for more contexts (e.g. headings, body text, shorter text, copyright notices), but it's still going to be an approximation for edge cases like displaying a single fullstop character. If this case is common, you'd want to increase the contrast value instead of going with the minimum passing value, so the contrast algorithms can still help you.

There's a tradeoff with having guidelines that are very accurate (e.g. a contrast algorithm that counts pixels) vs simpler to follow (e.g. recommended font weight and size). People already find WCAG2 hard to follow as it is.

Re: What are OKLCH colors?

#75

Post by pavlov »

xg15 wrote: post #66
pavlov wrote: post #14

Earlier quoted context omitted.

He’s Swedish, so I bet OK is actually short for “Ottossons kulör” but he’s just being modest.

In the spirit of "Oll Korrekt", "Otto's Kolors"? How do you pronounce it, btw? "Oklich"? "okay L.C.H."?

Lich is an old word for a corpse (or in D&D mythology an undead magician).

An okay lich is like a chill corpse, maybe?

Re: What are OKLCH colors?

#76

Post by fidotron »

rafram wrote: post #70
fidotron wrote: post #59

> 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 per…

There’s no green shift at all in that example on my display. Could your calibration be off?

It's practically cyan, which is half way to green, not a lighter version of the blue to the left. This is on a MBP built in display.

This totally has uses but it is not, as claimed, "there is no hue or saturation drift" given the hue has shifted so much.

Re: What are OKLCH colors?

#77

Post by jakubkrehel »

chrismorgan wrote: post #7

The “Better Gradients” thing is dodgy. OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown: linear-gradient(in oklch, #f0f, #0f0) You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow: l…

This is super insightful, thank you! I wrote the article and will make changes to explain this better :)

Re: What are OKLCH colors?

#78

Post by adornKey »

The best axis for Lightness in my opinion is still the Gray-Scale (as used back in the day for black/white/grayscale TVs).

The newer CIE colorspaces (CIECAM02 CIECAM16) seem to address the effect, that color-perception goes wild if you change background and illumination. Oklab seems to only make some fixed choice about how to include the chromatic part to lightness. I'm not so sure, how this definition of lightness is any better than grayscale (from 1931).

Re: What are OKLCH colors?

#79

Post by cubefox »

chrismorgan wrote: post #7

The “Better Gradients” thing is dodgy. OKLCH is a polar coordinate space. Hue is angle in this space. So to interpolate hue from one angle to another, to get from one side of a circle to the other, you go round the edge. This leads to extreme examples like the one shown: linear-gradient(in oklch, #f0f, #0f0) You can also go round the circle the other way, which will take you via blue–aqua instead of via red–yellow: l…

> The red in that gradient is way darker than the rest of it.

It doesn't look significantly darker to me.

Re: What are OKLCH colors?

#80

Post by cubefox »

layer8 wrote: post #72
djoldman wrote: post #69

Earlier quoted context omitted.

But what really is a "color gradient"? Isn't it any continuous function that starts at a specified color and ends at another specified color? How then does one say that any gradient is good or bad? Isn't the problem you are highlighting guaranteed to exist for any colorspace that defines colors outside of human perception?

A good gradient is one that takes a perceptually uniform, and typically perceptually shortest, path. The OKLCH gradient isn't perceptual uniform and appears to take unnecessary detours through other hues.

One could also argue that the detour through other hues is necessary in this case to avoid going through grey.
Post reply on HN