bug#41544: 26.3; Possible incorrect results from color-distance

[Mattias Engdegård]

29 maj 2020 kl. 19.52 skrev Tom Tromey <tom@tromey.com>:

> However, my main concern is just whether it still picks reasonably
> contrasting colors when editing CSS.  If it does, then that's good
> enough for me.

Thank you for the kind words. I couldn't leave well enough alone, of course. 
Emacs does this sort of is-this-colour-dark computation in at least 7 different 
places, with different algorithms:

* max(r,g,b) < 0.5
* r+g+b < 0.5*3
* color-distance(c, "black") < 292485

They aren't really satisfactory: for example, saturated blue (#0000ff) is quite 
clearly 'dark', yet the first algorithm considers it 'light'. Colour distance 
isn't quite right either -- the implemented formula is intended to measure 
distances between colours, not brightness. For example, it considers #ff0000 to 
be closer than #0000ff to black, but the red is clearly brighter.

I tentatively went with your suggested 0.299r + 0.587g + 0.114g, with a cut-off 
value of 0.58 to make saturated blue and red 'dark' and green 'light'. This is 
not a correct luma calculation since there is no gamma correction, but it might 
do for this purpose.

Proposed patch attached. I found css-mode no worse than before (a tad better, 
if anything). Perhaps we need to decompress to linear components after all, but 
at least now there is a single place to do it.

(Should list-colors-display use color-dark-p for the text in its left column, 
by the way? Or is there a point in not doing so?)

0001-Use-a-single-light-dark-colour-predicate.patch
Description: Binary data