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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: tom <at> tromey.com, simon <at> polaris64.net, 41544 <at> debbugs.gnu.org
Subject: Re: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Fri, 05 Jun 2020 15:27:22 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 4 Jun 2020 17:29:06 +0200
> Cc: tom <at> tromey.com, simon <at> polaris64.net, 41544 <at> debbugs.gnu.org
> 
> 1. color-name-to-rgb calls (color-values "#ffffffffffff") as a means to get the range of the colour values.

There's some history to that: see bug#25890.

> 2. With TERM=xterm-color, there are 8 colours. These are assumed to be the 8 first of xterm-standard-colors (xterm.el).
> 3. The colour closest to "#ffffffffffff" is "white", with the values (229 229 229), or translated to 16 bit/channel, (#e5e5 #e5e5 #e5e5) which color-values returns.
> 4. "blue" has the values (0 0 238), or (0 0 #xeeee).
> 5. Thus color-name-to-rgb returns #xeeee/#xe5e5 for the blue channel, or 1.039, which is a clear bug.

What bad results does this issue cause in practice?

(Btw, in a GUI session I see (0.0 0.0 1.0), so no problem there.)

> The main problem is trusting "#ffffffffffff" to match a colour with the maximum range.

Why is that a problem, given the color representation we use in Emacs?

> It could be argued that xterm.el shouldn't use subdued colours when only 8 are present; I didn't go far back in XTerm history to find out. Modern XTerm has default colours 0-7 that correspond to the assumptions of Emacs.
> 
> Since we already document that the colour channel maximum is either 65535 or 65280 depending on platform, taking the very roundabout way of trying to match a sufficiently white colour and using its components is demonstrably unsafe and error-prone, as well as unnecessarily slow. Hence color-component-max in the patch.

Sorry, you lost me here.  I don't understand what you are saying here
and what does that have to do with the problem being discussed.

> This also fixes a different problem: if the display hasn't been initialised fully, such as when running in batch mode, then (color-values "#ffffffffffff") returns nil, and as we shall see later, it may be useful to be able to call color-name-to-rgb at this stage without crashing.

This command:

  emacs -batch --eval "(message \"%s\" (color-name-to-rgb \"white\"))"

yields "(1.0 1.0 1.0)" on my system with today's master branch, and
this command:

  emacs -batch --eval "(message \"%s\" (color-values \"#ffffffffffff\"))"

yields "(65535 65535 65535)", so I don't think I understand what
problem you are concerned with here, and how can this cause a crash.
Please elaborate.

Previous Next

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