[Libreoffice-ux-advise] [Bug 156182] FORMATTING Automatic text color can be unreadable with darker cell colors

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=156182

--- Comment #11 from Myndex <me at andysomers.com> ---
Hi @Heiko Tietze 

As an FYI, case 5 is identical to case 0 or case 2

For case 5, 128 is not perceptual middle contrast, it is too dark. For case
0,2,& 5 an appropriate threshold is 156 (a range of 152 to 164 ish).


The corrected case 4 as shown above in comment #10 is the only technically
correct luminance conversion in the group, as it is the only one based from the
official sRGB IEC 61966-2.1 ... the corrected version works with the thresh
0.36 (range is 0.34 to 0.4)


Case 0,2,5 are using the obsolete NTSC color coefficients, technically
incorrect.


## An APCA version:

APCA uses estimated screen luminance (Ys) for more see "Why APCA" at
https://git.apcacontrast.com/documentation/WhyAPCA


Here is a case 6 using APCA ESL:

Case 6 REM APCA Estimated Screen Luminance
    aLum =  (Red(aColor)/255)^2.4 * 0.2126729 + (Green(aColor)/255)^2.4 *
0.7151522 + (Blue(aColor)/255)^2.4 * 0.072175 
    Threshold = 0.351


The ideal threshold is 0.351 (range is 0.32 ~ 0.38)


## ACCESSIBILITY ISSUES

I'm uploaded an updated playground with the macro with some added rows, and the
updated macro. Also you might be interested in
https://github.com/Myndex/fancyfontflipping which is a repo and demonstrator on
this particular subject.

I've also uploaded some screenshots of these processed for different color
vision deficiencies.

This is an accessibility issue, and as you can see from the screen shot of the
darker version of case five (128), for color vision deficiencies in particular
protanopia, the contrast becomes very low particular for reds.

The accessible thresholds: 

Case 1 and 3: do not use. 

Case 0,2,5: 156 (use only if needed for computational efficiency)

Case 4: 0.36 (using the corrected formula in comment #10)

Case 6: 0.351 (as in case 4 this is computationally more expensive)


So in conclusion, if you're interested in computationally efficiency then the
existing case 0, with a threshold of 156 is a reasonable compromise.

But for accuracy case 4 or case 6 .... definitely case 6 if there is an
interest in adding finer-tuning to contrast (i.e. if you want to incorporate
APCA into the workflow).



For a deeper dive into the minutiae, you might be interested in:
https://www.smashingmagazine.com/2022/09/realities-myths-contrast-color/



Thank you for reading

Andy

-- 
You are receiving this mail because:
You are on the CC list for the bug.