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

From: Mattias Engdegård <[email-masked]>
Date: Sun, 31 May 2020 22:46:07 +0200

29 maj 2020 kl. 19.52 skrev Tom Tromey <[email-masked]>:

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