4 ms·

> 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 dr

> 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.

rafram 1y ago
There’s no green shift at all in that example on my display. Could your calibration be off?
- fidotron 1y ago
  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.
- jibal 1y ago
  There certainly is ... run a color picker over it.
  - rafram 1y ago
    I opened the macOS Digital Color Meter and set it to "native values" mode. The second-to-last OKLCH swatch has a green component of 202, and the last has a green component of 226. The corresponding values in the HSL swatches are 203 and 227. Basically no difference at all.
    - crazygringo 1y ago
      > The corresponding values in the HSL swatches are 203 and 227. That is a gigantic difference. Those are totally different hues. Which are, of course, exactly the difference we're seeing.
      - rafram 1y ago
        I'm saying HSL has the exact same shift as OKLCH. And neither is visibly green to me.
        deleted 1y ago
        [deleted]
        gowld 1y ago
        It's visibly cyan, isn't it? It's maybe not an intuitive "green" hue (depending on your linguistic culture), but it's clearly different from all the other colors on that chart.
crazygringo 1y ago
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 1y ago
  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 1y ago
    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.
    - dwringer 1y ago
      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 1y ago
        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.
altairprime 1y ago
You can see why by looking at the Hue chart for this color: https://oklch.com/#0.7684,0.1754,218.1,100 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 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!
- fidotron 1y ago
  > 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.
  - altairprime 1y ago
    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.
throwaway0123_5 1y ago
I don't know much about the science of colors and I imagine this is going to be very subjective but I would at "worst" describe the rightmost OKLCH color as blue-green (but probably just "light blue"). Meanwhile the two rightmost HSL colors I would not describe as blue at all. Second from right I would call "light purple" and the rightmost honestly looks grey to me (which is weird because the caption says the darker HSL values "muddy out towards greyish" but the leftmost values for OKLCH and HSL both look pretty blue to me). Also if I use the macOS app "Digital Color Meter" I get essentially the same green value for the rightmost OKLCH and HSL colors (226 and 227 for "display native values" and 228 and 227 for sRGB).

rafram 1y ago

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

fidotron 1y ago
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.
jibal 1y ago
There certainly is ... run a color picker over it.
- rafram 1y ago
  I opened the macOS Digital Color Meter and set it to "native values" mode. The second-to-last OKLCH swatch has a green component of 202, and the last has a green component of 226. The corresponding values in the HSL swatches are 203 and 227. Basically no difference at all.
  - crazygringo 1y ago
    > The corresponding values in the HSL swatches are 203 and 227. That is a gigantic difference. Those are totally different hues. Which are, of course, exactly the difference we're seeing.
    - rafram 1y ago
      I'm saying HSL has the exact same shift as OKLCH. And neither is visibly green to me.
      - deleted 1y ago
        [deleted]
      - gowld 1y ago
        It's visibly cyan, isn't it? It's maybe not an intuitive "green" hue (depending on your linguistic culture), but it's clearly different from all the other colors on that chart.

crazygringo 1y ago

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 1y ago
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 1y ago
  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.
  - dwringer 1y ago
    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 1y ago
      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.

altairprime 1y ago

You can see why by looking at the Hue chart for this color: https://oklch.com/#0.7684,0.1754,218.1,100 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 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!

fidotron 1y ago
> 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.
- altairprime 1y ago
  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.

throwaway0123_5 1y ago

I don't know much about the science of colors and I imagine this is going to be very subjective but I would at "worst" describe the rightmost OKLCH color as blue-green (but probably just "light blue"). Meanwhile the two rightmost HSL colors I would not describe as blue at all. Second from right I would call "light purple" and the rightmost honestly looks grey to me (which is weird because the caption says the darker HSL values "muddy out towards greyish" but the leftmost values for OKLCH and HSL both look pretty blue to me). Also if I use the macOS app "Digital Color Meter" I get essentially the same green value for the rightmost OKLCH and HSL colors (226 and 227 for "display native values" and 228 and 227 for sRGB).