really glad to see this released, because it will help popularize the new lch/oklch color spaces, which are an improvement over rgb/hsl.
with that said, i did some experimentation with these new color spaces recently and found that even these are not foolproof for those of us who don't want to be steeped in the depths of color spaces and human perception. for instance, mentioned in the article is automatic gamut mapping for when you try to display a color that's outside the gamut. seems like that's a good thing since it would take care of some rare edge cases, right?
no, the edge cases are all over the place. the gamut "depth" is dependent on the component values (like lightness and chroma), so if you want to go from a light red hue to a light yellow hue, you can't just change the hue component, because the lightness and chroma values might put the target color out of bounds. that's where the automatic gamut mapping kicks in. but guess what? the various browser engines currently have their own algorithms, and they that don't pick the same nearby colors.
the evil martians oklch color picker[0] shows this visually. if you look at the hue vs. lightness graph, notice how jagged the (planar projection of the) gamut is there. for any given horizontal line (constant lightness), you might end up out of bounds on the chroma component for a chosen hue. this can happen in any of the 3 dimensions.
also, while oklch is more perceptually even generally, there are gradient examples where it's not much better (i think orange/brown gradients is one of those cases, but i'm not certain, offhand). color is apparently quite hard, so i'm not knocking the effort or the improvements, but there are still some gotchas remaining for designers/developers.
the gamut "depth" is dependent on the component values (like lightness and chroma)
This is an unavoidable bug (feature?) of human vision and computer displays.
Using models like "HSL" or "HSV" is a way of trying to sweep it under the rug, but it doesn’t really work very well and ends up causing a lot more trouble.
yah, visual perception isn't uniform in all directions, but i believe it's more that those distortions (the kinks and valleys) comes from trying to make the color space perceptually even to humans (and human perception has variation as well). however, there's no perfect way of doing this in all vector directions, so it's a multi-dimensional optimization problem that can only minimize distortions/maximize evenness, rather than provide a singular best analytical solution. as a result, the color space comes out like a spikey blob, to match our numerical color scales to human perception, since the opposite of coercing human perception onto uniform color scales is not feasible.
Comments
really glad to see this released, because it will help popularize the new lch/oklch color spaces, which are an improvement over rgb/hsl.
with that said, i did some experimentation with these new color spaces recently and found that even these are not foolproof for those of us who don't want to be steeped in the depths of color spaces and human perception. for instance, mentioned in the article is automatic gamut mapping for when you try to display a color that's outside the gamut. seems like that's a good thing since it would take care of some rare edge cases, right?
no, the edge cases are all over the place. the gamut "depth" is dependent on the component values (like lightness and chroma), so if you want to go from a light red hue to a light yellow hue, you can't just change the hue component, because the lightness and chroma values might put the target color out of bounds. that's where the automatic gamut mapping kicks in. but guess what? the various browser engines currently have their own algorithms, and they that don't pick the same nearby colors.
the evil martians oklch color picker[0] shows this visually. if you look at the hue vs. lightness graph, notice how jagged the (planar projection of the) gamut is there. for any given horizontal line (constant lightness), you might end up out of bounds on the chroma component for a chosen hue. this can happen in any of the 3 dimensions.
also, while oklch is more perceptually even generally, there are gradient examples where it's not much better (i think orange/brown gradients is one of those cases, but i'm not certain, offhand). color is apparently quite hard, so i'm not knocking the effort or the improvements, but there are still some gotchas remaining for designers/developers.
[0]: https://lch.evilmartians.io/
This is an unavoidable bug (feature?) of human vision and computer displays.
Using models like "HSL" or "HSV" is a way of trying to sweep it under the rug, but it doesn’t really work very well and ends up causing a lot more trouble.
yah, visual perception isn't uniform in all directions, but i believe it's more that those distortions (the kinks and valleys) comes from trying to make the color space perceptually even to humans (and human perception has variation as well). however, there's no perfect way of doing this in all vector directions, so it's a multi-dimensional optimization problem that can only minimize distortions/maximize evenness, rather than provide a singular best analytical solution. as a result, the color space comes out like a spikey blob, to match our numerical color scales to human perception, since the opposite of coercing human perception onto uniform color scales is not feasible.