APCA Luminance calculation non-standard, up to 2.5% deviation

[svgeesus]

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

C'=12.92 C	C ≤ 0.0031308
C'=1.055 C1/2.4-0.055	C > 0.0031308

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

1. Colorimetry, Fourth Edition. CIE 015:2018. CIE. 2018. URL: http://www.cie.co.at/publications/colorimetry-4th-edition
2. ISO/CIE 11664-4:2019(E): Colorimetry — Part 4: CIE 1976 Lab* colour space. 2019. Published. URL: http://cie.co.at/publications/colorimetry-part-4-cie-1976-lab-colour-space-1
3. Björn Ottosson. A perceptual color space for image processing. December 2020. URL: https://bottosson.github.io/posts/oklab/
4. Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB. URL: https://webstore.iec.ch/publication/6169
5. Almost correctly. WCAG 2.1 has a very small error due to referencing an early working draft of sRGB rather than the finished standard. The error is less than 0.01% and is corrected in WCAG 2.2
6. APCA™ for W3C & WCAG_3
7. sRGB (and display-p3) approximation errors
8. Apple Computer and ICC, Display P3

cc/ @myndex

[Myndex]

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 color(srgb-linear ...) and my remark was going to be "I should probably align APCA to use the new CSS 4 srgb-linear to ease standardization"

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

APCA incorrectly approximates the sRGB transfer function with a simple power law.

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 tape

But 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 #000000. If a screen color is black, it's not black. And not only flare, rod intrusion for values under 8 cd/m² has a measurable effect on perceived contrast of dark colors.

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.

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"

However APCA appears to simply copy the exponent of 2.4 from the full sRGB equation,

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]

If this error is inadvertent, it should be ....

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

If it is intentional, as a mid-tone shaping curve,

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.

then this shaping step should be separately specified from the conversion to CIE Luminance,

As mentioned, yes, can do. But as also mentioned, there are benefits for some adjustments prior to, or while applying the coefficients.

so that APCA can be used with other color models such as Display P3 All published color models include a method to convert to and from CIE Luminance.

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.

The modified quantity should not be called Luminance, but should be given some other name to avoid confusion.

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.

Closing

I 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 Perceptibility and Acceptability of Gamma Differences of Displayed sRGB Images S&T's 2003 PICS Conference Imaging Technology Research Group, University of Westminster Harrow, Middlesex, United Kingdom

