Non-sRGB color spaces, outdated sRGB threshold, and other issues in the "relative luminance" definition

[michael-n-cooper]

From @peteroupc on March 24, 2018 8:47

Also found at this issue. Posting here in case I get a reply sooner.

The value 0.03928 (as used in what was formerly a note to the "relative luminance" definition but what is now a "normative" part of that definition) comes from the sRGB proposal. This is outdated and either 0.04045 or 12.92 * 0.0031308 = 0.040449936 (I don't know which is used in the IEC standard) should appear in its place.

I understand, however, that all three thresholds don't make a difference in the results if only 8-bit linear sRGB values are involved. On the other hand, if no change to the 0.03928 threshold is planned soon, a note on the origin of that threshold should be added to the document (in particular, why that threshold was chosen rather than the one given or implied in the IEC standard).

EDIT (Mar. 27): Clarification. EDIT (Apr. 9): Struck out part of the text. Since so few source code files on GitHub use 0.040449936 compared to 0.04045, I reasonably believe that the IEC standard uses 0.04045 as the relevant threshold, assuming it even mentions an inverse transfer function.

Copied from original issue: w3c/wcag21#815

[michael-n-cooper]

From @awkawk on March 27, 2018 16:57

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

[michael-n-cooper]

From @awkawk on April 4, 2018 2:40

Thanks for the comment - we can look at an update to the understanding document after WCAG 2.1 is published, but we are not making changes to the normative text or definitions from WCAG 2.0 in this update. I am closing the other issue you link to as we will track it here.

[michael-n-cooper]

From @peteroupc on April 4, 2018 2:49

Thanks for the update. A related issue concerning the "relative luminance" definition that the Understanding WCAG document should clarify is whether "relative luminance" should be considered equivalent to the Y component of CIE XYZ (especially for non-sRGB color spaces such as DCI-P3) (more specifically, equivalent to the "luminance factor" as defined by the CIE) and whether the notes in that definition specifically apply only to companded ("non-linear") "sRGB" colors encoded as 8-bit-per-component colors and not to sRGB or sRGB-like colors encoded or represented in some other way (whether by using different red, green, blue, or white points, a different color component transfer function, a different encoding form, or otherwise).

EDIT (Apr. 8): Clarification.

[michael-n-cooper]

From @alastc on April 18, 2018 22:14

I'm going to take this to people who know more about color spaces than I do, but regarding urgency it would help to know in what scenario CIE XYZ or DCI-P3 would be applicable for web content?

I.e. if "relative luminance" were considered equivalent to the Y component of CIE XYZ as you described, what difference would that make? What would someone creating web content do with this information?

[michael-n-cooper]

From @peteroupc on April 18, 2018 23:10

My reference to CIE XYZ in my post is largely for the sake of clarity. What I mean to refer to is relative luminance being equivalent to the ratio of a color's luminance (Y component of CIE XYZ) to the white point's luminance; that is, the luminance factor — this is a much more precise statement than the definition of "relative luminance" in the current WCAG. Specifically, given a colorimetric color space such as sRGB or DCI-P3 (and other examples), the luminance of a color is objectively defined, whereas the current definition uses the word "brightness", which is a subjective attribute.

Some higher-end monitors support a wide gamut of colors, wider than sRGB; examples include DCI-P3 and Adobe RGB (1998). For such monitors, as well as images that use non-sRGB color spaces (via ICC profiles and similar mechanisms), and in other cases in which a non-sRGB color space is known to be involved, it can be useful to find the relative luminance of RGB colors in terms of such a non-sRGB color space. However, if I am not mistaken, color specifications in CSS (and presumably in HTML as well) are in terms of sRGB regardless of the monitor's color gamut or the computer's working color space; even so, this doesn't rule out images with profiles specifying a non-sRGB color space.

Most importantly, though, although the WCAG is primarily designed for Web content, those guidelines also appear in design recommendations for mobile apps (for example, in Google's material design specification), and the WCAG guidelines for the use of color can also find good use when designing computer programs with graphical user interfaces in general.

Finally, in any case, the threshold 0.03928 instead of 0.04045 indicates that the color space in note 1 of the current WCAG is "like sRGB", but not exactly sRGB. If an application wants to use the threshold of 0.04045 (which is the threshold that I presume is given in the IEC standard), then note 1 arguably doesn't apply anymore and the manner of calculating relative luminance for the "real" sRGB is undefined except as given in the definition for "relative luminance" in the current WCAG.

[michael-n-cooper]

This issue did not port properly. Check w3c/wcag21/#815 for the remainder of the context.

[svgeesus]

Regarding the K0 coefficient in the sRGB definition, the original poster is correct. The value should be 0.04045.

The original calculations (slope of the linear portion = 12.9232102, threshold of 0.0392857) were incorrectly rounded down when first proposed (the slope of the linear portion was rounded to 12.92, threshold rounded to 0.03928; both four significant figures). This produced a discontinuity in the curve (the linear and curved portions did not actually meet).

The final IEC standard corrected this by keeping the same slope of 12.92 (for backwards compatibility) and moving the threshold to 0.04045, so the curves now meet (although there is now a slight change of slope at the join).

This has zero practical impact for 8 bit per component systems. On a 0 to 255 scale, the transition from linear to curved part happens at 10.0164 for 0.03928 and 10.31475 for 0.04045. Both round to 10/255. There is a slight but imperceptible impact for 10 bit per component systems. On a 0 to 1023 scale, the transition from linear to curved part happens at 40.0656 for 0.03928 and 41.259 for 0.04045, which round to 40/1023 and 41/1023 respectively.

Thus, the correct, international standard value of 0.04045 should be used, and tools should preferably be updated, and there will be no visible difference in calculated contrast ratio from using the draft or the final standard threshold values.

[svgeesus]

Concerning relative luminance:

A related issue concerning the "relative luminance" definition that the Understanding WCAG document should clarify is whether "relative luminance" should be considered equivalent to the Y component of CIE XYZ (especially for non-sRGB color spaces such as DCI-P3) (more specifically, equivalent to the "luminance factor" as defined by the CIE) and whether the notes in that definition specifically apply only to companded ("non-linear") "sRGB" colors encoded as 8-bit-per-component colors and not to sRGB or sRGB-like colors encoded or represented in some other way (whether by using different red, green, blue, or white points, a different color component transfer function, a different encoding form, or otherwise).

Yes, the value being computed for sRGB is the relative luminance, and is equal to the CIE Y value for the color in question, as a fraction of the CIE Y value for a diffuse white (and assuming the CIE Y value for sRGB black is zero, which is not strictly true).

Edit: I see that in fact you do add a 5% viewing flare component, so you are not assuming black is zero luminance; good!

Therefore, for non-sRGB spaces such as P3, the same calculations for relative luminance should be made, starting from the chromaticities and white point of the P3 colorspace. The gamma value used for Apple's Display P3 colorspace is 2.2, and the chromaticities for P3 are not the same as sRGB.

In the old issue there was some confusion about using non-sRGB colorspaces on the Web. The assertion was made that all colors are converted into sRGB. This used to be true, but is no longer true. CSS Color 4 allows colors to be specified in a range of colorspaces, and image-p3 is one of the built-in options. Hopefully this answers the question about "how could people actually use that on the Web".

I also saw some confusion about CIE Lightness L (as used in Lab for example) vs. CIE Luminance Y vs. the L value in HSL.

Luminance is a measured, objective quantity for how much light something produces; it is weighted to the human visual system (so dark red light is dimmer than yellow-green light, for example). Lightness is derived from luminance, such that the lightness of diffuse white is 100 and the lightness of mid grey is 50. It will be possible to use CIE Lab on the Web and for the purposes of contrast ratio the Lightness is converted back to luminance.

The L part of HSL is basically broken. It does not correspond to measured or perceived luminance n any way. For example, pure yellow (#FF0) and pure blue (#00F) have the same L value in HSL, even though the yellow is clearly much lighter than the blue. I saw a well-intentioned but highly misguided suggestion in the old issue to base everything off HSL. Don't do that.

[svgeesus]

from https://github.com/w3c/wcag21/issues/815#issuecomment-385283999

So the solution is to add text to Understanding WCAG 2.0 (which can be done) to talk about other color spaces. The contrast levels and definition of luminosity remains the same. It would only be the formulas for "lightness" that change to match the colorspace you are in.

I agree that text should be added to Understanding WCAG regarding other color spaces. Provided it is done correctly (luminance, not luminosity; relative luminance, not lightness). I'm happy to review text, or indeed to propose text, for that addition.

[alastc]

Hi @svgeesus,

Thanks for joining this thread, my knowledge of colour spaces is very basic so it's hard to judge the details of this. (I wasn't involved in the original setting of this, it was so long ago!)

From what you've said, the main questions I'm trying to understand are:

• If there is a slight impact for 10 bit per component systems, how would I know if I had an 8 or 10 bit output system?
• Related, are there higher bit systems that 10? My camera supports 14 bit pictures, but not sure if my monitor does?! Changing the value is a pretty big deal, I'm trying to work out what % of monitors/devices and testing tools would be affected.
• Is there a consistent color space that browsers display CSS derived colours in? I assume p {color: #036;} will always be in sRGB, it looks like you'd need to do something like p { color: image-p3(0%, 20%, 40%);} to use a different color space. However, does the browser convert that for display? In the same way that all length units are translated to pixels for display by the browser, is there a color space that browsers convert all CSS colours into?
• Can images (including jpg, png & svg) use different colour spaces, and will the author always know? E.g. Would I have to define the colour space, or could I upload a PNG background which uses a different color space without realising? (I assume that's embedded into jpg/png files?
• If I use a colour-picker style testing tool like the colour conrast analyser, does it matter what colour space is used? I.e. will it pick up something close to the diplayed luminance regardless of colour space?

If I can understand that (which I struggled with in the previous thread), I feel like I'll be able to work out what the updates should be... and your offer for writing something is very likely to be taken up!

Cheers,

-Alastair

[svgeesus]

If there is a slight impact for 10 bit per component systems, how would I know if I had an 8 or 10 bit output system?

Most systems are 8-bit now. There are a few 10-bit systems, graphics cards like the NVidia Quadro graphics cards on workstation-class desktops and laptops support 10bit color for example. (My clunky Dell 17inch laptop has a wide gamut screen and 10 bit framebuffer and screen, for example) With increasing use of wider color gamuts, the need for 10 or even 12 bits per component becomes more acute (a larger space needs more bits to represent it at the same resolution) so these are becoming more common over time.

In other words, the impact on existing systems is tiny. But the number of affected systems will increase over time.

Related, are there higher bit systems that 10? My camera supports 14 bit pictures, but not sure if my monitor does?! Changing the value is a pretty big deal, I'm trying to work out what % of monitors/devices and testing tools would be affected.

Yes, there are both 10 and 12 bit system used for wide gamut TV for example. Some monitors are 10 bit input and output but use 12 or 14 bits internally for calculations or for lookup tables for gamma correction, for example. This is to avoid round-off errors.

Is there a consistent color space that browsers display CSS derived colours in? I assume p {color: #036;} will always be in sRGB, it looks like you'd need to do something like p { color: image-p3(0%, 20%, 40%);} to use a different color space. However, does the browser convert that for display? In the same way that all length units are translated to pixels for display by the browser, is there a color space that browsers convert all CSS colours into?

We need to carefully distinguish between the space used to specify a color and the space used to display it. It is correct that color: #036 is specifying an sRGB color while color: image-p3(0 0.2 0.4); is specifying a P3 color and color: lch(80 117 220deg) is specifying a color directly in CIE LCH.

Color managed implementations will convert all color specifications to the actual output colorspace of the device (screen or printer) in use. So for example Chrome or Safari on a Mac with a P3 screen will convert the sRGB values to the values needed for P3. This is done with an ICC profile, by the operating system.

Can images (including jpg, png & svg) use different colour spaces, and will the author always know? E.g. Would I have to define the colour space, or could I upload a PNG background which uses a different color space without realising? (I assume that's embedded into jpg/png files?

Yes, images can and often do use different colorspaces, by embedding an ICC profile. The author will know by looking at the info panel in an image editor, for example. The software should convert this to the destination colorspace for display. Untagged images are assumed to be in sRGB.

If I use a colour-picker style testing tool like the colour conrast analyser, does it matter what colour space is used? I.e. will it pick up something close to the diplayed luminance regardless of colour space?

Unfortunately that currently depends on how the picker is implemented.

[svgeesus]

By the way, I recently read a great Medium article by Netflix which is an easy-to-read, but technically accurate, introduction to the trend to higher bit depth, wide color gamut (WCG) and high dynamic range (HDR)

[alastc]

Thanks @svgeesus, interesting article.

I thinking I'm getting it, ish. So my working assumptions are:

• An image or CSS defined color can be defined with a non-sRGB color space.
• How that is displayed depends on the user's monitor.
• A display with high brightness + HDR will have greater contrast (in luminescence terms), regardless of the color space of an image.
• An HDR image (short-hand for greater-range) displayed on an SDR display will not show the extremes of brightness or color (essentially clipping them).
• An sRGB regular image on an HDR display would spread the color & brightness out over the display-able range.

So as a user, there is only upside from having an HDR display, it will have greater contrast. The other way around (high-range image on low-range monitor) is likely to clip certain images, but shouldn't otherwise reduce contrast of what is displayed.

Therefore if most people are on SDR displays, we should test with the SDR color space regardless of the color definition. (Not sure how well you know WCAG 2.x, but it has a concept of "accessibility supported", so that people use & test with user-agents currently in use. )

The question is whether converting a P3/Rec2020 image / CSS-color to sRGB for testing is harmful for working out the contrast that would appear on a regular SDR display?

[svgeesus]

An sRGB regular image on an HDR display would spread the color & brightness out over the display-able range.

No! otherwise a normal paper white will become an eye-searing blinding white. Max intensity is only suitable for small specular highlights. The correct mapping of SDR content onto an HDR display is a topic of active discussion but there is agreement that using the full range is totally wrong.

Otherwise, yes to your other points :)

[alastc]

Ok, that makes sense, and I suspect makes source material more consistent across screens.

So the first step is to update the 0.03928 value here: https://www.w3.org/TR/WCAG21/#dfn-relative-luminance

To 0.04045.

On the basis that "This has zero practical impact for 8 bit per component systems." the sooner we do that the better, before more people get higher-range displays.

@patrickhlauke would that impact the CCA? Is it an easy change? (Obviously other tools are available, just checking that it is an easy value to change in at least one tool.)

Secondly, I'm wondering about making sRGB the testing requirement in future, i.e. values are converted to sRGB for the purpose of testing the contrast ratio. My thinking being: It is the smaller color space, so it would be clipping off any extra hue/brightness differences, so it is more of a lowest common-denominator. If that contrasts, any extra from the color space is a bonus.

Would that make sense?

[patrickhlauke]

@alastc CCA uses a third-party color handling library, which has functions to calculate luminosity/contrast https://github.com/Qix-/color/#luminosity

this is where the update will need to be made by the author there https://github.com/Qix-/color/blob/master/index.js#L253

[edit: x-ref https://github.com/Qix-/color/issues/149]

I'd suspect most tools that calculate contrast either do this in a similar fashion, or hook in a helper library...it'll be a question of nudging the original upstream authors in the latter case.

And I'd agree that WCAG should really define one canonical color space for its calculation/result. The "fun" part will be the arguments over how non-sRGB colors will need to be converted to sRGB, as that will likely vary...but that's a problem that's a bit too broad to handle for WCAG i'd say.

[svgeesus]

@alastc

So the first step is to update the 0.03928 value here: https://www.w3.org/TR/WCAG21/#dfn-relative-luminance

To 0.04045.

Yes. Also, to update the sRGB reference from a specific, ancient working draft to the current International Standard (which is where the .0.04045 comes from).

Shall I send a GitHub pull request for those two changes?

[awkawk]

@svgeesus sure, that would be helpful. It will sit for a while until we are under a new charter but it will be able to make it into an editor's draft sooner than later.

[svgeesus]

In section 6 Glossary , which appears to be normative, the definition of relative luminance is

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white https://www.w3.org/TR/WCAG21/#dfn-relative-luminance

The term brightness is not further defined, so this definition is incomplete and (as correctly noted by @peteroupc ) incorrect. The term 'darkest black' is not defined (is it a perfect black absorber? Is it the luminance of sRGB 0,0,0?) and the term lightest white is not defined (and that definition will matter, once HDR comes into play and the lightest possible white is a thousand times brighter than a diffuse paper white).

Then, in a Note (are Notes normative or informative?) the actual equation is given for finding the luminance of an sRGB color and the sRGB diffuse reference white, so that the relative luminance can be calculated. I can see that this could be an informative example on the grounds that sRGB is just one colorspace among many (although, it is the most important one on the Web). But the equations in that Note are the only clue as to how relative luminance is actually calculated.

As noted by @peteroupc :

What I mean to refer to is relative luminance being equivalent to the ratio of a color's luminance (Y component of CIE XYZ) to the white point's luminance; that is, the luminance factor — this is a much more precise statement than the definition of "relative luminance" in the current WCAG. Specifically, given a colorimetric color space such as sRGB or DCI-P3 (and other examples), the luminance of a color is objectively defined, whereas the current definition uses the word "brightness", which is a subjective attribute.

So I suggest (and yes, this is preparatory to the pull request which I am preparing) changing the definition to align with the procedure hinted at in the Note and clearly expressed by @peteroupc

relative luminance The ratio of the luminance (Y) of the color, to the luminance (Yw) of the white point. The relative luminance of the white point is thus 1.0, and the relative luminance of the black point, before correction for viewing flare, is 0.0. (see contrast ratio, where viewing flare is corrected for).

I see that your definition of contrast ratio correctly takes into account the viewing flare (the fact that the black on the screen is not pitch black but reflects some small amount of the ambient light) with the 0.05 correction factor, so nothing needs to be done there and I just added a cross reference..

I see that the value 0.04045 needs to be added to https://www.w3.org/TR/WCAG21/relative-luminance.xml as well.

[svgeesus]

The references do not include a normative definition for luminance.

The correct definition would be CIE Colorimetry - Part 1: Standard Colorimetric Observers ISO 11664-1:2007(E)/CIE S 014-1/E:2006 http://www.cie.co.at/publications/cie-colorimetry-part-1-standard-colorimetric-observers

I'm going to update the definition in CSS Color 4 normative references to that (it currently refers to the almost-identical 2004 standard) so, I think, there is no need to add that to WCAG.

[svgeesus]

The reference in WCAG to a specific dated draft of sRGB does need to be updated though, so I will add that to my pull request. The correct reference is

IEC 61966-2-1:1999 Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB https://webstore.iec.ch/publication/6169

[svgeesus]

As noted by @peteroupc in the original thread:

Although Note 3 in the "relative luminance" definition says "If using other color spaces, see Understanding Success Criterion 1.4.3", actually Understanding WCAG is silent on color spaces other than sRGB.)

and sure enough, Understanding Success Criterion 1.4.3 just says

Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet - sRGB" [sRGB].

which a) is only about sRGB, and b) both references are outdated and now incorrect, with the old `` value.

I propose instead the following text, pointing to css-color-4, which does indeed talk about other color spaces like P3, Rec.2020, CIE Lab, CIE LCH, and gives the equations for calculating luminance for each of them:

"If using other color spaces, see CSS Color 4 for how to calculate relative luminance.

[alastc]

"If using other color spaces, see CSS Color 4 for how to calculate relative luminance.

How would a tester know what the color space is for a particular image? Presumably CSS-set color could be examined for color space settings, but what about images?

Also, for users on a basic sRGB screen, what would they get?

That's why I was suggesting that we standardize testing to sRGB.

[svgeesus]

How would a tester know what the color space is for a particular image?

Two things strike me as odd about that question. Firstly, why is the user involved here? It is the tool implementor who needs to know the colorspace, not the user. And they know because their tool reads the CSS. Secondly, why are images involved here? Are there tools that perform pixel-by-pixel color contrast checks when an image is involved?

Also, for users on a basic sRGB screen, what would they get?

They would get the source color, converted to sRGB (if it fits in the sRGB gamut, it should be the same measured color; if it doesn't, the color will be less saturated than the actually specified color).

[alastc]

If the tool can work it out that's great, but we do need to test for contrast between colours on images. E.g. for the non-text contrast criteria, or for text on an image and/or gradient background. We've just done a technique for that.

I use the CCA for testing with spot checks.

the color will be less saturated than the actually specified color

That appears to support the argument for converting to sRBG for all the testing. If some/many people are using sRGB screens, they would get less saturated (therefore less bright?) colours. I'd rather take a lowest-common-demonimator approach than assume folk with low-vision all have good quality screens.

[svgeesus]

Thanks for the link to image background techniques. That seems reasonable to me. In that case, to answer your question, a tagged image (one with an embedded ICC profile is in the colorspace that the profile says it is; untagged images (with no colorspace info) are assumed to be in sRGB, for backwards compatibility.

In terms of assuming a lowest common denominator screen for testing, sRGB seems ideal for that.

[Myndex]

I found this thread as I am preparing an issue regarding contrast, but I saw a number of misunderstandings and questions here I can answer:

1) Luminance is Y from CIEXYZ. It is LINEAR (no gamma curve) and it is not perceptually uniform (neither is light, which is what luminance in XYZ represents).

2) Luminance SHOULD NEVER be called "brightness" nor "lightness" those terms have different meanings. For one, "brightness" is a PERCEPTION, and luminance is a measurable quantity. By the same token, "luminance" should never be used to describe encoded video Y´, which should be called luma. Luma is gamma encoded. Luminance NEVER is (always linear, like light).

3) The 1996 draft of sRGB should NOT be used for anything. The equations have changed as well as other specs (like flare). IEC. 61966-2-1. 1999 is normative. The 1996 draft (on display at W3C) is based on CRTs with glass screens, not LCDs with flat, and mostly matte screens. FLARE IS DIFFERENT!! IEC defines flare as 1 cd/m2(nit), which is 1.125% for an 80 cd/m2 monitor. (We'll ignore that most people have their monitors at 120 to 160 nits.)

3b) The "5% flare" in the original sRGB draft is NOT in the standard, NOR is it really relevant to modern LCD monitors. I've measured about a dozen desktop & laptop LCD monitors, both matte and gloss, in various lighting conditions, including bright interior office lighting, and never got a reflectance reading above 1 cd/m2 using my Sekonic 558 Cine spot meter. Your mileage may vary.

4) Authoritative documents on color and gamma are by Charles Poynton: https://poynton.ca/GammaFAQ.html https://poynton.ca/ColorFAQ.html 4b) This guy below talks at length about the rounding issues in sRGB, and the discontinuity: http://entropymine.com/imageworsener/srgbformula/ 4c) Bruce Lindbloom has a lot of color math resources, among other things. http://www.brucelindbloom.com/index.html?Math.html

5) On color profiles: sRGB is the profile of the web. All images should be in sRGB. Any image that is NOT in sRGB needs an embedded profile, but expect that those images will look wrong on many devices that do not do color management.

5b) sRGB is a smaller gamut than P3, so on a color managed browser on a P3 display, the image will look correct (the color management will transform sRGB to P3).

5c) sRGB is still the standard colorspace for the web, so stick to sRGB unless you have a specific application where your viewers will have a different form of monitor and colorspace that you need to match. I attempt to clarify why using other profiles are less than useful especially in 8 bit here: https://www.generaltitles.com/helpfiles/13-q-a-blog/colorspaces-and-file-types/11-dslr-colorspace

Some replies to @alastc , basically everything SVGEESUS said, just adding on:

• Related, are there higher bit systems that 10? My camera supports 14 bit pictures, but not sure if my monitor does?! Changing the value is a pretty big deal, I'm trying to work out what % of monitors/devices and testing tools would be affected.

The 14 bit pictures from your camera are "RAW" sensor data, and can't be displayed directly as they need to be debayred first. When you open them, you can open them as 16 bit, and maintain much of the dynamic range for editing. But you would usually convert them to 8 bit png or jpg for use on the web.

A lot of video is 10 bit. For film we often work in 32 bit per channel, and sometimes even 64 bit per channel (some high end grading systems). So yes, there are systems with higher bit depth which allows for greater flexibility in adjustment without introducing delta E errors.

But for monitors, typically 8 or 10 bit. I use an NEC wide gamut monitor for my center display, and it can do 10 bit, and it has internal 14 but LUTs (the profiling happens within the display, not on the graphics card). And some cards will handle 10 bit as well. The HDMI spec allows up to 12 bit.

