141–150 of 189 posts
Earlier quoted context omitted.
Let's say you continuously change wavelength of a laser from blue (~480nm) to red (~630nm), you are going through green, not through gray. If in your use case going through gray makes sense, that's ok, there may be many paths from one color to another.
Shine a red and a green light near each other on a wall — what does the transition look like?
Earlier quoted context omitted.
I don't think you & I have much disagreement here as I like the way you write about approximations and edge cases and things involving human judgement calls and "both not either" kinds of testing. The WhyAPCA document you link to also includes language to such effect with sliding scales over regions & such. Me - I'm mostly asking questions not offering answers. That said, to correct the record.. >These examples are u…
There is no real difference between ratio and difference. It is just scaled with a logarithm. See https://blog.ce9e.org/posts/2022-09-10-contrast-algorithms/ for details.
The 2x2 table in that contrast experiments link I sent enumerates some differences along the edge cases { even with just |diff|s. }. Just empirically if you change that 0.05 to 0.02 or 0.10 things change "a lot" in terms of all the edge cases. You can try fiddling with running that Python script yourself and see.
Also, I believe the project of an actual "contrast measurement" - not merely threshold checking - is a worthy goal. I think it would be good to be able to say how bad, and for that the specific monotonic transformation absolutely matters, and again, I expect the color space designer people have opinions on this very worth listening to. I think they are targeting differences in the numbers being the most meaningful thing.
All that said, I did like your George Box quote. :-) I just don't think dismissing the problem is a great solution here. I'm not sure there is a great solution. But you & anyone are always free to find any problem uninteresting. I mean, you could also find all the color space distinctions of TFA similarly "no real difference".
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
> 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.
Earlier quoted context omitted.
Let's say you continuously change wavelength of a laser from blue (~480nm) to red (~630nm), you are going through green, not through gray. If in your use case going through gray makes sense, that's ok, there may be many paths from one color to another.
In general people don't really think of color in terms of the spectral progression (or the hue wheel), and I don't think that most people intuitively expect a gradient between two colors to pass through another "unrelated" primary or secondary color. The point is somewhat moot though, given that such gradients (like yellow to blue or red to green) are very unnatural anyway.
Earlier quoted context omitted.
> 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.
I'm saying HSL has the exact same shift as OKLCH. And neither is visibly green to me.
Earlier quoted context omitted.
Shine a red and a green light near each other on a wall — what does the transition look like?
There's no transition, this is color mixing, or overlay in case of light.
I suppose that's different with light than some analog with pigments? (Two dabs of color set apart, a brush perhaps used to blend them as continuously as is possible.)
The OKLCH lighter shade veers off into bright cyan! I don't see HSL getting grey on the dark side.
Earlier quoted context omitted.
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.
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.
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.