Is the term "ambient light" correct in this context? #1
Comments
|
Thanks for the feedback! The idea that the 0.05 represents ambient light comes from the paper by Hwaung/Peli which was referenced in wcag#695 as "modified Weber". The 0.4 was just a rough guess. I added a note in fcadae0. The point is that you can get something that is very similar to APCA by tuning a single parameter. That doesn't necessarily mean that APCA doesn't have additional benefits. But still an interesting observation. As for scaling: As explained in the analysis, this doesn't change anything about the color math and is really only about developer ergonomics. For example, you could add I am not sure I fully understand your last paragraph. Can you give more context on that? As I see it, web authors don't know the light conditions under which their content will be used. So there is no way to account for the actual ambient light. What WCAG 2.x does instead is to account for some ambient light. APCA now poses the question whether the 0.05 was too optimistic and we should go more in a worst-case-scenario direction. (More ambient light results in a lower contrast.) |
|
Hi Bruce, Tobias @bruce-usab @xi First, Tobias, thank you for your in-depth analysis. As I mentioned in my response to the issue you posted in Silver, there are things we should discuss. However, for THIS post I am going to constrain my comments to the above posts from Bruce and Tobias—I am going to respond to both at once here, and may include Tobias quotes from the introduction document itself. PART ONE: Answering The Above Posts
The plain language APCA introduction is "Why APCA™" and Bruce, I would love to hear your take on this, if you haven't read it yet...
As it happens in the understanding doc, it indicates it was derived from the sRGB standard that references a 0.05 Y flare component. It is nevertheless applied inappropriately. It does have the effect of limiting the max contrast to 21:1 but that is still not enough to fix the functional problems.
No, the 0.05 applied to both sides was from WCAG 2, in the understanding doc, claiming it was the flare component (NOT ambient light, flare, which is markedly different). The Hwaung/Peli modWeber uses an asymmetric 0.05 i.e. on only one side (that's the mod). The Somers modWeber uses a significantly higher value, and additional offsets. Nevertheless we moved past it for a large variety of reasons.
The plots did not make a lot of sense to me (until I examined the code), and they show that the 0.4 mod is divergent from APCA by ~20% or more??, and this is not an apples to apples comparison—it is making a comparison between two very different values and approaches. I am really confused here as to what Tobias is trying to show.
No, not across hue/chroma variations and not at specific value levels, and not over the full range. The resultant contrast value curves are notably different. Yes, there is some improvement, but it is not perceptually uniform—that is, the degree of change does not follow perception over the range. While this may not be immediately apparent, you are comparing a linear light value (luminance) that has this arbitrary 0.4 addition, which has no empirical support at all. Okay, so this 0.4 does appear to partially reverse engineer the APCA contrast curves "kinda", and then comparing it to APCA's modified CAM02/RLab/Stevens power curves, which include the built-in, simplified adaptation, spatial frequency, polarity, and other key considerations. IN OTHER WORDS:We spent 3 years researching and developing APCA™, and you are simply attempting to match the output values with a reverse engineered math. But your approach is not considering multiple aspects of the several color appearance models, peer reviewed vision science, and live studies, that form the foundation for APCA™. And to be clear, it is not a complete alignment, at most it approximates the APCA contrast curves, but not for polarity, not ∆ uniform, etc.
There are several advantages. The design goals of APCA™:
Just tossing in 0.4 as an addition does not achieve these goals, though it may mimic some of APCA™ is is most definitely NOT APCA™.
Partially false, because there is an early stage scaling adjustment that definitely does affect the color math and hue representation. But more importantly: developer ergonomics are not to be waved away as unimportant. They are a very important part of developing wide acceptance so the guidelines are adopted and actually USED. Minimizing the importance here to support the reverse engineered math is notwithstanding.
Yes!Though I might say "perceptually spread out" instead of geometrically, and this is key to having a functional metric that is stable and easy to use by designers. It is ALSO very important for automated systems. And it is the automated color systems where WCAG2 really breaks down, as "4.5:1" is not uniform in appearance from light colors to dark colors. I've shown this before, but:
So this problem interferes with creating automated color schemes, and automated color schemes that are responsive to USER NEEDS is the actual direction we went to go. APCA™ is designed to facilitate this.
This is a misunderstanding. The human vision system (HVS) is extremely context sensitive, and it adapts to the range it is in. The HVS is not good at judging absolute light values, but the HVS is very good regarding relative values, and a key contextual factor here is light adaptation. We can make reasonable assumptions (some of which are defined in international standards), and we know where "things get bungled up" and therefore we can base the guidelines on a common poor-case environment. I have a 90 minute long power point presentation that shows this. Someday the book will be ready too.
No, WCAG 2 claims it is adjusting for screen flare. And ambient light here is defined in the IEC document, along with gamma and other aspects, not that those are relevant in 2022. There is way more here, and it is not centered on the global "ambient" light. I realize it is tempting to simplify it that way, but to do so ignores the more important factors. Here though is a key point: you are under the impression that the 0.4 you added to WCAG2 somehow models high ambient light, and the answer is no, not at all, and that has essentially nothing to do with APCA. There are a dozen or so psychophysical factors at play here, and I don't have a simple response, other than "APCA is specifically related to contrast appearance of high spatial frequency stimuli on self-illuminated RGB computer displays & devices, with a focus on readability and accessibility". All the 0.4Y you added does is reverse engineer the curves we developed and established over the last three years of research and development. That is where the heavy lifting is. Because I've been open about the work and the math, it is plain to see, and sure, there are all sorts of ways to reverse engineer the math and code you can see. But that is not solving the larger problem, it's just copying over someone else's work. For instance, what are you going to do with WGC HDR color spaces? What about user needs? What about modeling certain impairments? You're not doing the work to develop the curves, you are just copying them and force-fitting different math to them, and for no useful effect.
APCA has multiple features that specifically are set around the "worst common" ambient lighting. The full version does more than a pair of colors. But the W3 public beta is just a pair to keep things simple. In discussion with Chris Lilly, three colors is probably a useful maximum. Nevertheless, some applications may have good use for the 4 or 5 input model.
It's not.... Some of the standards in this area range from "WTF" to "OMG" to "LOL". Luminance does not model perception, it models light in the real world, it needs to be transformed to model perception. Dr. Arditi has a compelling paper on how the current contrast maths are not functionally useful for signage. Rethinking ADA signage standards for low-vision accessibility Nevertheless, I think a variant of APCA could be applied to the architectural signage problem. It is a more complicated problem: with self illuminated devices, the device is often the illuminant driving adaptation. For architectural signage, the illumination that is driving adaptation is somewhere between about 2 feet and 93 million miles away, and has the power somewhere between a candle flame and nuclear fusion. 😎 Thank you for reading! AndyNote [1] "Perceptual uniformity" is a vision science term. Yes, we know that it is impossible to model all forms of vision—but we CAN model the general, and also understand offsets and user needs outside of that range. But the statement that "there is no such thing as perceptual uniformity" is not accurate at all. We are not talking about absolute uniformity from one user to the next, we are talking about relative uniformity across the visual range. |
|
I think we should settle whether the 0.05 in the WCAG 2.x formula models ambient light or not.
The Hwaung/Peli uses the form
I assume you are referring to the notes on formula which state: "The ANSI/HFS 100-1988 standard calls for the contribution from ambient light to be included in the calculation of L1 and L2. The .05 value used is based on Typical Viewing Flare from [[IEC-4WD]]." This uses both terms "ambient light" and "typical viewing flare". I must admit I have no idea what flare even is, so some clarification would be helpful (wikipedia was not helpful with this). Regardless of the sources, it simply makes sense to me that a value that is added everywhere models the light that exists everywhere in the system, i.e. ambient light. But I am not a color expert and will be happy to change the wording if there is conclusive evidence. So what could this be other than ambient light? "Flare" seems to be a term that often comes up. Is that more accurate in this context and what does it mean exactly? |
xi
changed the title
|
I don't want the discussion to go off track, so I changed the title to focus on a single question. Please open separate issues for anything not directly related to the new title. |
My apologies for my misunderstanding. I am not sure how I came to believe the 0.05 was just to help with the rounding, and with setting the floor at 1 instead of 0. From Understanding Notes on formula (TR edition [early publication but identical to 2.1 cite above], emphasis added):
|
The U.S. Access Board promulgates accessibility standards for brick-and-mortar facilities, and those include a contrast requirement for building signage. The article Andy cites includes excellent background exposition. Thank you @Myndex!
The maths are about half-way through, including a discussion of the mythical 70% figure. From that article, I also now have a new favorite term: ipse dixit. Thank you again @xi for this introduction to APCA. I am of the opinion that this issue may be closed. |
It does not model ambient light at all. It does not correctly model flare, either.
The only functional difference is that one is a ratio and the other is a percentage. You and I discussed this three years ago in thread 695.
Let's not start going over the WCAG 2 understanding document, which was written by people that have no understanding of vision or color science. That said, "flare" is the REFLECTION of light on the front surface of the display, and AMBIENT is the total illumination in the given environment, which partially drives adaptation. They are not at all the same thing.
It is much more complicated than that. The 0.4 you applied happens to crudely and incompletely reverse engineer the APCA contrast curves, nothing more.
I don't understand your question. Flare is the added luminance from reflection on the face of the monitor. |
No, it is to account for viewing flare (ambient light reflected back from the display,which adds to the light emitted by the display). 5% of the media white is far too high a correction, by the way; the sRGB standard gives an ambient flare of 0.2 cd/m2 which, with a white level of 80 cd/m2 is 0.25% - so we would add 0.0025 It does, though, mean that the denominator cannot be zero so code doesn't need to check for that. |
|
Hwaung/Peli also explains:
So, if flare is light that is being reflected by the screen, we can consider "flare" and "ambient light" to be the same thing. With that and the comment by @svgeesus I consider this settled. Whether 0.05, 0.4 or 0.0025 is the best value is a separate issue that should be discussed in the context of the standards themselves. This repo only summarizes what the standards say. |
|
So (to answer the question which is the title of this issue): No. Ambient light is the diffuse light bouncing around a room. It is measured in lux. For example, the sRGB standard states that the default viewing conditions are an ambient level of 64 lux. Flare is an addition to the light output by a display, caused by the reflection of some of the ambient light. It depends on the level of ambient light, sure. It also depends on the reflectivity of the display (a shiny glass CRT reflects a lot more than a matte LCD). It is generally assumed that there is no significant wavelength-dependent absorption, ie the color of the ambient light and the color of the flare is the same. Flare is measured in the same units as luminance - candelas per square meter, cd/m2, also known as nits. |
See my previous comment, and please re-open the issue. |
|
It seems we were working at the same time 😃 So do I understand correctly that "flare" means "part of the ambient light that is reflected by the screen" and that it is the better term in this case? |
|
Right. |
|
Could you please have a look at #4 to see if it fixes the wording? |
|
Just to interject as I did substantial investigation into the genesis of the WCAG 2.0 contrast method. The 0.05, as used, is not particularly helpful. It would have been slightly more helpful if it was applied asymmetrically, however, that again is not modeling ambient nor flare, but instead causing a manipulation of the resultant contrast curves. Here is a screenshot of the IEC standard that was used as the "basis" of the 0.05:
This is from the "Annex D: Typical Viewing Conditions" section. And again, the way it was/is being used is not appropriate. ALSO, the sRGB standard referred to CRT displays, not LCD displays, which have an all-together different flare characteristic. |
|
I changed the wording to "flare" throughout the document, so I consider this fixed. |
Thanks for this APCA Introduction!
In your detailed analysis, you mention:
FWIW, I had always presumed that tweak was just to avoid division by zero.
With your very helpful comparison plots, you mention:
Might you add some exposition regarding how you picked .4 and how that is a factor for ambient light?
My understanding is that the main advantage with the APCA algorithm is using values tuned to LCD/LED instead of CRT. It also seems to me that the values APCA returns are geometrically spread out in a more useful range. That is, while the 2.x metric varies from 1 to 21, 7:1 is the highest referenced value, and at about 12:1 is hard discern hue at all (for text).
As interested as I am in a better contrast formula for WCAG3, being able to account for ambient light would be huge. There is interest with having facility/signage contrast requirements that are more sophisticated than what we currently have. Light meters used with photography provide an easy way to measure luminance, but I have never read a compelling explanation of how that is sufficient for print foreground/background.
The text was updated successfully, but these errors were encountered: