Re: [csswg-drafts] [css-color] [filter-effects] Should no-op filters produce different output from no filter? (#7100)

> my feeling on this issue is that we should add a feature to the web where the "working color space" of an element may be specified.

Already considered:

- https://github.com/w3c/csswg-drafts/issues/300
- https://github.com/w3c/csswg-drafts/issues/481
- https://github.com/w3c/csswg-drafts/issues/3844

and rejected because, as you said:

> There is no "right" space for interpolation for all applications (the main dividing line is content to have luminance that is physically linear versus perceptually uniform).

So yes, the appropriate colorspace depends on the operation being done so will vary for different properties on a given element as one size does not fit all. Basically the choices come down to:

1. Linear-light for simulating physical properties (CIE XYZ is a good choice here, linear-light sRGB also gives the same result as long as extended values (outside 0-1) are handled without clipping). This is what compositing should use, but doesn't; it is what svg filters use, except clipped to the sRGB gamut due to the age of the spec.
2. Perceptually linear, either rectangular or polar, where midpoints of an interpolation need to be visually in the middle of the two colors being interpolated. OKLab is the best choice here although CIE Lab is also acceptable. This is what CSS Gradients use, for non-legacy color formats or by opt-in.
3. Gamma-encoded sRGB or indeed gamma-encoded display RGB, if backwards compatibility is a more import a concern than either linear-light or perceptual linearity.

> An issue that came up here is "what precision should we provide?". When exposing "display-p3" to Canvas2D, this was also a concern. The phrasing there came out as: Should the selection of a buffer's color space imply a certain precision for that buffer? That was a hard question, and we punted by only exposing "display-p3", where, like "srgb", the most reasonable default would be 8-bit-per-color 

That was a good choice for Canvas, given that dealing with greater than 8 bits per component was deferred until later. For the `color()` syntax in CSS Color 4, the required precision per colorspace is [listed in the spec](https://drafts.csswg.org/css-color-4/#serializing-color-function-values). Note that compared to Canvas, which needs to store color values per-pixel, in CSS there is a need to only store color values per property declaration, greatly reducing the memory impact.

> (we excluded "rec2020" both because the transfer function for it had some contention, 

that issue was [solved a while ago](https://drafts.csswg.org/css-color-4/#serializing-color-function-values)

> but also because 8-bit-per-color is not a reasonable default for that space). 

Right - it needs minimum 10, preferably 12 bits and Rec BT.2020 gives values for 10bit, 12bit and float representations.

> For a space like "srgb-linear", 8-bit-per-color is very-not-good. 

Right. 12 is the minimum here, to round-trip all 265 gamma-encoded 8 bit values.

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


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

Received on Thursday, 5 May 2022 20:25:42 UTC