From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Thomas_Fr=C3=B6ssman?= Newsgroups: gmane.emacs.devel Subject: color-rgb-to-hex rounding / color-srgb-to-xyz typos Date: Tue, 12 Jan 2021 12:23:53 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000093e02905b8b24209" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25106"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 12 12:32:07 2021 Return-path: Envelope-to: ged-emacs-devel@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 1kzHuA-0006Qt-Ui for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Jan 2021 12:32:07 +0100 Original-Received: from localhost ([::1]:34026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzHu9-0006EM-Mu for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Jan 2021 06:32:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzHmT-0006oz-04 for emacs-devel@gnu.org; Tue, 12 Jan 2021 06:24:16 -0500 Original-Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]:42654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kzHmQ-0007tp-6Z for emacs-devel@gnu.org; Tue, 12 Jan 2021 06:24:08 -0500 Original-Received: by mail-ot1-x343.google.com with SMTP id x5so1567991otp.9 for ; Tue, 12 Jan 2021 03:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jossystem-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/gw2eta0FkR5/GhukDpynfl03Ki4kRllukzPbOitBFo=; b=XhoYAL8v6Tw/KZAqKlrB7qKDhqE8/DPUqOkhTmCl+TjjKgdH14GAfVE9M3P1zfhGY5 R9Z1BmbOCSaOCOUYJPwpiFDXSoZLNQ8OTCb96i2tSfpenmOoo2P1qnzrh/pJrsTyc1/s jYeEbHdgIgdpbBenBAKNq6lHAPsA/HDvQVnLvZwKSbrsKB0vHj9hZk/p20K1saBUmhwA 6xgVSmJIXvHs0eVmYpw58XT0jdkfSic4ugXU22Uiw8VXNWkvuxwQf8/dyfRNS7D6ln83 g2ExAemDaAnG9zwrSKDTqFgZoYanoFA+Rssw544LKEde14pv/5nVqUf9I1cZgfOZNB8Z Eksg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/gw2eta0FkR5/GhukDpynfl03Ki4kRllukzPbOitBFo=; b=sjQtHzh0Cyw4NUZphSjlhLQ+6Lkitr8RQwO3SiqdEqtuosZg20LqU80zR6Q2Fm7zGT +3m8AyBOJeb5tp/E7ItjnONysXEttExGyyBXrKGHtNPv11Xdt/i5THpSm0RULGpbymNP 2EBxa/z53sIL0N5ebg7PZGJduMqZ8KW9am0kCcOz7qGT2xpD0Ha40Av6iNfZhoCZC+9/ 2nxNjzRAn4yPc+b3cKdt43hUz/9lpiKij40/AjOZ/aV6sgw7lwbJxVgOLoV81N3RstEi wCL1gM+a/xrdNPXx8g88rcc6fyl5C/BjV72q3PwBypUGO5y0YaGHzV0fyZ8ZcOJnbMEt CRgw== X-Gm-Message-State: AOAM530FlXToEYdSrk2RwEIyglRsx9bjNCS938RuzHgF+ZZTOoMY7p0g NZgM4wjJ/e6HDMvlsho2vze+KNsZwnKun9pPR7lK9Qd4cGWrzmE/ X-Google-Smtp-Source: ABdhPJxXJxQtd8cYRjZH7wF7jeUc6/pQw7BVqAEkNRq2gGRY0RwO7QgYI8wA1X8xsNg0sjpMTmO3lVPsINGbhEgOlUo= X-Received: by 2002:a9d:269:: with SMTP id 96mr2430560otb.174.1610450644224; Tue, 12 Jan 2021 03:24:04 -0800 (PST) Received-SPF: none client-ip=2607:f8b0:4864:20::343; envelope-from=thomasf@jossystem.se; helo=mail-ot1-x343.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262967 Archived-At: --00000000000093e02905b8b24209 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1. color-rgb-to-hex rounding Hi. I was investigating why a simple color space conversion from rgb to lab and back via just multiplying a component with 1.0 caused colors to change when being converted back. The issue is that even tiny changes to a component float in LAB space can bring the color value down by 0.00000x or something in RGB and when it's converted back to hex it gets a surprising value. I think I propose this change making rounding optional so that it doesn't affect anyone who is depending on the current behaviour. (defun solarized-color-rgb-to-hex (red green blue &optional digits-per-component round) "Return hexadecimal #RGB notation for the color specified by RED GREEN BLUE. RED, GREEN, and BLUE should be numbers between 0.0 and 1.0, inclusive. Optional argument DIGITS-PER-COMPONENT can be either 4 (the default) or 2; use the latter if you need a 24-bit specification of a color. Optional argument ROUND rounds values which probably is what you usually want." (or digits-per-component (setq digits-per-component 4)) (let* ((maxval (if (=3D digits-per-component 2) 255 65535)) (fmt (if (=3D digits-per-component 2) "#%02x%02x%02x" "#%04x%04x%04x"))) (if round (format fmt (+ 0.5 (* red maxval)) (+ 0.5 (* green maxval)) (+ 0.5(* blue maxval))) (format fmt (* red maxval) (* green maxval) (* blue maxval))))) 2. typos (?) in color-srgb-to-xyz typos While looking at the issue and referencing the wikipedia sRGB page it seems like these values should be changed.. Doing this upset the tests a bit though so I didn't take it all the way because I started trying to understand how to actually produce test case data that is based on some verified numbers and not just the output of color.el's functions. diff --git a/lisp/color.el b/lisp/color.el index 258acbe405..cc478a7525 100644--- a/lisp/color.el+++ b/lisp/color.el@@ -187,16 +187,16 @@ color-srgb-to-xyz "Convert RED GREEN BLUE colors from the sRGB color space to CIE XYZ. RED, GREEN and BLUE should be between 0.0 and 1.0, inclusive." (let ((r (if (<=3D red 0.04045)- (/ red 12.95)+ (/ red 12.92) (expt (/ (+ red 0.055) 1.055) 2.4))) (g (if (<=3D green 0.04045)- (/ green 12.95)+ (/ green 12.92) (expt (/ (+ green 0.055) 1.055) 2.4))) (b (if (<=3D blue 0.04045)- (/ blue 12.95)+ (/ blue 12.92) (expt (/ (+ blue 0.055) 1.055) 2.4)))) (list (+ (* 0.4124564 r) (* 0.3575761 g) (* 0.1804375 b))- (+ (* 0.21266729 r) (* 0.7151522 g) (* 0.0721750 b))+ (+ (* 0.2126729 r) (* 0.7151522 g) (* 0.0721750 b)) (+ (* 0.0193339 r) (* 0.1191920 g) (* 0.9503041 b))))) (defun color-xyz-to-srgb (X Y Z) --=20 Thomas Fr=C3=B6ssman http://t.jossystem.se --00000000000093e02905b8b24209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

1.=C2=A0color-rgb-to-hex rounding

Hi. I was investigating why a simple color space conversio= n from rgb to lab and back via just multiplying a component with 1.0 caused= colors to change when being converted back. The issue is that even tiny ch= anges to a component float in LAB space can bring the color value down by 0= .00000x or something in RGB and when it's converted back to hex it gets= a surprising value.
=C2=A0
I think I propose this change mak= ing rounding optional so that it doesn't affect anyone who is depending= on the current behaviour.

(defun solarized-color-rgb-to-hex (red green blue &optional digits-pe= r-component round)
=C2=A0 "Return hexadecimal #RGB notation for the= color specified by RED GREEN BLUE.
RED, GREEN, and BLUE should be numbe= rs between 0.0 and 1.0, inclusive.
Optional argument DIGITS-PER-COMPONEN= T can be either 4 (the default)
or 2; use the latter if you need a 24-bi= t specification of a color.
Optional argument ROUND rounds values which = probably is what you usually want."
=C2=A0 (or digits-per-component= (setq digits-per-component 4))
=C2=A0 (let* ((maxval (if (=3D digits-pe= r-component 2) 255 65535))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(fmt (if (= =3D digits-per-component 2) "#%02x%02x%02x" "#%04x%04x%04x&q= uot;)))
=C2=A0 =C2=A0 (if round
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (format f= mt (+ 0.5 (* red maxval)) (+ 0.5 (* green maxval)) (+ 0.5(* blue maxval)))<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (format fmt (* red maxval) (* green maxval) = (* blue maxval)))))


2. typos= (?) in=C2=A0color-srgb-to-xyz typos

While looking= at the issue and referencing the wikipedia sRGB page it seems like these v= alues should be changed.. Doing this upset the tests a bit though so I didn= 't take it all the way because I started trying to understand how to ac= tually produce test case data that is based on some verified numbers and no= t just the output of color.el's functions.

diff --git a/lisp/color.el b/lisp/color.el
index 258acbe405..cc478a7525 100644
--- a/lisp/colo=
r.el
+++ b/lisp/col=
or.el
@@ -187,16 +187,16 @@ color-srgb-to-xyz
   "Convert RED GREEN BLUE colors from the sRGB color space to CIE XYZ=
.
 RED, GREEN and BLUE should be between 0.0 and 1.0, inclusive."
   (let ((r (if (<=3D red 0.04045)
-               (/ red =
12.95)
+               (/ re=
d 12.92)
              (expt (/ (+ red 0.055) 1.055) 2.4)))
         (g (if (<=3D green 0.04045)
-               (/ gree=
n 12.95)
+               (/ gr=
een 12.92)
              (expt (/ (+ green 0.055) 1.055) 2.4)))
         (b (if (<=3D blue 0.04045)
-               (/ blue=
 12.95)
+               (/ bl=
ue 12.92)
              (expt (/ (+ blue 0.055) 1.055) 2.4))))
     (list (+ (* 0.4124564 r) (* 0.3575761 g) (* 0.1804375 b))
-          (+ (* 0.2126=
6729 r) (* 0.7151522 g) (* 0.0721750 b))
+          (+ (* 0.21=
26729 r) (* 0.7151522 g) (* 0.0721750 b))
           (+ (* 0.0193339 r) (* 0.1191920 g) (* 0.9503041 b)))))
=20
 (defun color-xyz-to-srgb (X Y Z)



--
Thoma= s Fr=C3=B6ssman
--00000000000093e02905b8b24209--