You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would prefer a normative solution to the problem of handling "extreme" colors produced by oklab and oklch (e.g, the ones from #9449 (comment)), which gets us to "some very wide gamut".
The value as mentioned in that comment can be expressed in many different ways.
How are these affected when gamut mapping is limited to oklch and oklab notations?
Edit:
For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue.
Discussing limits to specific color spaces and/or color notations should be a separate issue.
The value as mentioned in that comment can be expressed in many different ways.
https://colorjs.io/apps/convert/?color=oklch(90%25%2090%25%200deg)&precision=4
For example with
hwb(329.3 10.37% -52.94%)
orlab(83.87 115.6 1.847)
.Implementing gamut mapping only for
oklab
,oklch
would be highly problematic.I immediately think of these :
oklch(from lab(83.87 115.6 1.847) l c h)
lch(from oklch(90% 90% 0deg) l c h)
color-mix(in lch, oklch(90% 90% 0deg), oklch(90% 90% 0deg))
How are these affected when gamut mapping is limited to
oklch
andoklab
notations?Edit:
For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue.
Discussing limits to specific color spaces and/or color notations should be a separate issue.
Originally posted by @romainmenke in #9449 (comment)
The text was updated successfully, but these errors were encountered: