CSS Color: lab(), lch()

[felipeerias]

Hola TAG!

I'm requesting a TAG review of:

• Name: lab() and lch() CSS functions for colors.
• Specification URL: https://drafts.csswg.org/css-color-4/#specifying-lab-lch
• Tests: https://github.com/web-platform-tests/wpt/tree/master/css/css-color
• Primary contacts:
  • CSSWG for the specification
  • @felipeerias for the Chromium implementation
• Organization driving the specification: CSSWG
• External issue trackers:
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1026287
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1352757
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=205675

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify

[dbaron]

Do you mean lch() rather than lhr()?

I'd also cc @svgeesus here as the primary contact for the spec.

[felipeerias]

Do you mean lch() rather than lhr()?

Sorry, yes, of course :)

[dbaron]

I think one thing we should perhaps look at is whether other parts of the Web platform (e.g., canvas) need things to prepare for colors that are outside of the sRGB gamut.

[felipeerias]

There is an ongoing discussion at the intent-to-prototype thread about which other parts of the spec still need some work:

https://groups.google.com/a/chromium.org/d/topic/blink-dev/iwsT-jkCQcI/discussion

And there are open issues at the CSSWG with different levels of consensus for topics such as:

• working color spaces ([css-color] Working Color Space w3c/csswg-drafts#300)
• rendering colors outside the sRGB gamut ([css-color-4] Should lab() colors which are outside the sRGB gamut be rendered on capable displays? w3c/csswg-drafts#4646)
• interpolation in non-sRGB color spaces ([css-color-4] Do gradients/animations using lab/lch colors interpolate in the Lab colorspace? w3c/csswg-drafts#4647)
• etc.

My main question at the moment is whether it would make sense to implement Lab-like selection and interpolation using the browser's existing color infrastructure (i.e. with clamped outputs), or whether it would be necessary to spec and implement general support for wider gamuts first.

A related question is whether there could be a path from those clamped lab() and lch() functions to their wide-gamut versions (if/when they are supported by the browser).

[svgeesus]

@dbaron, thanks for cc'ing me into this issue.

I think one thing we should perhaps look at is whether other parts of the Web platform (e.g., canvas) need things to prepare for colors that are outside of the sRGB gamut.

Yes, they do. This was discussed previously in TAG review although that issue stalled on waiting for responses from the original poster.

The Color on the Web Community Group is working on a draft report for HDR on the Web; although the focus is on HDR, Wide Color Gamut is also being examined and all parts of the web platform will need some changes to get outside the sRGB gamut while maintaining both backawrds compatibility and future extensibility.

@felipeerias wrote:

My main question at the moment is whether it would make sense to implement Lab-like selection and interpolation using the browser's existing color infrastructure (i.e. with clamped outputs), or whether it would be necessary to spec and implement general support for wider gamuts first.

Good question From discussions with @tabatkins I understood that Chromium infrastructure had an internal datatype, a 16bit scRGB which (because it can go below 0.0 and above 1.0) could in principle be used to express a wider gamut than sRGB?

[svgeesus]

In case it helps TAG review, CIE Lab (the rectangular form) and LCH (the polar form) were standardized in 1976 by the International Lighting Commission (CIE). It then became an International Standard and was jointly published with ISO. The latest edition of that reference is

ISO/CIE 11664-4:2019(E): Colorimetry — Part 4: CIE 1976 Lab* colour space. 2019.
Published. URL: http://cie.co.at/publications/colorimetry-part-4-cie-1976-lab-colour-space-1

Lab is widely used in the paint, printing, and film industries. It is used as an interchange space, and commercial instruments exist to measure it. For example, making a color profile for a particular printer, ink and paper combination consists of printing a large number of swatches with combinations of the inks used, then measuring the Lab values with a spectrophotometer. These measurements are then used to construct an inverted 4D (for CMYK) lookup table to calculate in the reverse direction - given a Lab color, what combination of inks wil give the closest measured result?

So Lab and LCH are well proven in both standardization and in industry practice. The question for the TAG is how best to integrate these with the Web platform.

In terms of implementer interest, Apple is currently implementing in WebKit for Safari, using their existing ColorSync architecture (an implementation of ICC profiles). BFO is implementing for their CSS/HTML to PDF product, and I see that @felipeerias is now evaluating whether and how to do this for Chromium. I'm not aware of any public signals from Mozilla.

[felipeerias]

Thank you, @svgeesus

In Chromium, Blink parses CSS color values into a 32-bit ARGB data type, which are eventually handed over to the Skia library to carry out the actual drawing (using its own 32-bit ARGB type).

Interestingly, Skia does support wider color gamuts (see "Color Correct Skia") and many of its methods can optionally take high precision colors (four floats plus a color space).

The problem that I am working on at the moment is that very little code in Chromium uses Skia's high precision colors, and Blink does not use them at all. In other words, the code that actually draws Web pages uses 32-bit ARGB colors throughout.

As far as I could see, Chromium's support for wider gamuts seems limited to selecting a specific color profile (scRGB linear, P3, etc.) instead of the one specified by the operating system. There isn't support at the moment for using a wider color gamut for individual Web elements.

I'm still studying the code and doing experiments, looking for a path forward that could be tackled (or at least started) by a one-volunteer effort.

[dbaron]

So we had a bit of a brainstorm in the TAG's breakout B today as to what issues we think it would be useful to review for platform consistency here. What we came up with is the following list, which is almost certainly incomplete:

First, there's a set of things that deal with colors (many of which are probably fine, some of which probably need some new features, and some of which might need some deeper adjustments):

• CSS and SVG
  • syntax for specifying colors
  • the list of things whose behavior is changed by the color-interpolation property and the color-interpolation-filters property is a good list of things that do math on colors (more generally, I think it comes down to compositing, gradients, animations, and filters, most of which have CSS and SVG pieces that might be a little different)
• HTML
  • legacy color attributes
  • <input type=color>
• Canvas
  • 2D context
  • WebGL context
  • webgpu context
  • ImageBitmapRenderingContext
  • including readback APIs (e.g., the format of raw bitmap data that you get back)
• WebXR?
• images (consider different formats (GIF/JPEG/PNG) and also whether or not they contain color profile information (tagged or untagged)
• videos (which might be different from images)

Then there's the set of things we're concerned about:

1. specifying (1a) and reading back (1b) colors: can you specify the range of colors that you want in all of these places
2. do things produce interoperable results? Some things to think about might be:
   a. different working color spaces
   b. different ways of clamping to device gamuts
   c. other sources of clamping
   d. places where things might be undefined (e.g., like untagged images in the old days before we said they were all sRGB)

I suspect other folks could expand on this list.

[imkremen]

Why Lab proposed as main perceptual uniformity color space for color 4?
Why not more modern CAM 16 or JzAzBz (especially for HDR)?

And why proposed to use Lab instead of Luv?
Here reference to Ross Ihaka:

Ihaka et al. (2003): The two perceptually based spaces introduced by the
CIE in 1976 are the CIELUV and CIELAB spaces. The CIELUV space is
generally preferred by those who work with emissive colour technologies
(such as computer displays) and the CIELAB space is preferred by those
working with dyes and pigments (such as in the printing and textile
industries),

see https://www.r-project.org/conferences/DSC-2003/Proceedings/Ihaka.pdf

[felipeerias]

@dbaron : Thank you very much for your work.

Sorry for the delay in following up. I've been having a number of conversations about this topic in the past days.

The main value of functions like lab() and lch() would be to enable authors to express colors in CSS that are outside the sRGB gamut (but within the gamut of modern devices). A precondition is to have support in the browser for handling those richer CSS colors: at the moment, Chromium uses a 32-bit ARGB format for these, so it would be necessary to add support for a higher-precision representation of colors throughout the rendering pipeline.

As this looks like more than could be tackled by a one-volunteer effort, I'm stopping this implementation work for now.

I am still very interested in this topic and would like to help in any way I can to move it forward; perhaps researching the concerns that @dbaron listed could be a first step.

I'm also wondering whether there could be other pieces of the Color spec that might be more easily implemented. For example, adding support for LAB interpolation (even if the colors may be clamped to the sRGB gamut for the time being).

[imkremen]

The main problem with "LCH" is that from source to source it reference to different color spaces (CIELab or CIELuv), here good comment from @jrus

And what is some day we want to add support for polar CAM16 or polar JzAzBz?

[tabatkins]

"RGB" can similarly refer to a multitude of spaces, but the spec nails down its precise meaning just fine. For most people the exact details don't matter; for those that do, reading the spec tells them exactly what they need to know.

(Note as well the line in that comment "Nowadays it also doesn’t really make sense to use CIELUV for anything.")

And what is some day we want to add support for polar CAM16 or polar JzAzBz?

If we decide those are reasonable to add as top-level functions, we can figure out names at that point. If not, they can be smuggled in via color(), possibly as predefined colorspaces. I don't see this as a future-compat issue.

[dbaron]

The other thing I would say about the list I drew up is that I don't think all of those things necessarily need to be addressed before shipping some parts of this. Features can be rolled out gradually. However, it's probably good to at least have a plan to get them into some reasonable state of completeness in a reasonable amount of time.

[dbaron]

Also, a few examples of things that might need fixing (or new alternatives) that would be found by auditing the list of things to audit to ensure that the platform has good support throughout for out-of-sRGB colors:

• (this one I'm pretty sure about) everything to do with canvas pixel manipulation, including the ImageData interface, to have variants that allow getting canvas data that's outside of the sRGB gamut
• the algorithm for serializing bitmaps, to ensure that it's possible to serialize any possible canvas accurately
• the <feColorMatrix> and <feComponentTransfer> filter primitives, to ensure that there are sensible ways to do those operations on colors outside of the sRGB gamut

[svgeesus]

@dbaron wrote:

discussion (in last week's breakout and plenary and between them) on whether the L component of lab() and lch() would be useful for color contrast calculations: our conclusion was that it's not, but only because it differs by a gamma correction from a value that would be useful (see the conversion from y to L in XYZ_to_Lab(), particularly the Math.cbrt). (Although it differs from the value currently used by both that gamma correction and by the difference between the D50 and D65 whitepoints, but the whitepoint difference seems much less significant.) (I also noticed w3c/wcag21#815 on the way.)

I agree with this conclusion. The L in Lab is certainly useful for many things (unlike the L in HSL, which is almost meaningless) but for color contrast calculations one needs a linear-light-intensity color space. The Y in XYZ (which is a step along the way to calculating Lab) is luminance, and this is used in the current WCAG contrast calculation. Which means that, when WCAG is ready to add this, the color contrast between, say, a foreground color in display-p3 and a background color in sRGB can easily be specified.

There is also a very interesting and detailed study on color contrast which may be used in WCAG 3, replacing the simpler formula in WCAG 2; but again, starting from the luminance of the foreground and background colors.

[svgeesus]

see https://www.r-project.org/conferences/DSC-2003/Proceedings/Ihaka.pdf

That is a very introductory paper, not presented at a color science conference, with a brisk overview of color spaces followed by an example of generating color scales for bar graphs. The main principles are those of Munsell, which is correct. The author then states:

Although Munsell’s colour balance recommendations are specific to his colourspace, they apply equally to any perceptually uniform space based on correlates of hue, value and chroma. In particular, reasonable results are obtained by applying Munsell’s principles to the CIELUV and CIELAB spaces.

It then goes on to utilize Luv without any explanation why it was picked. I suspect it is because Luv was supported by their programming environment, so it was a choice of least resistance.

[svgeesus]

@dbaron wrote:

First, there's a set of things that deal with colors (many of which are probably fine, some of which probably need some new features, and some of which might need some deeper adjustments):

I would like to thank the TAG for their work on identifying gaps in the current Open Web Platform, arising from the current sRGB-centric model of the early Web, which would need to be filled to deploy Lab and LCH.

A similar gap analysis has been ongoing in the Color on the Web CG since fall last year, and a draft report High Dynamic Range and Wide Gamut Color on the Web identifies similar gaps to those noted by the TAG. While the report is incomplete, I think a good way forward is to merge any new items noted by the TAG, which are not in the current CG report, into that report. There is a good community of relevant Color Science and industry experts in that CS, which ensures good technical review.

[simontWork]

A very interesting discussion. Could I just ask what operations you're intending the colour representation chosen to be used for?

I have seen issues with large colour volumes being reduced for display on practical monitors. If the scaling occurs within the colour space, then there may be a need to investigate how hue-invariant desaturation and brightness changes are.

For example, Braun, Fairchild and Ebner show experimental results for CIELAB desaturation:
https://www.researchgate.net/publication/2514272_Color_Gamut_Mapping_in_a_Hue-Linearized_CIELAB_Color_Space

There are more recent colour representations that can be used and which have significantly lower hue-distortion on desaturation, but care needs to be taken in understanding the limitations of each representation's design, e.g. some are designed to be implemented in the hardware currently prevalent in televisions, some are not easily realised in current consumer hardware.

[atanassov]

Another thread of discussions has been about providing ability to use the new color spaces to compute contrast ratios. I opened the issue #989 to continue this discussion at CSS Typed OM since typed color values seem look like a great way to address this.

[dbaron]

@svgeesus, regarding the issues above in the Color on the Web CG -- one of the things that presumably will need to happen at some point is that issues get filed against HTML, CSS, etc. Is the goal of the Color on the Web CG to try to do that? (And if so, is it waiting on developing more concrete proposals to address the issues, or do you feel that it makes sense to file the underlying issues even before you've developed proposals to address them?)

[svgeesus]

Currently that CG is tracking existing issues, to get a sense of the overall readiness of the Open Web Platform for Wide Color Gamut and High Dynamic Range.

I do expect new issues to be raised as we discover them.

[Myndex]

.... The L in Lab is certainly useful for many things .... but for color contrast calculations one needs a linear-light-intensity color space.........There is also a very interesting and detailed study on color contrast which may be used in WCAG 3, replacing the simpler formula in WCAG 2; but again, starting from the luminance of the foreground and background colors.

@svgeesus Hi Chris!

Sorry I'm just now commenting, things have been nuts in LA/Hollywood... I just wanted to mention a couple things in passing that you might be interested in.

Readability

The first note is that the contrast values are intended to be more consistent in terms of functional readability than perceived contrast levels. I.e. actual readability is the goal.

Perceptual

The contrast is reported as a percentage similar to Weber or Michaelson, not a ratio. The test values are linearized, and then have perceptual curves applied based on estimated adaptation. L* difference is sometimes used this way, though we are using slightly different curves (RLAB does something similar using different curves for foreground and background), and this has the advantage of a more accurate contrast/readability prediction.

Adaptation

The eventual final version is intended to have a module that will estimate the immediate surround on green in addition to the foreground and background, as that predicts the global adaptation level, which used to provide a more accurate contrast prediction.

Color/Hue

Also in the final (not yet shown) the color/hue module will make some adjustments based on color saturation. This is mostly for red for those with protan CVD, and blue due to the non-intuitive way that blue affects perceived luminance, and therefore contrast.

sRGB

As a side note, this is being designed for sRGB. Eventually a module could add-in support for other spaces (in fact, the algorithm is designed to allow a module for dynamic environmental response).

That said, in the interim sRGB is the "ideal monitor for accessibility" for a few reasons.

• Common Standard It is the common space now, and expected to be available far into the future.
• sRGB allows for a consistent display type while other assertive technologies are being developed.
• Color Vision Deficiency: sRGB is nearly ideal for helping those with CVD. In particular, for those with Protanopia the red primary is of a short enough wavelength that a saturated red is still visible and presents only a perceived 15% to 30% luminance loss. P3 is slightly more of a loss. But the new UHD Rec2100 and Rec2020 have the red primary of such a longer wavelength that it would likely appear black (not perceived) for those with protanopia.

As such, for some vision types, Rec2100 et al will need content to be "Daltanized" for display. (Daltanizing is a best practice for CVD... but requires some assistive tech to remap the content colors).

Please let me know if you have any questions!

Thank You!

— Andy

[svgeesus]

I have seen issues with large colour volumes being reduced for display on practical monitors. If the scaling occurs within the colour space, then there may be a need to investigate how hue-invariant desaturation and brightness changes are.

Yes, using for example the Hung and Berns dataset, Lab/LCH has a well known hue curve towards purple in the blue region. CIECAM02 has, unfortunately, a similar bend. Jzazbz has a correction for this, but when I implemented this colorspace, I found it had an equally problematic curve towards cyan.

(I would upload examples, but GitHb doesn't support SVG)

[svgeesus]

Okay, here is an example for Lab: the gradient shows sRGB blue (#0000FF) is progressively desaturated by reducing LCH chroma until it meets the neutral axis. Below are shown the (linear-light, not gamma-corrected) R G and B values, it can be seen that R rises faster thus accounting for the purple shift.

https://drafts.csswg.org/css-color-4/images/lab.svg

Here is the same thing in Jzazbz, sRGB blue is progressively reduced in JzCzHz chroma until it gets to the neutral axis. Of note: the green now rises faster, giving a cyan shift. Also the RGB channels do not fully converge on the gray axis, which is very odd.

https://drafts.csswg.org/css-color-4/images/JzczHz.svg

[Myndex]

Yes, using for example the Hung and Berns dataset, Lab/LCH has a well known hue curve towards purple in the blue region. CIECAM02 has, unfortunately, a similar bend. Jzazbz has a correction for this, but when I implemented this colorspace, I found it had an equally problematic curve towards cyan.

Hey @svgeesus

Not sure if you have played with this, but Bruce Lindbloom had made a perceptually uniform LAB space. I've not spent a lot of time with it, but thought I'd mention as it seems relevant to these last two posts.

http://www.brucelindbloom.com/UPLab.html

That said, I've been looking into blue in terms of readability and finding the instability and context sensitivity frustrating. Such as how blue adds or subtracts from perceptual contrast as dependent on the value of other primaries involved, not to mention the effect of rod intrusion at low luminance (under 8 nits).

[jrus]

http://www.brucelindbloom.com/UPLab.html

This should better be called “Munsell renotations as an ICC profile”. It’s basically a way of adapting the 1943 lookup table produced by the OSA so that some modern software can make use of it. It’s not really comparable to CIELAB as an analytical model. (But it’s reasonably close, because CIELAB and later color models were explicitly designed to match Munsell renotation data.)

[dbaron]

We're looking at this in a TAG breakout today, and I think we're happy closing this issue at this point, which we propose to do in this week's plenary. We've provided a few pieces of feedback above that seem to have dealt with (see previous summary), or are being actively worked on:

• One of those is the review of sRGB dependencies in other parts of the platform, which it seems the Color on the Web CG is working on. We'd strongly encourage getting those issues filed against the relevant specs sooner rather than later so that the working groups involved can get started on fixing them sooner rather than later.
• Another seems to be the desire for better color conversion APIs, for which a Color object proposal seems to be forthcoming.

[Myndex]

Hi David @dbaron,

I just now noticed this:

• discussion (in [last week's breakout].... on whether the L component of lab() and lch() would be useful for color contrast calculations: our conclusion was that it's not, but only because it differs by a gamma correction from a value that would be useful ....

I wanted to address: the new contrast method in Silver/WCAG3 is APCA (Advanced Perceptual Contrast Algorithm). it does use perceptually-based power curves, though with different exponents depending on the context and polarity.

The problem with using just ∆L* (Lab difference) is that color difference is not contrast.

Like color, "contrast" is not real, that is, it is a perception, and not absolute relative to perception. Contrast is extremely context dependent, and in some ways our perception of contrast is more non-linear than our perception of a color or luminance. Our perception of visual contrast is much more than a color difference: for instance spatial frequency is critical, and has a stronger effect on contrast perception at high spatial frequencies than luminance (for web, this translates to very thin small fonts).

Here is my favorite demonstration of context. Both yellow dots, and the squares they are on, have the same absolute color coming out of your monitor:

And the yellow of course is not yellow, it is separate red and green that stimulates the L and M cones in a similar way as spectral yellow does (which is between red and green). The red and green do not mix in the air like paint: they "mix" in your neurological system, starting with the ganglion cells behind the retina ( 'opponent color'), and then through the multistage filtering and processing of the visual cortex.

What you see all day is not exactly reality: it is your brain's filtered and deconstructed perception, which can be quite different from absolute values. Context needs to be accounted for or estimated to predict a perception as complicated as contrast.

APCA is focused on luminance contrast for fluent readability: getting whole words and letter-pairs into the Visual Word Form Area (VWFA) — this needs ample luminance contrast. But other stimuli, for spot reading, object recognition, state change.... are processed via different routes and in some different areas of the brain, and have different requirements.

Andy
A Guy Too Obsessed with Color

[mysteryDate]

Shipping lab and lch in blink soon:

https://groups.google.com/a/chromium.org/g/blink-dev/c/r0QATT8-kOw

Followed this draft spec: https://www.w3.org/TR/css-color-4/#lab-colors.

We're trying to pass all of the interoperability tests here along with webkit and gecko.

[dbratell]

Also oklab and oklch per https://drafts.csswg.org/css-color-4/#ok-lab