[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 #6 from Myndex <me at andysomers.com> ---
Hi @Heiko Tietze 

So the existing

>  luma = sal_uInt8((B * 29UL + G * 151UL + R * 76UL) >> 8);

Is essentially the Yʹ (Y prime) "luma" from NTSC, it is not "luminance" but is
a gamma encoded value.

It is less accurate, however it's computationally inexpensive, and for the
purpose of picking a point to flip from black to white text, strict accuracy is
probably not needed, as the flip point is a single threshold level and is
itself "fuzzy".

if you want to keep it maximally simple, using that existing luma definition,
then when luma is less than 164, text should be white, otherwise, black.

This is based on #a4a4a4 being perceptual center contrast between black and
white on self illuminated sRGB displays in typical contexts.


## Regarding the macro

Case 0 try a threshold of 164

Case 1 is incorrect (that answer on stack is incorrect, as I pointed out in my
answer to that question https://stackoverflow.com/a/56678483/10315269). the
reason is that the sRGB coefficients require the data to be normalized 0-1 and
then linearized ^2.2

Case 2 is functionally the same as your existing case 0, a useful threshold
would be 164

Case 3 is wrongly using wrong coefficients and wrong gamma ... 

Case 4 is my down and dirty actual luminance, but the macro shows a threshold
of 0.6 which is incorrect. If using actual luminance, the threshold is 0.36 

Case 5 is an obsolete and incorrect WCAG 1.0 attempt at something...



Thus case 0 or 2 need a threshold of 164, but are a little less accurate than
actual luminance

case 4 needs a threshold of 0.36


Sorry for the delay in my response, but please let me know if you have any
further questions.

Andy

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