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

Flare correction of 0.4 (40%) #3

Open
svgeesus opened this issue Jul 28, 2022 · 6 comments
Open

Flare correction of 0.4 (40%) #3

svgeesus opened this issue Jul 28, 2022 · 6 comments

Comments

@svgeesus
Copy link

The claim is made that a WCAG 2.1 luminance contrast formula with a flare correction of 40%, rather than 5%, gives high correlation to the results from APCA.

5% is already far too high.

40% means that black (#000) looks the same as color(srgb-linear 0.4 0.4 0.4) which is rgb(66.52% 66.52% 66.52%) or in other words, a pretty light grey.

That can happen, for example a dim projector in a bright room on a white screen, with the audience saying "we can't read the slides". But it doesn't seem a reasonable basis for a lightness contrast algorithm.

The observed correlation is interesting, certainly, but I don't see flare correction as a reasonable model to explain the correlation.

I also don't really see the WCAG luminance ratio (tweaked or not) as a useful model going forward, because luminance is not at all perceptually uniform. Simply put, a mid grey is no where near the middle in a black to white luminance ramp, while it is at the middle in CIE Lightness or OKLab Lightness or UCS16 J, all of which try to model perceptually uniform lightness.

@xi
Copy link
Owner

xi commented Jul 28, 2022

So what is your conclusion? I can think of different possible interpretations:

  1. A flare correction of 40% is far too high, so the modified WCAG 2.1 formula should not be used. Since APCA strongly correlates with the modified WCAG 2.1 formula, it should not be used either.
  2. A flare correction of 40% is far too high. The modified WCAG 2.1 formula only works by accident and is not physically meaningful, so it should not be used. APCA has similar results, but also a physically meaningful structure.
  3. A flare correction of 40% is far too high, so the modified WCAG 2.1 formula should not be used. It also does not actually correlate with APCA because there was an error in the calculation.

Do you have an idea which one it is?

@Myndex
Copy link

Myndex commented Jul 28, 2022

It is most likely (2)

A flare correction of 40% is far too high. The modified WCAG 2.1 formula only works by accident and is not physically meaningful, so it should not be used. APCA has similar results, but also a physically meaningful structure.

And again, your assertions that it is "close" seems to ignore the fact that you are comparing apples to triangles. The curves are visibly different by over 20%.

And to mention, #3 — you are not calculating APCA the way APCA is intended to be used. You wave off the scaling which you consider unimportant, but which is key for perceptual uniformity. You can not just disregard aspects of APCA design because you don't like them.

In the "analysis" you state:

"I am a regular web developer with a bachelor's degree in math, but without any training in the science around visual perception. That's why I cannot evaluate whether APCA is better than WCAG 2.x. Instead this is a systematic comparison of their mathemetical properties."

You can not assert a claim of "analysis" based on twisting the math around to suit your narrative. I've reviewed your analysis, and it is ignoring the key issues entirely, and misdirecting readers toward spurious conclusions.

@xi
Copy link
Owner

xi commented Jul 29, 2022

I thought about this some more. When I use my phone on a sunny day, the idea that reflected ambient light is 40% of the white that the screen can produce doesn't sound so unreasonable. A value of 0.25% (as you have proposed in #1 (comment)) feels much too low for that situation.

In the context of WCAG we have to consider worst case scenarios. So can you provide more context on the range of possible values?

@Myndex
Copy link

Myndex commented Jul 29, 2022

I thought about this some more. When I use my phone on a sunny day, the idea that reflected ambient light is 40% of the white that the screen can produce doesn't sound so unreasonable.

Think again then. On a sunny day, the sun is at about 1.6 Gcd/m2 and less than 10% of that would cause retinal damage. 40% would be like a laser searing your retina into fried bacon.

And moreover, this statement of yours indicates a misunderstanding of the concept, which Chris already succinctly described, so reconsider.

A 40% flare means the face of the display is nearly half the brightness of the room, and it does not take a math genius to see that is not at all the case.

@xi
Copy link
Owner

xi commented Jul 29, 2022

You misunderstood. In (Yfg + 0.05) / (Ybg + 0.05), all the values are in relation to the colors on the screen, not to the brightness of the room. I think this is an important distinction. 40% of the brightness of #fff will certainly not cause retinal damage.

@Myndex
Copy link

Myndex commented Jul 29, 2022

You misunderstood. In (Yfg + 0.05) / (Ybg + 0.05), all the values are in relation to the colors on the screen, not to the brightness of the room. I think this is an important distinction. 40% of the brightness of #fff will certainly not cause retinal damage.

Actually no. But again, this entire "0.4" thing you are doing is not supported by anything. The reference flare indicated is in reference to the "typical" ambient defined in the spec—the 0.05 references a CRT display in ambient of 350lux.

Regardless, as used it is not useful.

The fact that you stumbled onto a crude but inaccurate and incomplete way to brute force this 180 year old math into something a little closer to the defined perceptual curves is notwithstanding, and it ignores the entirety of the science behind it.

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

No branches or pull requests

3 participants