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 w3c/wcag21#815 (comment)

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: #36;} 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.