[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 Individual Colorimetric Observers for Personalized Color Imaging Advisor: Mark D. Fairchild Committee Chair: George Thurston Committee Members: Roy S. Berns and Laurent Blondé

5 MIN HUANG YONGHUI XI 1, JIE PAN1, RUILI HE1,2, AND XIU LI1 Colorimetric Observer Categories for Young and Aged Using Paired-Comparison Experiments

6 ITU-R BT.709-6 (06/2015) Parameter values for the HDTV standards

[Myndex]

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.

[svgeesus]

then this shaping step should be separately specified from the conversion to CIE Luminance,

As mentioned, yes, can do.

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

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

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 offset indicated in that svg is inflated 400% vertically, relative to the horizontal scale.

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 color-contrast() function solely referencing the WCAG 2.1 algorithm resulted in that function being deferred to level 6 and will result in its being removed from Interop 2022. The plan is to work on it more so that it helps move the Web forward, rather than (and I agree with your assessment in your formal objection) harming the Web.

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.

[svgeesus]

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

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.

[Myndex]

Hi Chris, @svgeesus thank you by the way for this extended interchange, it has been extremely helpful

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

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 objectives

APCA 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

• Developed from and supported by the existing CAM and other vision models and vision science.
  • Is a simplified appearance model specifically intended for self-illuminated displays.
  • as accuracy for readability is a primary goal, it features:
    • achromatic luminance contrast is the main tested perceptual property.
    • perception curves are based on highest spatial frequency stimuli for a given contrast value.
    • polarity sensitive, including middle contrast shift
  • weighted toward the lowest-denominator for common use cases:
    • standard resolution (and standard antialiasing)
    • standard dynamic range
    • light/bright total page luminances
    • bright interior environments
    • unknown display calibrations (assumes clipped blacks, flare)
  • Is extensible and adjustable. Some of the (as yet unreleased) modules:
    • Protan accommodation (requires access to all three RGB tuples)
    • Glare prediction (requires access to all three RGB tuples)
    • 3 way, 4 way (and more) colors/conditions

The Guidelines

• Readable text based largely on the work of Whittaker, Bailey, Lovie-Kitchin and also G.Legge, et alia

  • Applies the concepts of critical size and critical contrast
  • Is intentionally abstracted from the algorithm to allow modular conformance models for other languages, use-cases, and target accommodation goals. For latin:
    • font size based on x-height (currently extrapolated to font body size, as that is what is available in CSS)
    • font weight based on reference font (another technology deficit due to non-standardization of weight)
    • minimum layout metrics such as line-height based on x-height
    • broad use-cases are content text, non-content text, and non text
      • granularly, content text is body text, fluent text and sub-fluent text
      • non-content text is spot-readable text and ancillary text
      • non text is:
        • intrinsically semantic (icons, pictograms)
        • abstractly semantic (dataviz, chart lines, pie pieces, map areas, focus)
        • functional/interactive (buttons, checkboxes, selectors, form fields)
        • non-semantic (dividers, container boxes, things needing basic distinction that are not information per se)

• All of the above guidelines must reference a minimum visual acuity (VA) and contrast sensitivity (CS) that is to be accommodated, and the degree of accommodation.

  • I can present what is needed to accommodate any given level of user need, but it is a matter of politics as to what level of user need is to be accommodated.

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:

1. I would like to bring up for discussion the future as it relates to a "permanent default color space" to always be supported by content, regardless of any other color spaces added or supported.

   • For some impairments, SDR and sRGB may be ideal due to the limited contrast range and the smaller color primary distances.
   • This then leads to thoughts of how to map SDR/sRGB content into HDR/WDC in a manner that preserves accessibility.
   • This is non-trivial and I'm not even going to attempt to distill this can of worms right now.

2. I generally feel that only physical display color spaces are useful here. I don't see practical value is using a color space with imaginary primaries, and not associated with any specific display space as a useful one for readability contrast assessment.

   • The physical display characteristics are needed to predict contrast in a meaningful way.

3. Some of the extended features, if they come into use (such as the protan module) require all three RGB tuples, not just the summed luminance. My feeling is that the eventual entry point into the algorithm will be sets of linearized RGB values.

   • Will these be always defined as linear sRGB, or will they carry an identifier of the originating color space?
   • For "always linear sRGB" pros/cons
     • NEUTRAL/PRO: continues to define the default, base color space as sRGB, regardless of technology
     • PRO: single baseline conformance for accessibility guidelines (and law) based on the default color space, creating a simpler conformance target for testing and evaluation.
     • CON: may then fail to accommodate accessibility needs that result from emerging technologies.
     • CON: extending accessibility guidelines to other color spaces by reverse gamut mapping gives me night terrors.
   • For "linear version of every color space" pros/cons
     • NEUTRAL/CON: for every color space, the linear RGB values will need to be accompanied by identification of the color space not only for the primary coordinates and WP, but also for the display TRC
     • PRO: flows naturally as technology advances
     • PRO: provides best assessment of any given display space for accessibility purposes. For instance, recognizes the additional needs created with Rec2020/2100, or HDR, etc.
     • CON: substantial work to evaluate and conform an input module for each color space. Even if they are all linear, there are still accessibility issues arising from the position of primaries and the originating transfer curve, etc.
     • CON: could complicate the accessibility conformance or testing process.
     • CON: may lead to greater misunderstandings or confusion due to many different spaces. Consider that even today people are using NTSC coefficients with sRGB (!!)

---

As more of a higher-level comment - as you know, your formal objection on the CSS Color 5 color-contrast() function solely referencing the WCAG 2.1 algorithm resulted in that function being deferred to level 6 and will result in its being removed from Interop 2022. The plan is to work on it more so that it helps move the Web forward, rather than (and I agree with your assessment in your formal objection) harming the Web.

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.

---

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

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.

[Myndex]

Hi @svgeesus part deux

Having now read that paper, the experimental design leaves a lot to be desired.

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.

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

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.

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.

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.

I would not, therefore, try to apply their reported results to modern flat panel displays.

Again, I'm not directly, offered more as corroboration for measurements done here (on LCDs of various types).

I also wouldn't try to build "user monitor variability" into the sRGB-to-luminance portion of APCA.

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

• Results: meh, no improvement.

Evaluate: ModWeber variants, MPCL, ∆L*, ∆Y (used in UK), and the Bowman-Sapolinski "thing" used in AU.

• Results: varied from meh to SMH, and clearly there were some important considerations missing.

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

• Results: SAPC which later evolved into APCA (and obviously I'm leaving out a lot of detail)

I will publish more than one paper on these subjects.

[svgeesus]

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 L_C result as the APCA demo web app, to the precision that the latter reports.

Although I can get close to the L_C 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 srgb-linear and then has the simple power law 2.4 TRC. (It then also doesn't matter if the matrix coefficients are slightly different to the sRGB standard).

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

[Myndex]

Hi Chris @svgeesus

The SAPC Tool

My as-specified gets the same LC result as the APCA demo web app, to the precision that the latter reports.

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 79 or f3 expands to a grey as in #797979 or #f3f3f3. typing 1 to 3 digits, followed by a comma makes a gray from the integer rgb, so 123, becomes rgb(123,123,123)

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"

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

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

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.

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 Lamberts

So, 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:

1. sRGB as a lowest common denominator default space for accessibility guidelines?

2. Will we actually be adding in the protan compensation and glare compensation modules?

3. Are we going to move to a three-way and four-way (color inputs) model? Or stay with a simple pair?

4. For automated color selection, including automated dark mode variants and Daltonizations, all three RGB tuples are needed - linear is fine, though knowledge of the destination space (at least) is needed... 5.

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

It occurred to me that another way to model this is to define something like an APCA reference monitor, which is derived from srgb-linear and then has the simple power law 2.4 TRC. (It then also doesn't matter if the matrix coefficients are slightly different to the sRGB standard).

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):

  Ys = (Y + 0.02)^1.08 - 0.017    ( then also adjusting the soft clip)

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.

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

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.

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

[svgeesus]

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.

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 :)

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.

Right. I do think we do need to distinguish display primaries from primaries used to define a color space.

Greater than unity is anticipated, though not fully evaluated. The mapping to HDR is to be discussed

(Somewhat) greater than unity is also a side effect of WCG, unrelated to HDR. As an example, color(rec2020 0 1 0) gives -0.5878, 1.133, -0.101 in srgb-linear or -0.790, 1.056, -0.350 in (extended) sRGB.

Are we going to move to a three-way and four-way (color inputs) model? Or stay with a simple pair?

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.

[Myndex]

Hi Chris @svgeesus

...Because the display primaries are right on the spectral locus...

For accessibility the one I am most concerned about is the red primary and protanopia:

...very sensitive to small amounts of observer metamerism....... Of course, the original CIE color matching experiments also suffered from that, for the same reason :)

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:

..._I do think we do need to distinguish display primaries from primaries used to define a color space._

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.

_(Somewhat) greater than unity is also a side effect of WCG, unrelated to HDR. As an example, color(rec2020 0 1 0) gives -0.5878, 1.133, -0.101 in srgb-linear or -0.790, 1.056, -0.350 in (extended) sRGB._

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.

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.

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:

• Text/icon color.
• background color adjacent to the text, which itself may be a button or container.
• larger field background color, only adjacent to smaller backgrounds and non-semantic non-text.

Notes on this: 1) Regarding polarity, we assume each input's polarity relative to the others is semi-independent but restrained within the context.

• It's possible for the text to be of negative polarity (dark mode) to the adjacent background, but positive polarity relative to the larger field, but in this case the adjacent background would have to be positive polarity to the larger field as well.

2) With the data we have so far, positive polarity (dark text on a light BG) is the most sensitive to changes in the larger field.

• Light mode has an apparent contrast increase with very dark surrounds
• At high contrasts, dark mode is minimally affected by the larger field.
• Therefore the current simple pairwise APCA assumes a "light grey" background, around #aaaaaa ish, as an ideal point where dark mode/light mode are closest, and around where the "worst case" for needed contrast arises.

3) The way things are moving per WCAG 3, I don't think now is the right time to introduce this for those guidelines, but this is the kind of thing that would be good in a general guideline as I proposed at the WICG incubator.

Thank you for reading

[Myndex]

Related to observer variability, the paper:

Individual Colorimetric Observers for Personalized Color Imaging Yuta Asano August 2, 2015 http://www.rit-mcsl.org/StudentResearch/YutaAsano/YutaAsano_Dissertation.pdf

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.

---

Tangent

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

[svgeesus]

Earlier I wrote:

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.

My implementation of APCA in color.js proceeds as follows:

1. the text and bg colors are converted to sRGB, without any gamut mapping
2. the Y_s is calculated, with the 2.4 exponent and the r,g,b weighting factors from apca-w3

This means it accepts input in any color space supported by color.js. It has now been tested with:

• the eight color pairs (sRGB hex) from the test on apca-w3. Result: all pass to 10 significant figures
• the eight color pairs (converted to other color spaces from CSS color 4) from the test on apca-w3. Result: all pass to 10 significant figures
• a few out of sRGB gamut colors, like display-p3 secondary yellow against white and black

The result from the third set of tests is NaN because of course a simple power function is only defined for non-negative inputs.

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.

[Myndex]

the text and bg colors are converted to sRGB, without any gamut mapping the Ys is calculated, with the 2.4 exponent and the r,g,b weighting factors from apca-w3 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

[bruce-usab]

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.

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.

Yes please.

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.

So, then are all the other Y_txt/bg/c references are to your Ys or to the conventional accepted luminance calculation?

