GNU bug report logs -
#41544
26.3; Possible incorrect results from color-distance
Previous Next
Full log
Message #25 received at 41544 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
29 maj 2020 kl. 19.52 skrev Tom Tromey <tom <at> 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 (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
This bug report was last modified 4 years and 304 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.