-
-
Notifications
You must be signed in to change notification settings - Fork 82
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
Gamut mapping: clarification of chroma reduction algorithm #63
Comments
@danburzo just a confirmation that we are looking into it. Unfortunately, at the present time we have four findings:
So - perplexed, needs to be fixed, will continue to look at it. |
Thanks for the update! I wanted to experiment a bit in this area, but I had to pick up some things and was unable to investigate further... I'll post back if I find anything interesting myself. |
Note that CSS Color 4 now describes gamut mapping. Much of that is just explanation, but it is followed by the actual algorithm which is constant-lightness, constant-hue chroma reduction in OKLCH using deltaE OK as the difference metric. |
Hi @svgeesus, I'm only just now picking this up. I've started implementing the gamut mapping algo, and I have some feedback. Is this an appropriate venue for it, or shall I post it to csswg-drafts directly? |
If the feedback is about what CSS Color 4 defines (or, should define) for gamut mapping in CSS, please leave the feedback on the CSSWG repo. If the feedback is specific to what color.js does - it will certainly offer the CSS algo as an option, probably as the default option, but can also offer other options - then this would be the best place. see also w3c/csswg-drafts#7135 (comment) where a better option for CSS is being explored. |
I would like to prototype the CSS Color 4 gamut mapping algorithm in color.js and have it available as an option. (It should probably the default, as it is clearly better than CIE LCH chroma reduction). |
It seems to me the current Color.js In regards to the algorithm itself, I believe the binary search optimizations it bakes in are still slightly unintuitive, but since it’s functionally equivalent to the simplified “roughly in gamut” idea (as I point out here), it’s more of a nitpick at this point. I consider the algorithm sufficiently clarified. |
Thanks @danburzo, I’ll close this then but please do not hesitate to open a new issue if needed. |
Hello, I'm coming to the repo from @svgeesus's comment regarding color clamping in the CSSWG repository. I've finally had the chance to look into the proposed algorithm, and I just wanted to confirm some details.
A basic bisection method for reducing the LCH chroma:
color.js
compares the color at each iteration with its clipped version:The current implementation seems to have diverged from the description in the docs:
At a first pass through the function, what I see is the definition of
displayable()
/inGamut()
relaxed to include colors at a deltaE2000 distance smaller than 2 to an in-gamut color (which, even by itself, sounds like a great idea). What I'm not seeing, unless I'm missing something, is how the conditionMath.abs(deltaE - 2) < ε)
can ever be fulfilled (and the clipped color returned early) withoutdeltaE - 2 < ε
catching it first.The text was updated successfully, but these errors were encountered: