Re: [csswg-drafts] [css-color-6] color-contrast() should allow specifying multiple contrast algorithms that need to be satisfied (#7357)

And just to be clear:

I am going to change the input section so that the _linearization_ transform used matches "standard" as defined in CSS 4/5. However, the lightness predictions will still not be a "standard CIE 1931 Y" as discussed below.

## Detail
Each color input to APCA will be the separate, normalized,, linear R,G, and B values, and a flag indicating the colorspace.

A key reason for this is the need for compensation for protan (red insensitive vision) and also possibly for the (potential, but still under review) halation/glare-compensation, as these features work by adjusting/offsetting the RGB to Y coefficients in a minimally invasive way. And also for certain automated color-contrast functions, which need to identify hue and chroma.


### Additional Considerations:  Reverse APCA & Auto Dark Mode

The fact there was no perceptually uniform contrast metric prior to APCA is simply that it was less important, when a designer was ultimately making color choices. BUT:

The overwhelming reason that perceptually uniform contrast is needed today is the need for AUTOMATED color and contrast adjustments. It is not possible to make "good" color or contrast adjustments without the eye of a designer, unless there is a perceptually uniform model with which to do so.

- The current reverseAPCA() function returns an achromatic grey adjacent color, when given a color and a target contrast value.     
    - But clearly there is a desire for a return color including hue and chroma that fits into a color scheme, such as with a color-contrast() type function. 
    - To facilitate an inverseAPCA() function that returns an adjacent color that is both at a target Lc value and also has a suitable hue/chroma requires the separate RGB values.
- Similarly for auto-dark-mode, flipping colors for dark mode is often best accomplished by maintaining the same hue, and inverting only the luminance around a contrast center for the polarities, and then adjusting chroma as needed for a contrast Lc value match. Here again, all three RGB values are needed. 

In both cases, these can be linearized RGB values, and in all cases the color-space must be known.

### Additional Considerations: CIE 1931

I have been looking at Judd/Vos as a potentially more appropriate path to emulating display response Y (something Sony has been working with as a means to correct metameric issues with narrow  band primaries).

However, recent research in relation to CIE Technical Committee 1-98 entitled _"A Roadmap Toward Basing CIE Colorimetry on Cone Fundamentals."_  indicates a potential shift is colorimetry, and likely important implications for display technology. 

For more background on this, see [_R.W.Pridmore. "**A new transformation of cone responses to opponent color responses**"_](https://link.springer.com/article/10.3758/s13414-020-02216-7)

So, I've been slow to make changes till I have a chance to review some of this further.


### RE: Lost in Color Spaces

At present, APCA is being demonstrated with SDR sRGB as this is the web default. The future of multi-colorspace web content system anticipates the above issues will only increase in importance. 

**Some questions we need to be asking are:**
- Is it valid to assess or predict contrast using imaginary spaces like ProPhoto or ACES at all?
- Is it possible or useful to predict contrast in any non-display space before it is gamut mapped to the display?
- Does contrast need to be measured for every display color space?
    - This also raises questions regarding automated functions, and automated space conversions.

**These questions lead to the following key question:**
- Should _normative_ guidelines such as WCAG 3 and minimum conformance specs be based only an APCA that is using a simpler sRGB screen luminance (as it is now), while the more complete models discussed in this post be available for practical use?


### RE: Alpha Blended Colors

All alpha blending or compositing must be done prior to sending to the APCA inputs, as in most cases the alpha blend is happening in a gamma encoded space.


## The TL;DR
**To summarize:** there are at least four contrast related factors that involve the independent RGB channels, and/or coefficients used to transform RGB into a photometric luminous intensity, as applied to the purpose of improving readability of text on self-illuminated monitors.
- compensating for protan (red insensitive) forms of CVD.
- compensating for glare, halation, and related, which involve high luminance/high contrast, but also factor "blue" light as a significant contributor.
- for a color-contrast() type function that returns a color given the adjacent color and target Lc value.
- for an auto-dark-mode function that inverts an entire color scheme, while maintaining hue and Lc contrast.

And
- How much belongs in a normative guideline vs how much can be used in a wider context such as a CSS function.


-- 
GitHub Notification of comment by Myndex
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7357#issuecomment-1183644749 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 13 July 2022 20:26:49 UTC