GNU bug report logs - #41544
26.3; Possible incorrect results from color-distance

Previous Next

Full log

Message #64 received at 41544 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tom Tromey <tom <at> tromey.com>, Simon Pugnet <simon <at> polaris64.net>,
 41544 <at> debbugs.gnu.org
Subject: Re: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Wed, 3 Jun 2020 22:08:46 +0200

[Message part 1 (text/plain, inline)]

3 juni 2020 kl. 17.59 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Then I think we should install it.

Thank you; pushed to master.

Now about the consolidation of the contrast colour predicate (color-dark-p): as described previously in detail, the current code for doing so in various places is unsatisfactory. For example, some of the methods employed classify #00ff00 as a "dark" colour, leading to suboptimal results. (Try typing #00ff00 in css-mode.)

There are other bugs that are annoying in themselves, but need to be fixed in order to make progress. Start Emacs in TTY mode with TERM=xterm-color and evaluate (color-name-to-rgb "blue"). Notice how one of the components is greater than 1 -- this is the unfortunate result of several bad decisions.

The attached patch supersedes the previous one; after staring at colour combinations I came to the conclusion that gamma-expansion is a necessity, but the exact sRGB composite gamma curve isn't quite necessary, and a power of 2.2 is close enough.

It also uses a contrasting text colour for the first column in list-colors-display, which serves as a good demonstration of how the predicate works for the standard named colours.

[0001-Use-a-single-light-dark-colour-predicate.patch (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.