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

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

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

Sorry, yes, of course :)

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.

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 (https://github.com/w3c/csswg-drafts/issues/300)
• rendering colors outside the sRGB gamut (https://github.com/w3c/csswg-drafts/issues/4646)
• interpolation in non-sRGB color spaces (https://github.com/w3c/csswg-drafts/issues/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).

@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?

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.

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.

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.

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

@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).

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?

"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.

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.

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

@imkremen CAM16 is a color appearance model, not a color space.

A color appearance model (CAM) is a mathematical model that seeks to describe the perceptual aspects of human color vision, i.e. viewing conditions under which the appearance of a color does not tally with the corresponding physical measurement of the stimulus source. (In contrast, a color model defines a coordinate space to describe colors, such as the RGB and CMYK color models.)

While CAMs result in more accurate color specification, they are not feasible for the Web platform, as we do not know the viewing conditions (and just setting them to defaults renders the whole point of using a CAM moot).

@LeaVerou

@imkremen CAM16 is a color appearance model, not a color space.

As I understand, that's why CAM16‐UCS, actually, was developed.

While CAMs result in more accurate color specification, they are not feasible for the Web platform, as we do not know the viewing conditions (and just setting them to defaults renders the whole point of using a CAM moot).

Definitely, user (developer) shouldn't carry about viewing conditions. Theoretically, in some future they can be provided by system (light sensors/display settings). But as intermediate stage, default values can be setted.

@tabatkins

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

According to this paper

CIELAB ( * L , * a , * b ) is recommended for the colorant industries (surface colors) while CIELUV ( * L , * u , * v ) for the display (self-luminous colors) industries.

As I previously write (see reference to Ross Ihaka), for the same reason polar Luv (HCL) is widly used in R lang community.

It is still a good practice to use the u' v' chromaticity diagram (in preference to the xy chromaticity diagram), but what I can remember reading from multiple color science sources is that CIELAB has equal or better performance than CIELUV for essentially all applications, including for comparing colors from emissive displays, gamut mapping, etc. I’m not doing a good job finding a reference in 2 minutes here though. “Use CIELUV for emissive media” is basically a 40-year-old heuristic that still persists because people keep citing it.

If you want something better than CIELAB there has been work on this more recent than the 1970s. Just because the R community uses something doesn’t mean it should be baked into every web browser. Browser specs should err on the side of adding fewer rather than more miscellaneous features. Anyone who really cares can do the simple arithmetic in their own code.

I think so far we've had three four threads of discussion in this issue:

• discussion about alternative color spaces to lab() and lch() (entirely in this issue), for which the TAG really doesn't have the experts on, so it's probably best raised in the w3c/csswg-drafts repo (if anywhere)
• 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.)
• discussion about auditing what other pieces of the web platform would need to change given the presence of colors outside of sRGB's gamut, in https://github.com/w3ctag/design-reviews/issues/488#issuecomment-610107610 and https://github.com/w3ctag/design-reviews/issues/488#issuecomment-616863174 and https://github.com/w3ctag/design-reviews/issues/488#issuecomment-618105500
• the state of APIs is for getting a color in one of the different color spaces, particularly for computed style; it would be good to be able to read colors in the preferred space

We discussed this briefly in a TAG breakout today, and I think the main reason I want to leave the issue open further is to monitor progress on the third one. Though we want to also get an issue filed on the fourth.

@imkremen wrote:

Why Lab proposed as main perceptual uniformity color space for color 4?

Because Lab is the industry standard. It is widely implemented; it is the Profile Connection Space for International Color Consortium (ICC) profiles, it is used in most books and articles

And why proposed to use Lab instead of Luv?

Because no-one uses Luv. No commercial instrument reports it. It has a terrible chromatic adaptation built in (XYZ scaling) and does not have a distance metric. Most books mention it once, in passing, when the introduce Lab.

The 1976 quote (from when the CIE standardized both Luv and Lab) is classical standards-body equivocation and relates more to the backgrounds of the input to the standards body; but in the 40-odd years since, everyone uses Lab unless they also have the data to construct a color appearance model.

Why not more modern CAM 16 or JzAzBz (especially for HDR)?

It's interesting that you mention the CIECAM color appearance models (97, 02, 16) , and it is reasonable to ask why CSS Color 4 and 5 are defined in terms of colorimetry (Lab and LCH) instead of color appearance. The reason that color appearance (which was considered) could not be used in CSS is because of the inherent nature of CSS. Style rules from various origins (author, reader, user agent) are combined via specificity and cascading to yield an eventual result. Thus, all colors are specified at a very granular level on individual elements in the document tree. There is thus no notion of the overall visual field or surroundings in which colors will take on an appearance. Certain aspects of that (the background color or image for a specific element, the colors of nearby elements) could in theory be tractable to analysis by a CSS processor. Others (the colors of other windows that are visible in addition to the browser window) are not available (and must not be, for security and privacy reasons); the overall room luminance, the current white point and the degree of user adaptation to that white point are unknown to a CSS processor and thus cannot be used as input to a color appearance model.

CIECAM is often used in the literature for perceptual gamut mapping of images, but in that case all the colors are available and the (assumed homogeneous, monochromatic) values for the immediate and distant surround and the lighting conditions for the print can be measure or specified and input to the model.

@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.

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.

@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.

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.

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

@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?)

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.

.... 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

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)

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

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).

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.)

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.

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

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.

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