Force into gamut affects all channels?
Opened this issue · 7 comments
Most of tools I see (Adobe and Mac's Colour Meter) would just clip the channel outside the range, so lch(50% 100 100) would be shown as rgb(44% 49% 0%). I'm wondering why have you decided to go with locking LCH hue and lightness and changing chroma instead?
Changing chroma with fixed lightness and hue will still affect sRGB hue, especially at boundaries (right where you're aiming):
What do you mean by "sRGB hue"? Are you referring to HSL Hue? That isn't at all perceptually uniform.
To see why simple clipping produces hue shifts, consider rgb(200% 100% 0%) which has much more red than green. Per-component clip gives rgb(100% 100% 0%) with equal red and green.
To answer your original question: most tools which use gamut mapping do some sort of hue preserving (most important) lightness preserving (also important) and thus chroma or saturation is the least noticeable variable to change. For example, any tool which converts an image for printing will do chroma reduction so that the final image looks like the original, just less saturated.
First of all, I'm sorry to bug you with all these questions as I only found out about Lab color space and LCH from Lea's article couple months ago. The way I see color is there is a color space that might have couple models it is represented in, so sRGB space would have RGB, HSL, HWB models and the way I store information about the color is following:
// #f00;
sRGBColor {
alpha: 1,
blue: 0,
green: 0,
hue: 0,
lightness: 0.5,
red: 255,
saturation: 1,
}
LabColor {
a: 80.812,
alpha: 1,
b: 69.885,
chroma: 106.839,
hue: 40.853,
lightness: 0.54292,
}so in my vision hue is property of sRGB color space and I find it much more useful to store information about color in both models at the same time
Regarding rgb(200% 100% 0%) I get it theoretically, but in practice this color doesn't exists, as it will have out of range lightness and to fight it it has to have negative blue channel that will counteract against red channel.
Most of the times both approaches give colors that are practically indistinguishable or very close, but as you approach low or especially high lightness values things start to go off quite a bit with pinnacle at lightness of 100% when all colors are just white:
It clearly should be very yellow and by no means white.
Another example against chroma reduction: P3 Red (lch(56.205% 136.758 46.308deg)) corrects into rgb(95.09% 27.07% 0%) as seen here:
Same behaviour with all other primary colors
I’m gonna revive this older bug because I was just surprised by this behavior, too.
So lch(0%, 100, 0) is equivalent to color(sRGB, 0.37, -0.21, 0.03), which is obviously out-of-gamut. The LCH color picker on css.land does a more fancy conversion to force that color into the sRGB gamut and ends up showing black. However, both Safari TP and this LCH-to-sRGB converter on colormine.org simply clamp the values (i.e. color(sRGB, 0.37, 0, 0.03), which makes lch(0%, 100, 0) appear as a burgundy-like red.
Would it make sense to adapt this color picker to match the browser behavior? Or is Safari actually off here?
Side note: I also filed a spec bug because I think this tool is doing it right and Safari is wrong and the spec should be more prescriptive :D
lch(0% 100 0deg) is the same color as lab(0% 100 0) and there are a lot of color pickers and converters online that work with LAB color and they all roughly give #600009, including Adobe:
As much as common sense tells me that L* = 0 should yield to black regardless it reminds me of a red fish in the Fargo
The problem seems to be with XYZ to sRGB conversion: if you convert any XYZ(n, 0, n), where n larger than 0 it will produce color with luminance (Y) greater than 0.
With all that being said if I would have to pick between chroma reduction and clamping I still would go with clamping (Safari and Adobe are correct), because color(p3 1 0 0) appearing as orange is slightly bigger problem comparing to lch(0% 100 0deg) appearing rosewood-ish