-
Notifications
You must be signed in to change notification settings - Fork 18
Force into gamut affects all channels? #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 |
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. |
I’m gonna revive this older bug because I was just surprised by this behavior, too. So 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 |
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 asrgb(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):

The text was updated successfully, but these errors were encountered: