- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Dec 2023 20:07:43 +0000
- To: public-css-archive@w3.org
> 2\. In step 10, defining `clip`, should we change it to specify it clamps to the range of the color channel, instead of 0-1? This may be a moot point, as it appears that only unbounded spaces which don't go through this portion have channel ranges besides 0-1. I notice that the [introductory text](https://drafts.csswg.org/css-color-4/#css-gamut-mapping) about the scope and applicability of the CSS GMA is in an inconsistent state. It started off as being widely applicable (for example, it used to be required before conversion to HSL and HWB). Explanatory notes were added to say that a different algorithm would be required: - for gamut mapping to a CMYK destination (because the destination black point is significantly lighter than sRGB black) - for gamut mapping of photographic images (to preserve local image detail, a perceptual GMA is needed which means that in-gamut colors can still be changed by the GMA) and so the section title describes the primary use case: [13.2. CSS Gamut Mapping to an RGB Destination](https://drafts.csswg.org/css-color-4/#css-gamut-mapping) Despite that, the pseudo-code is written to assume an arbitrary (colorimetric) destination color space, and the first line of the pseudo-code says what to do if `destination` is unbounded, such as XYZ-D65, XYZ-D50, Lab, LCH, Oklab, Oklch. And so, as you point out, what to do if `destination` is _bounded_ but the coordinate limits of in-gamut colors are not [0,1]. The suggestion to return [1 1 1 origin.alpha] was, I believe, [first made here](https://github.com/w3c/csswg-drafts/issues/6999#issuecomment-1025833319) and [a little later, here](https://github.com/w3c/csswg-drafts/issues/7135#issuecomment-1066121795) and in both cases I think an RGB color space whose gamut bounds are [0, 1] was assumed. In practice, for the color spaces defined in CSS Color 4, I think that is all that is left once (XYZ-D65, XYZ-D50, Lab, LCH, Oklab, Oklch) is excluded. Looking now (to check for upwards compatibility) at [CSS Color HDR](https://drafts.csswg.org/css-color-hdr/), then - [`rec2100-pq`](https://drafts.csswg.org/css-color-hdr/#valdef-color-rec2100-pq) is bounded at [0, 1] - [`rec2100-hlg`](https://drafts.csswg.org/css-color-hdr/#valdef-color-rec2100-hlg) is bounded at [0, 1] - [`rec2100-linear`](https://drafts.csswg.org/css-color-hdr/#valdef-color-rec2100-linear) has the SDR portion bounded at [0, 1] but can go higher. For example a 2000 nit super white is `color(rec2100-linear 9.852 9.852 9.852)`. - [`Jzazbz`](https://drafts.csswg.org/css-color-hdr/#jzazbz) is bounded [0, 1] on Jz and [-1, 1] on az and bz - [`JzCzHz`](https://drafts.csswg.org/css-color-hdr/#jzczhz) is bounded [0, 1] on Jz, [0, sqrt(2)] on Cz and [0,360] on Hz - [`ICtCp`](https://drafts.csswg.org/css-color-hdr/#ictcp) is bounded [0, 1] on I and [-1, 1] on Ct and Cp Looking too at what is in Color.js, - [`ACEScg`](https://colorjs.io/docs/spaces#acescg) is bounded [0, 65504] - [`ACEScc`](https://colorjs.io/docs/spaces#acescc) is bounded [-0.36, 1.47] I _think_ that there is value in keeping the wider generality of the CSS GMA, which does mean that continuing to specify `[1,1,1,origin.alpha]` will work for the "gamut map to RGB display" case, but is sometimes going to be incorrect in the wider case. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9651#issuecomment-1858429328 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 December 2023 20:07:45 UTC