Re: [csswg-drafts] [css-color-4] Need a future-proof way to adjust lightness of a color (#10110)

The `okhsl` space can express an arbitrarily wide gamut with `S` coordinates above `100%`.

For that particular color, for the particular operation that I was doing, it works quite well. Performing `okhsl(from color(display-p3 1 0.5 0.5) h s 90%)` gets us the color `color(display-p3 0.9946 0.8428 0.8328)`, which is quite reasonable.

Over in [the page](https://bottosson.github.io/posts/colorpicker/), the computation is just "keep doing what you were doing up to the boundary of the gamut"
```
 if (s < mid) {
   ... C = t * k_1 / (1.f - k_2 * t);
 } else {
  ... C = k_0 + t * k_1 / (1.f - k_2 * t);
 }
```
For some values that really ramps out quickly. That color `color(display-p3 1 0.5 0.5)` is one such example -- it has something like `S=495%` (according to colorjs.io), which is a bit much, and has problems for `L` substitutions at other values. The color `color(display-p3 1 0 0)` is an example that isn't. It maps to `okhsl(28.96 108.1% 59.19%)`.

I think it would be a good idea to update `okhsl` have a more controlled expansion after `S>100%` so that, say, Rec2020 be contained within `S<=150%`, and also to include the aforementioned `100%` means P3/Rec2020 variants.

-- 
GitHub Notification of comment by ccameron-chromium
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10110#issuecomment-2012155755 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 21 March 2024 12:28:41 UTC