• Is there a consistent color space that browsers display CSS derived colours in? I assume p {color: #036;} will always be in sRGB, it looks like you'd need to do something like p { color: image-p3(0%, 20%, 40%);} to use a different color space. However, does the browser convert that for display? In the same way that all length units are translated to pixels for display by the browser, is there a color space that browsers convert all CSS colours into?

Color managed browsers will display in the space that the monitor is profiled for. But some browsers like Opera are not color managed, and so will display without correction. CSS/HTML colors display as sRGB as a default, but WILL be adjusted in color managed browsers. The "new" color space colors will only be correctly interpreted if the browser supports that. As I said above regarding sRGB, I recommend all web stuff be sRGB.

• Can images (including jpg, png & svg) use different colour spaces, and will the author always know? E.g. Would I have to define the colour space, or could I upload a PNG background which uses a different color space without realising? (I assume that's embedded into jpg/png files?

Your images can be in any colorspace the container supports. (a container is the file, such as jpeg or png). And yes, it is possible to not know that you're in the wrong colorspace, sometimes the difference is subtle. Color spaces are not usually embedded unless you specify that in your image editing app. Also Photoslop has "convert to sRGB" checkbox on it's save for web dialog.

• If I use a colour-picker style testing tool like the colour conrast analyser, does it matter what colour space is used? I.e. will it pick up something close to the diplayed luminance regardless of colour space?

Many of these tools are using useless math. The contrast math the W3C specified is flawed (I'm working on a pull request right now). So really, it's up to the developer what or how it handles color transforms and analysis. Many of the color tools like HSV pickers are done using fairly simple math, and leave much to be desired (such as most are not perceptually uniform).

So keep in mind that an RGB value is just a set of numbers. Without being related to a color space, those numbers could mean anything. In 8 bit, #00FF00 is max green. But what max green? The sRGB max green is in a very different place than the P3 max green or the Alexa Max Green.

SO: If you put an sRGB image on a P3 monitor, and interpret as if it was a P3 image, it will look more saturated and/or brighter than it should. If you take a P3 image and interpret and display as sRGB, it will look less saturated and/or darker. (gross generalities of course).

[alastc]

Hi @Myndex,

Thanks for that. In general terms let's keep discussion of changing the overall contrast math/model to the other thread, this one is focused on relatively minor corrections to the current one for WCAG 2.2

Questions:

• Is the update to IEC. 61966-2-1. 1999 simply updating the value? (K0 coefficient, 0.04045). I wasn't sure if the flare aspect would be part of that update?
• From what you've said, I take it you would support that all testing of color contrast (on the web) should assume sRGB, regardless of declared color space in the content?
• Should color-picker tools default to sRGB, and if it is being used on a system that supports more (e.g. P3), it should transform that value to sRGB?

Thanks for the rest, I'm gradually filling in my knowledge on color spaces.

[Myndex]

Hi @Myndex,

Thanks for that. In general terms let's keep discussion of changing the overall contrast math/model to the other thread, this one is focused on relatively minor corrections to the current one for WCAG 2.2

Hi @alastc You're welcome, and I agree about keeping the contrast stuff to issue 695

For THIS one, is someone making a pull request? because I was about to. While the error does not affect how the WCAG is using the math, it is bad form for a standards document to present an incorrect calculation as standards documents are considered authoritative, and errors like this impact credibility.

Just to show it does not affect WCAG, for 8 bit hex values #000000 to #090909:

Left (pink) Wrong (0.039) threshold, and right (yellow) correct 0.04045

The spreadsheet math (OpenOffice) — Normalize the 8 bit to 0-1 (divide hex by 255) then assuming that value is in cell E39: =IF( E39 <= 0.04045; E39/12.92 ; POWER(((E39 + 0.055)/1.055);2.4))

The WCAG also defines relative luminance as:

the relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white

Incorrect, luminance is NOT brightness. And "relative brightness" is itself redundant, brightness is always a relative, non-measurable, perceptual term.

Relative Luminance should be defined:

• the relative quantity of light with 0 at minimum black and 100 at maximum white. Luminance is spectrally weighted relative to human color vision, however luminance is not perceptually uniform to human visual perception of lightness.

Questions:

• Is the update to IEC. 61966-2-1. 1999 simply updating the value? (K0 coefficient, 0.04045). I wasn't sure if the flare aspect would be part of that update?

IEC defines flare differently, however it is NOT (and never) part of the sRGB equation in discussion in this thread. The flare/ambient issue IS part of the contrast discussion in issue 695.

• From what you've said, I take it you would support that all testing of color contrast (on the web) should assume sRGB, regardless of declared color space in the content?

sRGB is the web standard and represents the MASS majority of devices. Alternate color spaces (which are not even useable at this time, as they are part of a working standard and not supported) should only be used in specific use cases. There is no benefit to accessibility (and only detriment) at this time.

As for programatic testing: Hmmmm... This is roundtable topic for discussion.

Non-sRGB colorspaces are not yet actually supported in a real way, so best to consider them experimental. IMO if anyone designed a page in a non-standard space, they need a way to fallback to sRGB gracefully, and that fallback is what should test. At the moment, fallback guidelines are not set (or even conceived from what I can see, but I'm picking my battles right now on contrast!)

• Should color-picker tools default to sRGB, and if it is being used on a system that supports more (e.g. P3), it should transform that value to sRGB?

With the exception of the L a b* picker, the common colorpickers don't have a "colorspace" they are just interpolating RGB values with no regard for any specific colorspace. This is partly why they are not perceptually uniform (and not even close!!) There are some color tools thought that are perceptually uniform and relative to a specific color space.

That said, when people are choosing hex values for color for webpages, they are choosing values intended to be presented in sRGB, i.e. full green #00FF00 = Y 0.7152 x 0.3 y 0.6

If #00FF00 is fed into Adobe98, the Yxy values would be Y 0.62736 x 0.21 y 0.71

If #00FF00 is fed into DCI P3, the Yxy values would be Y 1?? x 0.265 y 0.690

The Y is the luminance and the x,y is the coordinate on the CIE chromacity diagram:

Thanks for the rest, I'm gradually filling in my knowledge on color spaces.

NO prob, it's a long steep learning curve, partly because it is quite abstract and partly because human vision is bizarre in how it functions.

Here is one white paper you might find interesting, a little more canted toward film (as in movies), but covers vision, video and everything.

https://www.filmlight.ltd.uk/pdf/whitepapers/FL-TL-TN-0417-StdColourSpaces.pdf

The main thing to remember about color spaces is: They are just MODELS that define (or attempt to) a particular device or perception.

CIEXYZ: A model of human vision, however it is not perceptually uniform. CIELAB: Another model of human vision, but it IS perceptually uniform. sRGB: A model (and standard) for common computer display behavior. DCI P3: A model (and standard) for digital cinema projection. US SWOP COATED: A model for offset printing CMYK on coated paper. MUNSELL: A categorization of color based on perception.

On CIELAB: It is modeled after the human opponent colors: red and green are opponents and blue and yellow are opponents. So the +a -a and +b -b axis are built around these opponent colors (i.e. red and green can't happen at the same time, and blue/yellow can't happen at the same time, per how our eyes transmit visual information to the brain).

Various forms of matrix maths or look up tables (LUTs) can be used to convert from one color space to another, with varying results. The ICC color management system uses profiles that define a particular space, and the CMM engine will convert from one space/device, into XYZ or LAB, and then into a destination space/device.

For instance, if working in sRGB and you need to print to an Epson color printer, the color manglement(joke) would convert from D65 sRGB to D50 CIEXYZ to D50 Epson CMYK.

However it is also possible with non ICC systems to use some custom LUT to go direct from one space to another.

sRGB and Rec709 are fairly ideal color spaces for 8bit (per channel) media for video display. When moving to a larger colorspace, you ALSO need to increase bit depth, or the delta E errors will simply make things look WORSE. It is one big reason I am very skeptical of adding in other color spaces for WEB pages.

Rec2020 defines a MINIMUM bit depth per channel of 10 bits. And all these all have some form of transfer curve like a gamma curve to make the best use of the available bits, this again because human vision is non linear (our eyes have a gamma of about 2.5).

So then, the Y Luminance in CIEXYZ is linear like light (no gamma)

The L in CIELAB L a b is Perceptual like human vision (it has a gamma type curve)

The gamma curves of sRGB or Rec709 are both a little different, and not quite like human vision, but similar. They are designed for efficient coding of the signal to the monitor, and assume the monitor is adjusted to the environment (ambient light) and also assume the monitor is going to ADD some gamma on display, so that there is a total system gamma GAIN, so that the "perception" of the image fits the intent of the image creator.

[svgeesus]

Agreeing with most of the contributions by @Myndex (which mostly recap earlier discussion) but:

sRGB is the web standard and represents the MASS majority of devices. Alternate color spaces (which are not even useable at this time, as they are part of a working standard and not supported) should only be used in specific use cases.

That used to be the case but is no longer. All modern iOS and OSX devices use image-p3. Higher-end Android devices such as Samsung Galaxy also use a WCG similar to image-pr in gamut. Modern TVs typically support WCG and HDR, increasingly aslo have embedded web browsers, and there is thus a need to composite SDR Web content onto WCG and HDR content (delivered using REC.2020, but in practice only using around the DCI P3 gamut volume).

Also, the xy chromaticity diagram is a very poor way to visualize gamut volume differences. It exaggerates small changes in green primary chromaticity, hides large changes in red and blue, and fails to show the gamut volume shape for dark and light colors.

[svgeesus]

For THIS one, is someone making a pull request? because I was about to.

Yes, I am on the hook to do that, but was asked to hold off due to some rechartering issue. @alastc @awkawk is that still the case? I am waiting for the all-clear.

[Myndex]

HI @svgeesus

That used to be the case but is no longer. All modern iOS and OSX devices use image-p3. Higher-end Android devices such as Samsung Galaxy also use a WCG similar to image-pr in gamut. Modern TVs typically support WCG and HDR, increasingly aslo have embedded web browsers, and there is thus a need to composite SDR Web content onto WCG and HDR content (delivered using REC.2020, but in practice only using around the DCI P3 gamut volume).

As it happens I have been using wide gamut displays since 2008 (and it's probably what caused my early cataracts - yikes). My main display is an NEC PA271 with an internal 14 but LUT. I was sad when xvYCC died on the vine, but I am really glad to see the emergence of more wide gamut displays (not the least of which is I expect them to get cheaper! I think I've spent more on displays than on computers). I am also a big Apple user, so very familiar Apple products.

Side note on Apple's "Display-P3" (aka image-p3 in CSS4) _ notably different than DCI-P3. DCI is D63 with a gamma of 1/2.6. Apple Display-P3 is D65 with an sRGB gamma curve. However on some devices 16 bit is supported.

But let me explain my viewpoint a lit more in-depth. First, no, not all Apple products use P3. The top-end ones do, like iMacPro and MacBook Pro. But Macbook air, regular Macbook, Imac 21" do not, they are sRGB. The same is true for iPads - Pro is P3, but not all of them. Current iPhones (as in available new) range from the SE and 6, 6s, 6plus are sRGB. 7 thru Xs are of course P3.

EXPENSIVE Wide gamut displays that cover most of P3 are still very expensive — two to three times the cost of a similar sized sRGB monitor, though I am hopeful that prices come down, as they eventually should if more people adopt. I have seen some lower cost "HDR" displays, though their specs say nothing about actual coverage of any specific gamut. (I assume they are just Rec709 that "accept" an HDR/Rec2020 signal and transform it to Rec709).

MINORITY MARKET SHARE According to ITS, current market share for all wide gamut monitors is under 20%. Current market share for iPhone is 23%, and if a generous 75% is iPhone 7 and up, that still means 82% of phones are NOT Apple Display-P3. True, Samsung has their own wide gamut variant, and I hear they almost have color management working. So, lets say, generously, that there is a 25% to 30% market penetration by the end of this year. That's still 70%-75% sRGB. And most mobile devices do not have color management, because it is computationally expensive. Color management slows down phones and drains batteries, and needlessly so.

sRGB is Still the defined standard. With Apple products that have display P3, they still display pages and untagged images as sRGB. sRGB is the defined standard for the web, and CSS level 4 is still a working draft and not a standard.

That is the jist of what I meant by my original comment.

P3, WGC, HDR, and sRGB in terms of Accessibility. In terms of accessibility, improving luminance contrast helps certain vision impairments. I suppose a case can be made that higher bit depths and HDR with higher dynamic contrast could be helpful. But when it comes to larger gamuts, not necessarily. A larger color space with primaries a farther distance apart does not give you greater contrast nor dynamic range. A higher bit depth does that.

In fact, extreme color contrasts can cause vision PROBLEMS. Chromatic aberration between blue and red for instance. Moving primaries farther away (wavelength wise) only exacerbates the problem, and chromatic aberration is an increasing problem for aging eyes.

And Sure, I have a Samsung TV with a web browser. It's worthless, LOL. And ALL these wide gamut systems support sRGB (though from what I've read Samsung color manglement is less than functional).

In short:

• sRGB is still the web standard, CSS4 not withstanding (and CSS4 still a draft)
• sRGB will remain the DEFAULT when CSS4 is adopted.
• P3 devices convert sRGB to the display profile.
• P3 and WGC require color management, which slows the user experience especially in mobile, as well as increasing battery drain.
• As it applies to CONTRAST and CSS colors — limited benefit and possible detriment, as accessibility concerns are more directed toward larger fonts, higher luminance contrast, no reliance on color contrasts, and minimizing chromatic aberration causing color pairs.
• If you have specific images that would be served by displaying in a wider gamut, they can snd should be tagged with the profile, and will display on color managed systems with that tag, even if the rest of the page is designed around sRGB.

As such, I stand by my original comment (except maybe less hyperbole). The best choice for general and accessible web design is sRGB. I'll just add that tagged images of alternate spaces could be utilized more as more systems become able to take advantage.

Also, the xy chromaticity diagram is a very poor way to visualize gamut volume differences. It exaggerates small changes in green primary chromaticity, hides large changes in red and blue, and fails to show the gamut volume shape for dark and light colors.

Yes, but A) I don't have a Luv spectral diagram that also has those three colorspaces overlaid (Ive been meaning to make one), B) the 1931 diagram is still the one in most common use, so it is the one that most are comfortable with, C) That said I do use the Luv when I can and D) Not at all the point though, I wasn't comparing gamut volumes, in context, I was just making an example of how the green primary changed between spaces, and the 1931 chart illustrated that well even if not perceptually uniform.

Yes, I am on the hook to do that, but was asked to hold off due to some rechartering issue.

Cool... I think I mentioned before, it's concerning when a standards document has such an error as it damages credibility IMO...

Cheers

[alastc]

Hi @svgeesus - we're actively working on WCAG 2.2 now, so a PR on a branch from master focused on updating the value would get attention fairly soon.

@Myndex

sRGB is still the web standard, CSS4 not withstanding (and CSS4 still a draft)

It's worth knowing that W3C standards formalise what has already been implemented in at least 2 browsers. I.e. the process is to write, implement and test as part of the same process. By the time it gets to candidate recommendation it is probably already being used by the public, and in fact I can see the effects in Chrome now with images I save as P3.

I don't think we need to get into that too much though, I think we're agreeing that we should standardise testing on sRGB anyway.

[Myndex]

Hi @alastc

Got it, I typically base “is it implemented” on caniuse.com and chrome & Mozilla docs, which don’t indicate any support for alternate color spaces. Though my point as you indicated is that sRGB is the appropriate space for 8bit and for accessibility.

The “worst” space is something like prophoto. Don’t get me wrong, as a designer I think it’s kind of neat that things like advanced compositing modes are being added — linear working space, floating point, transfer modes like multiply, ADD, overlay , Lab color etc etc — but from a practical IT point of view, I question their utility for a production server.

Those are all things I use daily in VFX, but they are all computational and bandwidth expensive. ProPhoto with a D50 wp is in particular a terrible choice for a public production webpage. On the other hand perhaps useful for “live proof” for printing? Still leaves a lot to “chance” and usability issues.

sRGB is an ideal default for 8 bit ... in five years who knows...

[Myndex]

For THIS one, is someone making a pull request? because I was about to.

Yes, I am on the hook to do that, but was asked to hold off due to some rechartering issue. @alastc @awkawk is that still the case? I am waiting for the all-clear.

Hi @svgeesus

Along with the pull request to fix the threshold in the sRGB equation, I'm thinking it would be good to remove the reference to the old working draft for sRGB. And for an up to date reference, the ITU spec "Television Colorimetry" is both free and authoritative, as opposed to the IEC spec which is inaccessible.

sRGB on page 14: https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2380-2-2018-PDF-E.pdf

Thank you

Andy

[svgeesus]

Along with the pull request to fix the threshold in the sRGB equation, I'm thinking it would be good to remove the reference to the old working draft for sRGB.

Yes, I have been arguing for that earlier in this thread, and it was accepted.

And for an up to date reference, the ITU spec "Television Colorimetry" is both free and authoritative, as opposed to the IEC spec which is inaccessible

Interesting, I did not know that! Thanks! I'm going to update the sRGB reference on specref so that new and updated specs use this automatically.

[Myndex]

Interesting, I did not know that! Thanks! I'm going to update the sRGB reference on specref so that new and updated specs use this automatically.

I traced back to the IEC standard,

One thing I've noticed all over the net though is a curious set of equations that suggest that sRGB to YCC should be using the 601 coefficients (... I would SO like to see if that is in the IEC standard for bg-sRGB and scRGB.)

The Rec709 -> YCC math shows the .21/.71/.07 coefficients. I've seen sRGB to YCC using either, and on gamma encoded R´G´B´

EDIT: The sRGB to YCbCr use of the BT.601 coefficients .30 .59 .11 is for 720x576 and smaller, i.e. standard definition, for compatibility with legacy media.

[svgeesus]

video has a bad habit of computing luminance from the gamma-encoded rather than the linear components.

and people in general have a terrible cargo-cult tenancy to blindly use an RGB to Y equation "they found somewhere" which is derived from the NTSC chromaticity values.

[Myndex]

video has a bad habit of computing luminance from the gamma-encoded rather than the linear components. and people in general have a terrible cargo-cult tenancy to blindly use an RGB to Y equation "they found somewhere" which is derived from the NTSC chromaticity values.

Hey @svgeesus — yes I agree they do! The worst offenders are those using (R+G+B)/3 (yikes!) But using the coefficients while gamma encoded leads to similar errors (Yet both NTSC and Rec709 specify using the coefficients WHILE gamma encoded - hooray for inconsistency in technology...not).

WCAG L Equation

For the subject of this thread, Here is the comparison between the wrong threshold value (WCAG) and the correct value, using 8bit color:

No errors using 8 bit — I couldn't find an 8 bit value that was affected by the error. Nevertheless, someday it should be addressed & corrected, as I find people using and referencing this on a fairly regular basis.

(And to be clear to anyone else reading, this WCAG error in sRGBtoY math is distinctly separate from the contrast-math problem being discussed in 695).

[WayneEDick]

Dear Andre ,

Tom Jewett and I have been reading your work and find it quite interesting. We would like to arrange a meeting with you doe compare your results with our observations. Tom has developed a hand tool to test various contrast tests. He has scaled them to be compatible with the scale used by WCAG (0 to 21) to enable simple visual comparison with each other. You might find it interesting: https://colortutorial.design/LRtest.html.

We would like to meet. My email [removed by Alastair and emailed separately], we will arrange an online conference room for us. The modified Weber contrast looks very interesting.

A review of this formula is overdue.

Best, Wayne Dick

[svgeesus]

No errors using 8 bit — I couldn't find an 8 bit value that was affected by the error. Nevertheless, someday it should be addressed & corrected, as I find people using and referencing this on a fairly regular basis.

As expected, and as I said earlier. The error should still be corrected, for two reasons:

• referencing an ancient, intermediate draft of a long-finished and published spec just because it contains a known and minor error due to sloppy rounding is just bizarre
• 10 bit is increasingly used and 12 bit will become more common (already used in Rec.2020 for example)

[rolandog]

Quoting from @svgeesus 's former reference:

I see that the value 0.04045 needs to be added to https://www.w3.org/TR/WCAG21/relative-luminance.xml as well.

I noticed that there are some validation errors, as well as some warnings from Firefox:

MathML attributes “background”, “color”, “fontfamily”, “fontsize”, “fontstyle” and “fontweight” are deprecated and will be removed at a future date

Should I file a separate bug or, perhaps when using a more recent editor, these may go away? For reference, here are some comments from the source:

<!-- edited with XMLSpy v2006 rel. 3 sp1 (http://www.altova.com) by Ben Caldwell (W3C) -->
<!-- use of valid doctype here breaks IE DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
        "http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd"-->

[patrickhlauke]

just wondering if this discussion came to any kind of resolution on whether or not the normative definitions need to be tweaked/updated for 2.x, or if we're happy for now with the slightly inaccurate/handwavy way luminance is being used /cc @davidofyork

[bruce-usab]

@patrickhlauke , my understanding is that the WG does not have the consensus appetite for working on normative editorials (for lack of a better term) for 2.2, but I would be hard pressed to point you to the minutes of the meeting where this became clear to me. I am pinging @alastc since I am so very very impressed by his ability to index this sort of detail.

[alastc]

Yea, there's a feeling of: It makes no apparent difference to update the number in the documentation (to the results of testing), so there doesn't seem to be any point in updating it. The approach in WCAG 3.0 is completely different, focus best placed on that.

I believe Bruce created a new technique to use the newer number, which is in the queue of issues once we get 2.2 out for review.

[Myndex]

Just to casually step over this poor dead horse: changing the sRGB linearization math to be correct instead of wrong has no effect on results for this narrow use case, the problem is more of optics as it degrades credibility by having a known incorrect piece of math in public view. Also the trickle down of people using these wrong thresholds and using it for whatever other purpose is an annoying persistent problem.

The actual (substantial) problem with the math and methods are elsewhere, and unrelated to this error, as well established now.

IRONICALLY: it is this little error that first caught my attention as it leapt out at me, because I use the sRGB math (the correct one) frequently in film work. This is what caused me to dig deeper, and I wonder if I would have gotten so involved into the other "more hidden" issues if this little bit had been correct? It would not have caught my attention... It was sort of a tip of the iceberg or something...