Non-sRGB color spaces, outdated sRGB threshold, and other issues in the "relative luminance" definition #360
Comments
|
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:
|
|
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. |
|
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. |
|
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? |
|
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. |
|
This issue did not port properly. Check w3c/wcag21/#815 for the remainder of the context. |
|
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. |
|
Concerning relative luminance:
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. |
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. |
|
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 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 |
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.
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.
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 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.
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.
Unfortunately that currently depends on how the picker is implemented. |
|
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) |
|
Thanks @svgeesus, interesting article. I thinking I'm getting it, ish. So my working assumptions are:
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? |
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 :) |
|
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: 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. Would that make sense? |
|
@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. |
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? |
|
@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. |
|
In section 6 Glossary , which appears to be normative, the definition of relative luminance is
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 :
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
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 |
|
The references do not include a normative definition for luminance. The correct definition would be 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. |
|
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 |
|
As noted by @peteroupc in the original thread:
and sure enough, Understanding Success Criterion 1.4.3 just says
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:
|
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. |
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?
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). |
|
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.
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 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. |
|
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 WCAG L EquationFor 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). |
|
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
|
As expected, and as I said earlier. The error should still be corrected, for two reasons:
|
|
Quoting from @svgeesus 's former reference:
I noticed that there are some validation errors, as well as some warnings from Firefox:
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"--> |
|
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 |
|
@patrickhlauke , my understanding is that the WG does not have the consensus appetite for working on |
|
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. |
|
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... |
and others
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
either0.04045or 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
The text was updated successfully, but these errors were encountered: