- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Dec 2020 16:17:10 +0000
- To: public-css-archive@w3.org
> For something like CSS colors, each color should be treated independently; making the result depend on surrounding colors is going to be counterintuitive and confusing. Agreed. > If the source colors are in CIELAB or the like, then the only reasonable thing to do IMO is leave in-gamut colors alone and clip the out-of-gamut colors to some point on the gamut boundary, hopefully along a direction that preserves intended color attributes as well as possible. Yes. > Plausible methods for reducing colorfulness to bring out-of-gamut colors inside include mapping inward along a constant hue/lightness line, mapping with constant hue toward middle gray, or mapping with constant hue toward a gray whose lightness depends on the hue. Yes, the first of those is the plan. We have [implemented this in color.js](https://colorjs.io/docs/gamut-mapping.html) and it seems to work well. In brief, work in CIE LCH and reduce Chroma (thus preserving Hue and Lightness) until a point "close" to the gamut boundary is reached. Closeness is determined by computing the DeltaE2000 between the current reduced-Chroma color and a per-component-clipped copy of the current reduced-Chroma color. This avoids excessive Chroma reduction caused by skating along the top of the gamut surface, especially with slight concavities. > Per-component clip does not give good results at all but instead dramatically distorts all color relationships and tramples on authors’ intentions, unless colors are so close to the gamut boundary that the clipping is trivial. Agreed. Per-component clip is a terrible method which, currently is mandated (from CSS Color 3). The approach described above judiciously applies clip in the trivial case you mention. > Gamut mapping should be done in some color space that more or less separates hue/value/chroma cleanly in a way that matches human perception. CIELAB works okay but the blue–purple shift can be annoying sometimes. CIECAM02 and IPT are both decent in my experience. I haven’t experimented with other possibilities. I have [studied](https://svgees.us/ICC%20July%202020/Towards%20an%20HDR-capable%20ICC%20PCS.html) the blue hue non-linearity in CIE LCH and compared with Jzazbz [1](https://www.osapublishing.org/oe/fulltext.cfm?uri=oe-25-13-15131&id=368272) which was different but not better; I have implemented IPT but not yet run the study. I would avoid CIECAM02 for two reasons: firstly because the required information for 10 degree surround, ambient luminance, and surround is not available which means that default values are used, collapsing it from a color appearance model into a simple colorimetry model; and secondly because of numerical instability and non-invertibility as [discussed here](https://www.researchgate.net/publication/246407910_ICC_color_management_and_CIECAM02). CIECAM16 solved the latter problem but not the former one. > People interested in this topic should read Ján Morovič’s monograph. Yes, I have it and it is very helpful. Much of it relates to the gamut mapping of photographic images, which does not apply directly to colors in CSS for the reason you mentioned, but it is a valuable work. > I don’t think stuff like “saturation” intent (at least, in any way I have ever seen it interpreted) deserve attention at all. Yes, it seems completely useless; "I want these colors as saturated as possible but don't care what colors they are" might have been relevant to 1990s Harvard Graphics charts but certainly isn't now. [1] An Efficient Uniform Color Space for High Dynamic Range and Wide Gamut Imagery. Safdar, Muhammad; Luo, M Ronnier. Optics Express Vol. 25, Issue 13, pp. 15131-15151 (2017) https://www.osapublishing.org/oe/fulltext.cfm?uri=oe-25-13-15131&id=368272 -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5191#issuecomment-736656374 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 December 2020 16:17:14 UTC