APCA Luminance calculation non-standard, up to 2.5% deviation #643
Comments
svgeesus
added
bug
|
Hi Chris @svgeesus I'd like to respond with a short answer before getting into the larger discussion, which may ultimately be moot. It's not incorrect because it is not intended to create standard luminance, and this is in the documentation, though as you pointed out before, I need to spend some time organizing the docs. It's funny as I almost made a comment in the CSS 4 thread regarding the And, this is something I'm happy to do, and certainly for the W3 version. But I was going to wait until there was some other change needed, in the effort to keep the changes of the base algorithm minimal. That Said (in depth answer)General:While adopting CSS 4 srgb-linear might make the following discussion either moot or academic, I don't want you to think that I was using 2.4γ capriciously or without good reason. I remember you bringing the point before; using something closer to the defined sRGB standard has in fact been on my mind. Nevertheless, I wanted more data and feedback from the public beta before making more changes to something that otherwise has been performing well and stably. Otherwise, below is intended to define the motivation/intent which I think might be misunderstood. Firstly, keeping in mind that this is beta, therefore experimental, there are research reasons for using a simple exponent for the ...toY, and also not splitting into multiple power curves at the input stage. And I recognize (and assumed) that eventually things would be split and compartmentalized in the interest of standardization, commonality, etc. But doing it at an early stage of development would only interfere with the already complex process of determining the plurality of exponents & constants for the independent power curves etc. Responses
Well, "correct" is relative to a context, given use case, and/or the totality of the usage, as I hope to show: The reasons and motivations are discussed in documentation in the discussions tab and the documentation folder. It is not "incorrect" given the specific use case—there is no output of Y in this function, i.e. the processed Ys (estimated screen luminance) is not created for use by any other function, and it's not even created by the APCA function, it's with a set of utility functions for pre-processing. IEC 61966-2-1 sRGB [1]The IEC standard states the EOTF as a simple gamma of 2.2 about four times in the document, including equation (1): As I know you know, the piecewise transform into XYZ was intended to closely match that 2.2γ and not have an infinite slope at zero, this being back when math co-processors were just starting to be standard, and most math was integer.. etc etc. The implication is that either the piecewise or the simple exponent is "correct" depending on use case or context. But there is ambiguity here, and this has been a "lively" area of contention. Here's a link to the first of a few posts I made in a thread on the subject at ACESCentral. Jack Holm, technical secretary for IEC also commented in that thread, thought you might be interested. When I am setting up a workflow around image IO, then I most often do use the piecewise in the working space. An exception is where speed/performance is important, as in streaming media. But that's a delivery/output space as opposed to a working space. Among other things, it is interchange and round trips that are important reasons to use the piecewise, making them more vital in the process of image editing, and in a working space... but... Measuring tapeBut what about for measuring contrast? In this case "interchange" and round tripping are not relevant — no image is being processed & output. Instead, colors/luminance are being measured, and we are most interested in how the monitor displays those colors, that is, we are interested in modeling the display as much as modeling vision or the observer of that display.. And we are testing two colors that both came from sRGB, and through the same power curve. We are not testing the colors against the sRGB piecewise curve itself. What matters here is the colors are pre-weighted to known values, as needed, and then processed to fine contrast. The remainder of the processing is all interconnected. As you see in the math, there is a soft-clip at black—this replaces the linear section (or I should say would just override it making it moot), and the input soft-clip serves a more important purpose relating to veiling glare, and preventing mathematically excessive contrasts if a color is near
An earlier version of APCA used a 2.218 exponent, which put the unity point of "zero error" at ~18% luminance. While I initially had concerns regarding "total error" I think it's better stated as an offset from the piecewise, it's important to note that both the colors being tested will follow the same initial input curve, so "same error - ish" and then it's more or less a wash. In fact we might want all of the shift to be all negative or all positive, instead of positive/negative, and 2.4 gives us an all negative shift from the piecewise. Some notes from way back when: There is a second thing though, an additional reason relating to the coefficients, and some of the problems with the standard rec709/sRGB values: the calculated luminances of a given primary vs an achromatic set of RGB luminance does not match the perceptual intensity when they are matched for visual equality. It is just HK effect? Perhaps. But we also know that the 1931 observer has inaccuracies in blue for instance Using 2.4 at the input stage improves this mis-match, which is how it ended up in use—initially I expected just for a short time but as it happens the base algorithm is working well, so no changes as yet. And no, the 2.4 is not intended as a complete HK solution. Also to be noted, there are some unreleased enhancements such as a protan compensator, a version of which does a direct modification of the coefficients. An area that the WCAG 2 contrast misses is in prohibiting red text on black—WCAG 2 passes it but APCA usually rejects it or forces it veyr large. I discuss this a bit in the article "What's Red and Black and Also Not Read"
That is actually a coincidence, the use of 2.4 is sourced elsewhere. I didn't just "remove the offset" leaving the 2.4 exponent. Another motivation for experimenting with a larger exponent is that some surveys of monitors in the field found that "60% of the monitors were set to a gamma value within the range 2.1 to 2.6, while 10 % were set to gamma 2.7 and the rest to gamma 2.8 or higher." [2][3]
As mentioned not inadvertent nor capricious nor done without reason or considerations including considerations of your stated objections, some of which I posed to myself as my own devil's advisory council at the time. I did discuss both the use of the 2.218 and the 2.4 exponent in some of the white papers, docs, and inline code comments, there are issues or discussions at the repo as well. Here's a list of APCA resources: git.myndex.com
This is definitely one of the reasons. I did not set out to create APCA. I started this in April of 2019 (remember thread 695) starting with evaluation all of the available contrast math/methods and CAMs, etc. One of the key findings was that none of them really tracked small text on self-illuminated monitors, and small text is the biggest contrast problem to fix. And fixing necessitated adjustments to the mid-tone area that needed adjustment in multiple places.
As mentioned, yes, can do. But as also mentioned, there are benefits for some adjustments prior to, or while applying the coefficients.
The way I've handled that in the interim was simply a different function for each, and something like that would be needed in any case.
This is more of a documentation problem. I do (or intended to) refer to it not as Y but Ys for estimated screen luminance specifically for the reason you state. Though I see I missed that in the bottom line of the most recent svg math. I have a glossary post in the discussions area that discusses terms specific to the project. BUT ALSO:It is fairly well accepted practice to have different encoding and decoding TRCs. The easy example is Rec709 [6], which has an OETF of ~1.9 ish, never had an EOTF defined until Rec1886, and there it is now defined as 2.4. Such system gamma gains are common in going from scene referred -> workspace referred -> output referred. And in reality, streaming workflows may have multiple LUTs in multiple locations for various reasons, including different tone response curves. The use of TRCs (different than spec) for a particular purposes is fairly standard in itself, at least here in Hollywood. Regarding sRGB luminance: at least the math I have examined, calculates the XYZ transform matrix based on a point on the 1931 chromaticity diag... but the primaries (except for Rec2020) are not points, more like eccentric spectral blobs. I bring this up because I find a lot of discrepancies between the calculated luminance and the visually perceived luminance on various systems. On the subject of standard observers, I just came across [4] and [5] which discuss standard observers with various kinds of vision. The one thing I can absolutely say about colorimetry is that it's not absolute. Humans are messy, and perception metrics can only define a range. ClosingI hope that answers the questions to your satisfaction Chris, please let me know if there is anything else I can clarify or help with. Thank you for reading Andy References[1] IEC 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2-1: Default RGB Colour Space - sRGB [2] Efthimia Bilissi, Ralph E. Jacobson, and Geoffrey G. Attridge [3] Xuemei Zhang, Yingmei Lavin, D. Amnon Silverstein, "Display gamma is an important factor in Web image viewing," Proc. SPIE 4299, Human Vision and Electronic Imaging VI, (8 June 2001); https://doi.org/10.1117/12.429516 4 Yuta Asano PhD Dissertation, August 2, 2015 5 6 |
|
Also, if I may: the offset indicated in that svg is inflated 400% vertically, relative to the horizontal scale. Set with a equal x and y scale:
Again, it's not a matter of an "error" as it is part of the end to end calculation into the Lc value. |
Thanks for clarifying that this is an intentional shaping. I would still strongly prefer, from a clarity, accuracy, and interoperability perspective, that if you are calculating luminance then you stick to the same luminance definition, which CIE and IEC use, and which is compatible with what CSS and Canvas use, rather than inventing your own. Then feel free to add your own separate luminance shaping step
I do see the soft-clip, yes. As my graph shows, the error from a pure power-law approximation affects the entire range of component values and is not restricted to the near-black region.
The percentage luminance error and the component value are unrelated, so the visualization can use whatever scaling is needed to make the graphic clear, provided the axes are correctly labelled. As more of a higher-level comment - as you know, your formal objection on the CSS Color 5 As part of that, you will see a push to improve the visual contrast part of WCAG 3 so that it meets the standards for CSS referencing it, which currently it does not, at all. That includes having APCA normatively referenced, and having all the constants listed normatively in a /TR publication (including getting obsolete early versions out of the spec and supporting materials), and close scrutiny of the algorithm in general so that it is fully applicable, not just to sRGB, but to all the color spaces that the modern Web is currently adopting. |
Having now read that paper, the experimental design leaves a lot to be desired. The monitor gamma was not measured, but estimated with a visual comparison tool. This does not take into account the offset of the monitor and is sensitive to CRT gun rise time (although at least they did not use the checkerboard test, which is significantly worse). The paper does mention rise time, and also notes that the test is unsuitable for "LCD" displays (it seems that TN-style displays with significant angular dependence are meant) implying that tests were conducted on CRT displays, which are almost unused nowadays. I would not, therefore, try to apply their reported results to modern flat panel displays. I also wouldn't try to build "user monitor variability" into the sRGB-to-luminance portion of APCA. |
|
Hi Chris, @svgeesus thank you by the way for this extended interchange, it has been extremely helpful
Well understood. As I mentioned, it is now my intent to abstract the linearization out to CSS 4 color module properties, i.e. srgb-linear, and the baseline. I'll create a polyfill for the library for backwards compatibility for browsers that don't support that. As a question there: is there an established best practice for export/importing a polyfill function to provide a CSS property for unsupported browsers in a way that does not also cause a future conflict in browsers where the actual property/method is supported? Questions re: normative objectivesAPCA is abstracted into two main parts: the base contrast prediction algorithm/math, and a set of design guidelines that indicate text and non-text minimums, such as font weight and size, and layout considerations, based around a set of common use cases. The Math
The Guidelines
So, for the purposes of our present discussion, as we are laying out in this thread, is the math/algorithm. The guidelines are separate, but there is a need for certain features to hopefully be added to CSS which would be helpful in defining and establishing readability guidelines, such as a property that allows the direct setting of font size by its x-height (i.e. font-x-size:) and related properties/metrics. As such, these are some of the questions that will need to be resolved eventually:
I want to mention that I did not take that objection lightly, as I do not want to throw sand into gears... I have been considering it for well over a year, as I think you may know as I had made some "less strong" mentions in the past.
GOOD.I've wanted this, and as you know this is the sole reason I became involved in this organization. My Achilles heel: understanding organizational processes and politics is not the best part of my skillset. My skillset is best suited to deep-dives finding solutions to intractable problems. While I may miss out on political subtleties, if I understand the needed parameters and limitations/exclusions, that can prevent any untoward hand-waving. I'm at your disposal to facilitate the continued development of technologies for the advancement of readability of the internet. |
|
Hi @svgeesus part deux
I agree, and it's not the sole basis of anything, I added it only as an interesting additional source, but not strictly normative nor a hill I'm going to fight for by any means. But there is corroboration in terms of measurements I've made, not to mention common default features in calibration software, etc.
Again, I agree. But there was also a hidden interesting (if only anecdotal) takeaway, that relates less to actual monitor calibration, and more to human variation of perception of high spatial frequency things like calibration targets.
Yes... and this is one of a few remote, large scale studies I am wanting to do to get an idea of perception relevant to current technologies.
Again, I'm not directly, offered more as corroboration for measurements done here (on LCDs of various types).
Yes, and again, this was more of a developmental, work in progress, structure, to align with actual results. That all stems from findings where our perception studies had results skewed from what was expected from some of the literature and existing math, or what existing might have predicted or suggested. Recall that initially in 2019, I began evaluating the existing contrast math/methods before going deeper into CAMs and so forth. The approximate timeline was:Evaluate: Weber, Michelson, Simple, and RMS contrast
Evaluate: ModWeber variants, MPCL, ∆L*, ∆Y (used in UK), and the Bowman-Sapolinski "thing" used in AU.
Evaluate: Dive deep into CAMs and other color models, like R-Lab, contrast models, readability, vision neurology, vision MRI studies, etc.etc. I.e. reviewing Fairchild, Hunt, Stone, Arend, Lovie, Legge, Barton, Brettel, Arditi, etc etc etc
I will publish more than one paper on these subjects. |
svgeesus
changed the title
|
I have been playing around with a JS APCA implementation, both as-specified in the equations and also modified versions (such as starting from CIE luminance, starting from CIE luminance then adding an exponent (2.4/2.223) shaper curve, and so on). My as-specified gets the same LC result as the APCA demo web app, to the precision that the latter reports. Although I can get close to the LC values with the modified versions, it isn't close enough and it does seem that the per-component values are needed. Which, as it stands, means that APCA is sRGB-only (I know that there are experimental additions of Display-p3 and Adobe (1998) RGB, but what about all the others?) I had hoped that any color space which defines a conversion to CIE XYZ D65 could be accommodated. It occurred to me that another way to model this is to define something like an APCA reference monitor, which is derived from However, doing it like this means that wider gamut spaces, such as display-p3 or rec2020, would generate some negative or greater than unity component values. I haven't yet investigated what the APCA equations do in the face of component values outside the 0.0 to 1.0 range. I don't know if that will give nonsensical results. I don't know if simple clipping into range, or gamut mapping into range, will give better LC predictions. |
|
Hi Chris @svgeesus The SAPC Tool
If you like, there is another tool that has more information displayed, including higher precision results, it is the SAPC research tool at https://www.myndex.com/SAPC/ Notes on the tool:To access the research tools and interactive demos, click on research mode. You can use the HTML5 color picker by clicking on any of the color patches near the input fields. The text input fields take most color strings including named colors, hex, and rgb(). Shortcuts: hex does not require a hash, and rgb() does not require the 'rgb' or the parenthesis. For greyscale, typing two hex characters as in The different research modes include a static target, a constant contrast demo and a contrast matching demo, plus the multi use-cases font cascade (experimental). "By The Power of Greyscale"
An exponent of 2.4 to 2.5 prior to applying the coefficients, helps to equalize the calculated luminances, when matching the perceived lightness of independent primaries to an achromatic grey. The research mode "static target" is helpful in exploring this. This also leads into the discussion of protan compensation for red-insensitive vision, which is a fairly narrow area that mainly presents a readability problem for the specific case of red against black. I discuss this in "What's Red and Black and Also Not Read" Also, working with other linearizing exponents was part of looking for ways to keep things as simple as possible. RGB XYZ 983
This is an important topic, and one that I've given a lot of thought to, and that is worthy of extended discussion. My general feeling is that calculating contrast should be done in destination spaces, representing physical displays. Working spaces with imaginary primaries must be converted/gamut mapped to the destination, at the very least just before display. (one way or another) therefore, any perceptual calculation such as a contrast prediction should be done after that gamut mapping, i.e. at least in a "soft proof" stage. The degree of change resulting from gamut mapping can be significant, and attempting to work on that "in reverse" to predict the gamut map, in addition to the eventual contrast, is non trivial. That said: among the design goals for APCA is that it be both extensible and adjustable for various applications/modes. Thus the abstraction for different spaces to different independent modules. I anticipate that will be the best answer for working with readability for HDR spaces. The other coinciding issue here (and how I become involved in the first place) relates to accessibility. Sticking with SDR for the moment, P3 and Adobe98 are not massively unique from sRGB in terms of any accessibility challenges. Rec2020 though certainly is. The red primary on sRGB is perceived at about 45% of the luminance of standard vision, and P3 is a bit less. But for Rec2020, I'd predict it's less than 2%-3%, i.e. essentially not there for protanopia CVD. Of LUTs and LambertsSo, in the film & television industry, specific LUTs are the common way everything is transformed, and there is no "PCS" though we do have some "defacto PCS" if you will, and working space conventions. These workflows tend to be customized for each project, and sometimes for the different divisions in a project. OpenColorIO has been helpful in this regard. I recognize the benefits of a single reference space for a PCS type of interchange. There are limitations and caveats too, as there are with all workflows. One that has been increasingly on my mind is HDR, and that deserves an entire discussion of its own. That said, it is not out of the question to develop APCA or a version that has a common input working space. It simply hasn't been thoroughly discussed with pros/cons etc. Some thoughts:
The current public facing apca-w3 reduces colors to achromatic pairs — but apca is a subset of a larger model that is intended to consider some of these things and properly handle hue/sat and some modest gamut mapping. Two that are particularly important are auto-dark-mode and auto-daltonization. Lost in Color Space
Right now, I've thought of APCA as at a point of irreducible complexity, but since it's the kind of thing that will always be in software (not a manual calculation), and also is not needed for high demand apps like live streaming, increasing complexity isn't a "huge" deal. What I mean by this is, there are reasonable solutions, and I've had versions along the way already evaluating some variations. It's more a question of determining the road map. Taking srgb-linear tuples to match the current, a pre-shaping curve with an exponent of about ^1.07 isn't terrible, with an adjustment of the soft clip. But adding/subtracting a small offset improves things and adds some side benefits (to be evaluated): And this is intended to work in the scenario of applying coefficients and summing to Y before any shaping to Ys. Which is best depends on a defined road map and considering the desirability of accommodating various user needs in future guidelines.
I'm not particularly concerned about P3. Rec2020 is a different story due to the greater accessibility implications, and the protan compensation module is probably very needed in that case. At the moment, the first stage of APCA is a clamp to 0.0 and 1.1 (the 1.1 will increase at a later date), then a soft clip near black, bringing black to about 0.0045 (for Y 0-1). Greater than unity is anticipated, though not fully evaluated. The mapping to HDR is to be discussed, my general feeling is that as far as readability is concerned, the overbrights are a negative impact, and are in the range of (pending) guidance on maximum luminance and maximum contrast. Therefore, it's reasonable that the over-range area can be compressed (for the purposes of a contrast metric) as it is a dead-zone as far as readability.
Well again, the low end already has a clamp and soft clip. The high end already has a certain amount of compression, and I've experimented with input Y values over 150. The power curves are essentially unbounded and have a natural compression factor—a compression that I've been thinking of "opening up" (reducing compression) for dark mode polarity. This is a good discussion — what I see here mainly is the need to define certain parameters, and to do so without unduly limiting future features and use cases. Thank you for reading, Andy |
Agreed that ultra-wide-gamut 2020 (and 2100) add unique accessibility challenges on top of those from sRGB, and moderately-wide-gamut display-p3, a98-rgb and so on. Because the display primaries are right on the spectral locus, the color sensations they produce are very sensitive to small amounts of observer metamerism (people who differ in small but measurable ways from the CIE standard 2 degree observer). Of course, the original CIE color matching experiments also suffered from that, for the same reason :)
Right. I do think we do need to distinguish display primaries from primaries used to define a color space.
(Somewhat) greater than unity is also a side effect of WCG, unrelated to HDR. As an example,
I think that a simple dark-or-light surround, making it three-way with background being assumed to be the proximal field, gets us a long way without adding much complexity to either calculations or to the mental model. |
|
Hi Chris @svgeesus
For accessibility the one I am most concerned about is the red primary and protanopia:
Particularly blue, which makes sense considering the 2° observer is mainly foveal which has no S cones.... and this leads to "well, S cone response is not part of readability" which might favor derating blue, but then "blue light is a known issue with disability glare" so just derating isn't a right approach either. The protan compensation relating to the red primary is comparatively simple vs "blue as a problem color". And... ...17 young British white males define modern colorimetry... which when you add in:
The spectral plots of sRGB primaries are anything but monotonic. But when we calculate luminance, we are using a singular xy point, despite the primaries actually being more of a lumpy smudge on the chromaticity diagram. Looking at this plot of sRGB primaries of an LCD, it indicates one of the reasons I'm using the term "estimated screen luminance" and why I've also been looking at better ways consider actual monitor characteristics. Leaping into this rabbit hole happened when early contrast matching experiments showed some "unexpected skew" relating to the red and blue primaries versus green or achromatic calculated luminance.
Remembering 15 years ago seeing on the DI stage the effect of an unclamped negative wraparound through an ICC profile LUT into a 10bit per channel integer container, where the black level was set at 95. Kinda like a Jackson Pollack. DPX is only recently giving way to EXR, at least amongst my clients, so I'm familiar with these issues. ACEScg with all positive primaries was created because the initial one with the negative blue imaginary primary made it less than useful for visual effects work... But here in terms of readability, which is the focus of APCA, we are mainly concerned with the green primary, especially for Rec2020. Blue is not useful to readability, and red is marginal in that regard as well. Yet red and blue can't be completely disregarded either, as they both have characteristics that are blockers, interfering with readability in certain situations. My point here is that, pending trials, clamping negative blue and red to 0 is mostly likely fine — we're not trying to process or predict imagery, only contrast for readability, which is a narrower subset of contrast metrics.
Okay, and this makes sense for guidelines too: a key point is the need to determine the adjacent background of a button that has text on it, so this is a needed three-way example — in working on this, I'd say the larger field is probably defined as being adjacent to low spatial frequency stimuli, i.e. the button shape & button background, and the button's background is the one adjacent to the high spatial frequency text element. The distinction is important because of the increasingly complex interactions. So then the three basic inputs are:
Notes on this:
Thank you for reading |
|
Related to observer variability, the paper: Individual Colorimetric Observers for Personalized Color Imaging Indicates that for normal vision, the need for 10 categorical observers, instead of a single averaged observer. And the significantly higher variability when viewing laser displays seemed to indicate more. SPDs of different makes/models of displays:
And so, again, I am thinking in terms of better models of actual displays here in 2022, which again is raising the question of departing from CIE 1931 XYZ just as far as a different weighting that emphasizes M/L cone peak sensitivities for a "most universal" luminance contrast method. TangentSome of this leads to questions, such as, is extending the tristimulus primaries to the locus the best way to improve color fidelity? The alternative being a four primary color model, e.g. RGBE... or the proposed 6 primary "flexible gamut" The deeper I look into this, the more it seems that instead of improving fidelity with very narrow band primaries, particularly green, on the spectral locus, which carries a lot of issues for realizability — using at least four "not mono"(wider)-band primaries might provide a more realizable display that also is better for accessibility. Of course there is no standard that I'm aware of, much less any content—but Sharp has played with the idea with a RGBY display. And not that this is relevant to the immediate case, and all conjecture aimed far into the future...but as I'm thinking about user needs and accessibility, a 4 or 6 color model using wider bandwidth primaries (than 2020) appears to offer a number of advantages over Rec2020/2100. The lack of standardization, content, etc is the biggest issue, but something that if a company like Apple got behind it, could make it a reality, possibly even sooner than an elusive 100% rec2020 display with no spreckles. |
|
Earlier I wrote:
My implementation of APCA in color.js proceeds as follows:
This means it accepts input in any color space supported by color.js. It has now been tested with:
The result from the third set of tests is I can fix that of course, by storing the sign, taking the power of the absolute value, then restoring the sign (as is done in the CSS Color 4 sample code. function linearize (val) {
let sign = val < 0? -1 : 1;
let abs = Math.abs(val);
return sign * Math.pow(abs, 2.4);
}Figured that it was worth pointing out that currently, APCA is only defined over the in-gamut range 0..1 not the extended range. |
Hi Chris @svgeesus yes, this is something on my list of things to investigate... But since the idea is to emulate physical displays, I'm not sure that "converting without mapping" is ideal, and why I've felt that having a specific input module for each color space is preferred. BUT WCAG 3 is still up in the air to the degree that anything is possible. I have mentioned in the past that as far as accessibility guidelines are concerned, sRGB is a reasonable baseline standard, to limit the complexity of normative guidance. Particularly as the red primary is still partially perceivable by protanopia. And a further issue is an APCA "clear simple guideline set" for WCAG 3, and then a more complete APCA as a separate (non normative) design system guideline (that overlays the "base" minimums). All of these issues underline the complexity, and I am trying to find ways to simplify reasonably... Your thoughts here |
|
Just my own thoughts/prejudices/preconceptions here. I have read this thread, but I won't pretend to have followed most of the nuance. OTOH, I believe I have an average/typical understanding of the underlying mathematics.
Yes please.
So, then are all the other Early on I recognized the similarity between the 2.x formula for relative luminance and I submit that it is problematic for APCA/BPCA to use |
|
Hi @bruce-usab
So, for the next planned version, I have been looking at recalculating the sRGB primaries using Judd/Vos. And at the same time, introducing the protanopia compensation. I have delayed all of this as I also want to do a larger clinical study for evaluation, with the intention that the next iteration is also the release candidate. I am seeking funding for the study I want to do, a process that continues at the moment.
One reason I am looking at Judd/Vos is that it is known that 1931 CIE is incorrect. Now, for the purpose of many things in colorimetry, the errors in 1931 are considered more acceptable than the problems resulting from revising the standard. But the story is a little different when predicting the appearance of real-world self-illuminated monitors, where the differences are noticeable. The "conventional" luminance calculations are ALL derived from the 1931 CIE 2° standard observer. And again for things like image processing and industrial applications, this has been fine. One of the reasons I am not considering conventional luminance calculation as fine for accessible contrast relates to how hue can interfere with readability. Side Note: I.e. while we know lightness perception is not linear as to light, and we model this with L* (or other, such as J* etc), neither is the relationship of primaries and the sum of the primaries, at least as per HK, though is still handled as linear math (Grassmann's laws). Adding to this complexity is that we know we process hue and saturation separately from the achromatic luminance, and we have significant research that states that functionally the value of luminance contrast is not additive to the value of color (hue/chroma) contrast. But this then does not explain the Helmholtz-Kohlrausch effect, and neither does anything derived from 1931 CIE (LAB/LUV) despite 1931 CIE being entirely based on matching to mono spectral colors (which by definition are of maximum saturation). NEVERTHELESS, I have experiments that show that modifying the linearization ("gamma removal") that HK effects are reduced, but I am a long way from committing to any statement of universality of any hidden perception gamma outside of that which models lightness of achromatic luminance. </ Things That Keep Me Awake At Night > And not to make the waters any murkier but CIE has research going on right now regarding the YGB model of vision in the effort toward a cone-space colorimetry. Here the Y means yellow. (...Kansas is a distant memory for Dorothy)...
So the +0.055 and 1.055 factor is an offset that squashes the power-curve, done to allow the addition of a linear section near zero — the overall effect is a "gamma" of 2.2, which for a dim CRT of the day, it might be adjusted for (lower contrast) as would be needed in a brighter office environment. It is useful to note that that for an overall brighter display, a higher gamma is needed for the same perception intent in the same environment. Today's very high brightness displays are frequently adjusted for an effective gamma of more than 2.4. Here are the implications for contrast: Calculating using a low gamma, then mid tones vs black will calculate as higher contrast than reality, and this is a specific area that WCAG 2 contrast is incorrect (false passes). Also, when calculating using a low gamma, contrasts between mid tones and white calculate as lower contrast than reality (false fails for WCAG 2). However, it is not enough to simply adjust the input gamma to align with modern devices, and in fact APCA does only this very tiny adjustment. There are still other factors in play, such as flare, which APCA addresses in part using the input soft clamp near black, similar to how DICOM handles flare. All of that is the pre-processing before actually estimating the perceptual lightness and the difference calc, which takes the adjustments the rest of the way, and have the addition of high spatial frequency stimuli in the contrast matching experiements. |
Similar, yes. Identical, no. Also it isn't possible to put a shaping curve on Y to get to Ys (I tried).
The R G and B weighting factors are identical to four decimals, yes (the difference being very slightly different white chromaticity values). The transfer function (exponent, for a simple power function) no-where near identical, as I showed in the first post of this thread.
Compensating for viewing flare is not a "rounding hack". Power law with offset gives quite different results to no offset. |
Yes, quite right. I am just confessing my naïve assumptions. I am pleased to have been informed by the recent threads on flare and ambient light. WCAG 2.0 did not invent the equation it uses for relative luminance: I can appreciate that it is not perfect, but does not this equation still have industry consensus as an acceptable metric for luminance? |
WCAG did not invent the conversion from gamma-encoded to linear-light, and the weighting levels for G and B to calculate luminance. Those are indeed taken from the sRGB standard. The luminance contrast formula used in WCAG 2.x does not come from the sRGB standard.
The equation for calculating luminance is correct (modulo referencing an older draft of the sRGB standard rather than the final one, which does not affect the calculation unless 10 or more bits are used). The equation for calculating luminance contrast is not very good, and it is not clear where it comes from. |
|
Hi @bruce-usab
It is the standard for sRGB to XYZ, and in XYZ, Y is relative luminance. This is derived from the CIE 1931 2° standard observer. Now, the 1931 2° standard observer is the basis for modern colorimetry. And while it is also known to have certain deficiencies, it is "close enough" to be useful, as it is (in a sense) more important to have a "particular standard" as a touchstone for converting between color spaces. In this realm, it is important to have a consistent method that is invertible so that "round trips" have no loss. However, while XYZ is a useful intermediate color space, it should not be assumed to emulate or model any real-world device, and this includes the luminance Y value. In other words, Y in this case is a "theoretical" and not "real" value. However, the difference of a theoretical Y vs a reality-based Ys in terms of a predicted contrast value becomes important if we want to align more closely with things such as modern displays and devices. Some of the initial studies in 2019 were frustrating as the mathematical predictions did not match empirical measurements. This led to a lot os experiments and measuring actual device characteristics. Modern displays and devices are two to three times higher in peak luminance than that described in the IEC standard. And increasing a display peak relative to a given ambient, the actual gamma of the device will typically be increased for the same perceptual intent. This is because a lower display gamma reduces contrast and increases the lightness of dark areas, but if the total peak brightness is higher, then a higher gamma is needed to maintain the same perceptual black levels. Secondarily, there is assumed "gamma gain" in imagery from camera to display for a given perceptual intent (Poynton) and the TRC for use with the derived XYZ matrix does not account for this as far as I've seen in any discussion on the topic. The APCA's use of a higher gamma prior to applying the coefficients is a much better fit to measured perception data from the contrast matching experiments. Nevertheless, I am working on aligning the TRC linearization to be that of standard CSS 4/5, for a common point of entry. But there still exists the needs to keep the RGB values separate and to use different coefficients, in part as I think it is important to better model protanopia. The current APCA is a vast improvement for protanopia over WCAG 2, but in light of emerging technologies, a more complete solution is needed (and was developed back in 2019, but not yet set in place for reasons relating to organizational politics). The way that a change in gamma or TRC affects contrast calculations is that the mid range values are directly altered. An assumed higher display gamma then translates to mid-value colors against black have a reduced contrast value as reported. And conversely mid value colors vs white have an increased contrast value as reported. Note: this is only one of several "layers" of how APCA does the contrast calculation, and the small gamma change here is not enough to "fix" WCAG 2 if it were so applied—the problem with WCAG 2 is that is is calculating the ratio of luminance without consideration for perceptual lightness. The reason that Weber (i.e. what WCAG 2 is essentially) is 180n year old idea that a log curve defines perception of the just noticeable difference; that is the threshold level of contrast sensitivity. But in the 1960s, Stevens showed otherwise (power curves and spatial frequency sensitivity). More recently, Poynton pointed out that the curve is more of a hybrid log/power-curve. In the SAPC experiments we determined that the supra-threshold, well above the JND, presents a further shape-instructive shift in the contrast center point. WCAG 2 states the "middle" contrast as about #767676, which is about at the "traditional 18% level" which is low spatial frequency color patches... but this is not the center contrast for high spatial frequency elements such as text. Depending on polarity, total contrast, proximal field, etc etc, the text center contrast is between about #999 and #b0b0b0. Which takes us back around to: contrast is not real, it is a context sensitive perception. Luminance, by itself, can not define contrastThe proof of this is trivial to demonstrate. In the following image, the two yellow dots are the EXACT same light coming out of your display, and grey of the two squares they are on are also equal to each other. But due to the context, one yellow dot appears "bright" and the other appears more brown. The two yellow dots have a contrast difference, but the luminance difference is exactly zero.
|
Hi @svgeesus I discuss the origins in this thread. The short answer is it's an "inverted Weber" with a bonus 0.05 added and no empirical testing, just a hand-waved a priori with tenuous claims of support from some cherry-picked obsolete standards. And importantly, conflating the ideas of visual acuity and contrast sensitivity, which should remain fairly separated. |
|
In recent years, I have developed some concern that the 1.4.3 Understanding document is something of a retcon when it comes to the thresholds and some of the maths.
Hence the interest for something better. But I have to point out that WCAG 1.0 and 508 circa year 2000 had almost nothing. SC 1.4.3 has had as much a positive impact as any of the other SC, IMHO.
It is just a variation on ( X / Y ) to compare two number of similar size. Since Y can be 0, and the maximum is 1, the numbers chosen shift the range from 0-20 to 1-21. I really do not think there is anything more to it than that. But okay, 0.05 is a nominal value for flare. |
Cool!
Now in errata for 2.1 and 2.2 Editor's Draft.
It is a relative difference formula capped at 20. Why 20? Why not? 10 is too flat. 100 is too much when half the range is irrelevant. Oh, then add +1 so the result can easily be express plain language as ration in the form of X:1. Following is not exactly the algorithm, but it is close to the idea: With X, Y both between 0.0 and 1.0, and X the larger:
|
|
Background
Luminance is a physical measure of the brightness of a light as seen by a standard human observer, taking into account the varying wavelength sensitivities of the human eye. It is defined by the CIE [1] and commonly represented by the symbol Y. It may either be absolute (in units of candelas per square metre) or relative, in which case the luminance of diffuse or media white is scaled to be 100%. Luminance is additive and suitable for calculations of physical quantities such as light mixing; it is not perceptually uniform (a relative luminance of 50% does not appear midway between black and white).
Lightness is an estimate of how light something is, independent of colorfulness or hue. The CIE define a measure of lightness, L* [2]. There are other measures, such as OKLab Lightness [3]. A lightness of 50%, for any color, should appear exactly midway between black and white, and the remainder of the range should appear evenly spaced visually.
sRGB values to luminance
The sRGB standard defines a transfer function to convert "gamma encoded" sRGB values to linear-light quantities (which may then be further converted, for example to CIE XYZ). Like many transfer functions derived from the broadcast TV world, the sRGB transfer function consists of a small linear portion near black, followed by a curved portion (scaled and offset power function) for most of the range [4].
WCAG 2.1 correctly [5] describes how to convert sRGB values to linear-light, and then how to calculate luminance.
APCA [6] incorrectly approximates the sRGB transfer function with a simple power law. It is possible to do this with a small (though still avoidable) error of around 0.5%; the best-fit power function has an exponent of 2.223. However APCA appears to simply copy the exponent of 2.4 [6] from the full sRGB equation, without taking into account the effects of offset and scaling. This introduces a significant error of up to 2.5% in the mid-tones [7].
If this error is inadvertent, it should be corrected by using the correct sRGB transfer function so that the luminance is correctly calculated.
If it is intentional, as a mid-tone shaping curve, then this shaping step should be separately specified from the conversion to CIE Luminance, so that APCA can be used with other color models such as Display P3 [8]. All published color models include a method to convert to and from CIE Luminance.
The modified quantity should not be called Luminance, but should be given some other name to avoid confusion.
References
cc/ @Myndex
The text was updated successfully, but these errors were encountered: