Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
michael-n-cooper opened this issue Jun 12, 2018 · 47 comments · Fixed by #1780

Comments

@michael-n-cooper
Copy link
Member

michael-n-cooper commented Jun 12, 2018

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
Copy link
Member Author

michael-n-cooper commented Jun 12, 2018

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:

@michael-n-cooper
Copy link
Member Author

michael-n-cooper commented Jun 12, 2018

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
Copy link
Member Author

michael-n-cooper commented Jun 12, 2018

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
Copy link
Member Author

michael-n-cooper commented Jun 12, 2018

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
Copy link
Member Author

michael-n-cooper commented Jun 12, 2018

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
Copy link
Member Author

michael-n-cooper commented Jun 12, 2018

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

@svgeesus
Copy link
Contributor

svgeesus commented Sep 6, 2018

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
Copy link
Contributor

svgeesus commented Sep 6, 2018

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
Copy link
Contributor

svgeesus commented Sep 6, 2018

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
Copy link
Contributor

alastc commented Sep 7, 2018

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
Copy link
Contributor

svgeesus commented Sep 21, 2018

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.

@svgeesus
Copy link
Contributor

svgeesus commented Oct 1, 2018

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
Copy link
Contributor

alastc commented Oct 1, 2018

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
Copy link
Contributor

svgeesus commented Oct 15, 2018

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
Copy link
Contributor

alastc commented Oct 15, 2018

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
Copy link
Member

patrickhlauke commented Oct 15, 2018

@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
Copy link
Contributor

svgeesus commented Jan 9, 2019

@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
Copy link
Member

awkawk commented Jan 9, 2019

@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
Copy link
Contributor

svgeesus commented Jan 12, 2019

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
Copy link
Contributor

svgeesus commented Jan 12, 2019

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
Copy link
Contributor

svgeesus commented Jan 12, 2019

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
Copy link
Contributor

svgeesus commented Jan 12, 2019

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
Copy link
Contributor

alastc commented Jan 14, 2019

"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
Copy link
Contributor

svgeesus commented Jan 15, 2019

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
Copy link
Contributor

alastc commented Jan 15, 2019

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
Copy link
Contributor

svgeesus commented May 2, 2019

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
Copy link

Myndex commented Jun 4, 2019

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:

Screen Shot 2019-06-04 at 2 32 06 AM

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
Copy link
Contributor

WayneEDick commented Jun 4, 2019

@svgeesus
Copy link
Contributor

svgeesus commented Mar 31, 2020

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
Copy link

rolandog commented May 29, 2020

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
Copy link
Member

patrickhlauke commented Jan 14, 2021

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
Copy link
Contributor

bruce-usab commented Jan 14, 2021

@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
Copy link
Contributor

alastc commented Jan 18, 2021

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
Copy link

Myndex commented Jan 19, 2021

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

@ValZapod
Copy link

ValZapod commented Feb 20, 2021

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'm starting to feel like people don't like math or something... ) I've seen sRGB to YCC using either, and on gamma encoded R´G´ B´ — something must be wrong somewhere...

I have all IEC standards, so I can look. I suppose you are slightly confusing BT.709 and sRGB transfer functions (both EOTF and OETF). They are different and even though Chrome uses sRGB EOTF to display BT.709 video, it is not correct (though better than to use BT.1886 (almost 2.4 gamma) as that is for dim environment, while all canvas is for 200 lux sRGB, inverse BT.709 OETF as EOTF is also wrong). The correct way is for example to use Apple TrueTone. sRGB (and sYCC) always used BT.601 matrix (it should not be called sRGB, then, more like sYCC without negative RGB values), nothing wrong with that. JPEG full range IS actually BT.601 matrix with BT.709 primaries and so is PhotoYCC (though there it uses bare BT.601 matrix). Just look into https://en.wikipedia.org/wiki/YCbCr#JPEG_conversion and compare with https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.601_conversion. xvYCC (which is video format, continuation of PhotoCD's PhotoYCC and BT.709 transfer) already introduces both of the matrices, in HDMI EDID Colorimetry block there is xvYCC_601 and xvYCC_709. (See https://github.com/ValZapod/edid-decode/blob/2e016dd4a44771184a13ebd55d5b3f294b99751b/parse-cta-block.cpp#L1600.)

Now, sYCC in EDID (61966-2–1's Amendment 1) uses BT.601 matrix too. It further defines sRGB transfer function as xvYCC does for BT.709, that extends gamut by using out-of-gamut YCC values that are converted to negative RGB values (those are calculated immediately with XYZ matrix after transfer)! It is full range though, while mandatory limited range xvYCC uses also not legal for broadcast values (for 8 bit outside of 16-235 for luma and 16-240 for chroma). But for example even legal BT.709 values 139, 151, 24 (that is RGB -21, 182, 181) is out-of-gamut for BT.709, but is not for xvYCC_709, and to convert those values to display gamut you would convert to XYZ (0.27018, 0.40327, 0.54109) and then to display gamut.

Now, bg-sRGB and bg-sYCC (61966-2–1's Amendment 1 again) are even more crazy. bg-sRGB, obviously, does not use any matrix, BT.601 or BT.709 or whatever else. It is RGB! Matrix is for RGB to YCC and back. And bg-sYCC also uses BT.601 matrix. The difference is only in quantization.
image

It does not matter what matrix you use! BT.601 matrix with enough precision will be enough.
image

I will also add that those old values of sRGB as was in first draft were just values used in NIF RGB as used in FlashPix format, that was a real predecessor of sRGB. http://www.graphcomp.com/info/specs/livepicture/fpx.pdf

scYCC-nl also uses BT.601:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants