- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Mon, 17 May 2021 16:35:23 +0000
- To: public-houdini-archive@w3.org
> Provide conversion between color spaces In rather more detail - it should provide conversion between any pair of colors, regardless of what colorspace each was specified in, provided that each colorspace has a colorimetric definition (so, table-of-measurements based colorspaces are excluded). That conversion should be automatic given the start and end points, without needing to specify a sequence of operations or additional data. For example when converting from `color(display-p3 n n n)` to `color(prophoto-rgb n n n)` the conversion must perform correct linearization before conversion to a linear-light exchange space like `XYZ`, must automatically compensate (Bradford chromatic adaptation) for the different white points of those two spaces, and perform the correct gamma-encoding on the linear-light result. _(I'm saying "like XYZ" because Canvas HDR plans to use linear-light Rec.2100 as the intermediate space, which should give the same result as XYZ provided there is no need for chromatic adaptation. Which with their limited choice of four colorspaces, there isn't - all are D65)_ The conversion should not needlessly apply steps that can be eliminated (for example, adapting from D65 to D50 and then immediately adapting back to D65 - very similar result but cumulative errors build up and can be problematic) However, being able to optionally specify additional detail (use CAT16 chromatic adaptation instead of linear Bradford, for example) _might_ be useful. But I think on balance that should be carefully justified, most of the time the defaults should be fine if well chosen. The matrix coordinates for conversions should be carefully tested such that long chains of conversions accumulate minimal errors. All conversions should use the same standardized values for white points, because using subtly different ones at different parts of the chain has been found to cause noticeable error. Both to avoid cumulative error and also to accommodate HDR (the way that Canvas plans to), and to accommodate WCG for situations (WebGPU) where everything is in one colorspace and so WCG is accomplished with out-of gamut values, there must be no clipping or gamut mapping of out of range values during intermediate operations. Clipping or gamut mapping should be explicitly requested, performed as late as possible (and both options should be supported). Gamut mapping using LCH chroma reduction with constant lightness is suggested as the optimal general purpose algorithm. As we are already excluding calibrated CMYK, there is no need to accommodate black point matching in gamut mapping. (HDR tonemapping should be treated separately). The case for allowing a custom gamut mapping operation should be considered. There is a lot of research work in this area, mostly concluding that different algorithms or color spaces are useful in some but not all cases, i.e. "it depends". So locking into a single choice would be unwise. There should be a mechanism for adding new (colorimetrically defined) colorspaces and getting auto conversion into and out of them. I'm thinking of OKLab, ICtCp for example here. Both adding by later standardization, and also adding with user code. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1040#issuecomment-842468083 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 17 May 2021 16:35:32 UTC