From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#41544: 26.3; Possible incorrect results from color-distance Date: Thu, 28 May 2020 19:31:51 +0200 Message-ID: <5C4A633D-8222-4439-BE37-9B8674F1DA6D@acm.org> References: <874ks2vew3.fsf@polaris64.net> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="47173"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tom Tromey , 41544@debbugs.gnu.org To: Simon Pugnet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 28 19:35:05 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jeMQq-000CAI-VU for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 19:35:04 +0200 Original-Received: from localhost ([::1]:38008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeMQq-0006uM-10 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 May 2020 13:35:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeMNv-0001tn-2e for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 13:32:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeMNu-0006cG-NN for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 13:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jeMNu-00071s-Jv for bug-gnu-emacs@gnu.org; Thu, 28 May 2020 13:32:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <874ks2vew3.fsf@polaris64.net> Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 May 2020 17:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41544 X-GNU-PR-Package: emacs Original-Received: via spool by 41544-submit@debbugs.gnu.org id=B41544.159068712127013 (code B ref 41544); Thu, 28 May 2020 17:32:02 +0000 Original-Received: (at 41544) by debbugs.gnu.org; 28 May 2020 17:32:01 +0000 Original-Received: from localhost ([127.0.0.1]:52960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeMNq-00071a-Aj for submit@debbugs.gnu.org; Thu, 28 May 2020 13:32:01 -0400 Original-Received: from mail223c50.megamailservers.eu ([91.136.10.233]:40682 helo=mail33c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeMNo-00071S-VJ for 41544@debbugs.gnu.org; Thu, 28 May 2020 13:31:57 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1590687114; bh=Yasi4sRb1zKngiAa7lQrTx2do4QJcOubwplCyGiejhk=; h=From:Subject:Date:Cc:To:From; b=VP62f5XJ/YhUfdjMe1z3bBLUnfQRYAaxhM5N1mgqMBYXRhU+0QK1d+ggG8gja0GbN p2rOWpYCBS1qY0A4iu6ex4KTJbZ51rxlMMPEhowhchQuSIFMw3h7yQ1qMKhJgi99gu yUMtFZSAiZIfzD7Tmr89vQypaKzTogSZbdhWoiqM= Feedback-ID: mattiase@acm.or Original-Received: from stanniol.lan (c-4e4ae655.032-75-73746f71.bbcust.telenor.se [85.230.74.78]) (authenticated bits=0) by mail33c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 04SHVp2O000373; Thu, 28 May 2020 17:31:53 +0000 X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F17.5ECFF520.003D:SCFSTAT68638221, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: -4.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=eaJDgIMH c=1 sm=1 tr=0 a=klNLuyVZdLUgl+K5Uafb2A==:117 a=klNLuyVZdLUgl+K5Uafb2A==:17 a=kj9zAlcOel0A:10 a=M51BFTxLslgA:10 a=XxNu1oolT2MRe3TBGnIA:9 a=CjuIK1q_8ugA:10 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181153 Archived-At: [CC:ing Tom Tromey, who used colour-distance in css-mode] Ah, where to begin. Clearly a distance metric ought to be symmetric; as = you note, this is easily fixed by replacing the shift by division, which = has the extra benefit of not relying on the implementation-defined = behaviour when right-shifting negative values in C. The extra cost is = negligible. Looking at it a bit closer, it seems a waste to use full 16 bit colour = channels only to shift out 8 of them before getting started. I presume = this was done partly in order to follow the Riedersma metric more = closely, and partly to stay within 32 bit numbers (I note that the code = uses the C 'long' type, which is almost always a mistake). Using 64-bit = arithmetic costs us next to nothing today, and this solves several = problems. But a darker cloud is on the horizon. Since the Emacs implementation = omits the square root of the result, it no longer satisfies the triangle = inequality, which is even more fundamental for distance metrics than = symmetry. It is good enough for comparison of distances, but they can no = longer be added, since it's not a true metric. In fact, it seems that users of color_distance are confused as well: a = comment says /* If the distance (as returned by color_distance) between two colors = is less than this, then they are considered the same, for determining whether a color is supported or not. The range of values is = 0-65535. */ #define TTY_SAME_COLOR_THRESHOLD 10000 which is a lie, since color_distance can return values well above 65535. Some uses are very questionable, given that it's the square of a metric: int delta_delta =3D (color_distance (&fg_std_color, &bg_std_color) - color_distance (&fg_tty_color, &bg_tty_color)); if (delta_delta > TTY_SAME_COLOR_THRESHOLD || delta_delta < -TTY_SAME_COLOR_THRESHOLD) So what to do? Best would be to do the arithmetic on the entire channel = values and take the square root at the end; the cost is nothing to worry = about on hardware less than 30 years old. Some constants used for = comparison would need to be adjusted: the above-mentioned = TTY_SAME_COLOR_THRESHOLD (10000), face-near-same-threshold (30000), and = a number in css--contrasty-color (292485). At least the last should = probably use the luma norm originally proposed instead (see bug#25525); = the use of colour-distance here cannot be right.