Early on I recognized the similarity between the 2.x formula for relative luminance and Y as used by SAPC. (All numbers and exponents identical to four decimal points, except for that pesky +0.055 which I dismissed as a similar rounding hack like the +0.05 in 2.x for contrast ratio.) Starting from that point of similarity, I worked my way through the SAPC algorithm to make myself comfortable with what was going on mathematically.

I submit that it is problematic for APCA/BPCA to use Y which is so close to 2.x relative luminance — but not really? Is it possible to express the APCA/BPCA equations to not have this ambiguity about Y?

[Myndex]

Hi @bruce-usab

I submit that it is problematic for APCA/BPCA to use Y which is so close to 2.x relative luminance — but not really? Is it possible to express the APCA/BPCA equations to not have this ambiguity about Y?

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.

So, then are all the other Ytxt/bg/c references are to your Ys or to the conventional accepted luminance calculation?

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:
Wanna know what breaks my brain? The Helmholtz-Kohlrausch effect indicates that highly saturated colors appear brighter than the equivalent calculated luminance of achromatic grey... But, all of colorimetry is based on color matching tristimulus primaries to maximum saturation, monochromatic spectral lights. The implication here then is that summation of the photometric totals of the primaries is not linear, though we treat this as if it was linear.

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

....except for that pesky +0.055 which I dismissed as a similar rounding hack like the +0.05 in 2.x for [contrast ratio].)

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.

[svgeesus]

Early on I recognized the similarity between the 2.x formula for relative luminance and Y as used by SAPC.

Similar, yes. Identical, no. Also it isn't possible to put a shaping curve on Y to get to Y_s (I tried).

(All numbers and exponents identical to four decimal points

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.

except for that pesky +0.055 which I dismissed as a similar rounding hack like the +0.05 in 2.x for contrast ratio.)

Compensating for viewing flare is not a "rounding hack". Power law with offset gives quite different results to no offset.

[bruce-usab]

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: Formula taken from sRGB and IEC-4WD.

I can appreciate that it is not perfect, but does not this equation still have industry consensus as an acceptable metric for luminance?

[svgeesus]

WCAG 2.0 did not invent the equation it uses for relative luminance: "Formula taken from sRGB and IEC-4WD."

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.

I can appreciate that it is not perfect, but does not this equation still have industry consensus as an acceptable metric for luminance?

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.

[Myndex]

Hi @bruce-usab

I can appreciate that it is not perfect, but does not this equation still have industry consensus as an acceptable metric for luminance?

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 contrast

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

[Myndex]

The equation for calculating luminance contrast is not very good, and it is not clear where it comes from.

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.

[bruce-usab]

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.

The equation for calculating luminance contrast is not very good...

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.

...and it is not clear where it comes from.

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.

[bruce-usab]

The equation for calculating luminance is correct...

Cool!

...modulo referencing an older draft of the sRGB standard rather than the final one

Now in errata for 2.1 and 2.2 Editor's Draft.

The equation for calculating luminance contrast is not very good, and it is not clear where it comes from.

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: if X-Y < 0.05 return 0 if (X/Y) > 20 then return 20 else return (X/Y)

1. If X and Y have the same luminance (or very close to the same luminance), then there is no contrast, and relative difference formula should return minimum, either 0 or 1.
2. The relative difference formula should have a cap, since white (1.0) versus black (0.0) is set at the maximum contrast, and algorithm needs to catch something like [(0.999)/(0.001)], returning 20 or 21.
3. Since our X and Y are between 0 and 1, and rule (1) working with rule (2) can catch division by zero, our relative difference formula is just (X/Y) or [(X/Y)+1].

[Tamarahill]

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

C'=12.92 C	C ≤ 0.0031308
C'=1.055 C1/2.4-0.055	C > 0.0031308

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

1. Colorimetry, Fourth Edition. CIE 015:2018. CIE. 2018. URL: http://www.cie.co.at/publications/colorimetry-4th-edition

2. ISO/CIE 11664-4:2019(E): Colorimetry — Part 4: CIE 1976 Lab* colour space. 2019. Published. URL: http://cie.co.at/publications/colorimetry-part-4-cie-1976-lab-colour-space-1

3. Björn Ottosson. A perceptual color space for image processing. December 2020. URL: https://bottosson.github.io/posts/oklab/

4. Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB. URL: https://webstore.iec.ch/publication/6169

5. Almost correctly. WCAG 2.1 has a very small error due to referencing an early working draft of sRGB rather than the finished standard. The error is less than 0.01% and is corrected in WCAG 2.2

6. APCA™ for W3C & WCAG_3

7. sRGB (and display-p3) approximation errors

8. Apple Computer and ICC, Display P3

cc/ @myndex