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: Re: color-rgb-to-hex rounding / color-srgb-to-xyz typos Date: Wed, 20 Jan 2021 16:17:31 +0100 Message-ID: References: <87wnw9r3zv.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d91d1505b95674e7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20781"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 20 16:23:25 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 1l2FKP-0005HY-GX for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 16:23:25 +0100 Original-Received: from localhost ([::1]:51972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2FKO-0005vL-GG for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Jan 2021 10:23:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2FEw-000095-73 for emacs-devel@gnu.org; Wed, 20 Jan 2021 10:17:53 -0500 Original-Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:37502) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l2FEt-0007V5-Sv for emacs-devel@gnu.org; Wed, 20 Jan 2021 10:17:45 -0500 Original-Received: by mail-ot1-x32e.google.com with SMTP id o11so23698234ote.4 for ; Wed, 20 Jan 2021 07:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jossystem-se.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mc7pauSwEY6dyPrb1lUJ6m9QuU+6NPJ7YT38wj2B8/k=; b=VOu/UZhM6k0zI9pjHuojp5TY44TIQLImcPBGs6cesyGn5uaeLqMwXbT3JY1rSz8E9Q UoNUTkNEM+muxEdxrn3P5kPWvawbn/0/yha7AFLNZSGOefHM/LziBkZsqUZZci9kigGl S+sFfk6WIzMXOuWy0YeAU8gMsQGZUMT0YX3vTe4zd9JdK5ZOIxVGsepI/45Wd7kvXXM5 zy7VPa65BlFiereRise26bEiiWSAOlmXdrBtl2E7D6iBJIMkmCm+AQSB0ApLWomD6VLC oWAPC2ozENMhBnfj54J9RKiBBSAgYo8vf24J9VhqIuI6StGxGSPLc+zQu8X2mYPazrls /2vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mc7pauSwEY6dyPrb1lUJ6m9QuU+6NPJ7YT38wj2B8/k=; b=DUcFKryeoR1dsLqItOt4j5MnU0c9eYUjkFFSGJQUdkVoY7U+9EccAlSQVWwftYL07S 8Uz6v0/kdo1+bWPQBXvmut98KR/uCfr5m5q02uEwq54ilrdRwLLL3qodTehme1CrDvZa MzQdRTB527fssehB0D9SRGRhPI2l7rqk3wuYW5GrJVYSzTLB1RxHklfRgYt9Qoo33QnJ dttHLpRkl1ci9gQuUj3WMtPKPXXZcyBIkDBAsL4dUbbK8fydLZwLW0XeVYPeYNTSNBKL HWKn6uhmQ1yR827Fb2sNJrqyCuVcSIsNHspitzueUmBvOjLe87Ab89mHGNJE1UBOJ7Hc 8cGA== X-Gm-Message-State: AOAM530sJTCHFNjQRBrs9YV8h4LRX9mdTelf51Zn5kQLnEiTZFhX1RdX 5Zp/xa2RnIJgijM+ryWP/VS167eafR1So7IBjK5/xZ0tSOCTj7wu X-Google-Smtp-Source: ABdhPJyswxyBLXzZQmER3cYOopR0jQHoVDFoC1p2Nk6tQPihECQRDKkUgsPp7d92HdeVUHB750ofoAYB0idk7GMezzU= X-Received: by 2002:a05:6830:3108:: with SMTP id b8mr7205126ots.174.1611155862258; Wed, 20 Jan 2021 07:17:42 -0800 (PST) In-Reply-To: <87wnw9r3zv.fsf@gnus.org> Received-SPF: none client-ip=2607:f8b0:4864:20::32e; envelope-from=thomasf@jossystem.se; helo=mail-ot1-x32e.google.com X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 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, URI_DOTEDU=1.997 autolearn=no 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:263207 Archived-At: --000000000000d91d1505b95674e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2021 at 4:37 AM Lars Ingebrigtsen wrote: > Thomas Fr=C3=B6ssman writes: > > > 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) > > Was this meant to be added to the solarized package, or to the in-tree > `color-rgb-to-hex' function? > Yes the in tree one, I added the change locally to that theme to avoid getting the rounding issues but I forgot to remove the prefix when posting to the e-mail list. I am really not sure if rounding should just always be applied or if it should be optional, I can't see many situations when you would not want to round but at the same time it will change colors in existing code ever so slightly. > > > 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. > > I don't know, either. Is this related to bug#41544, perhaps? > I don't think color-distance has anything to do with color.el at all. Fixing these small value changes doesn't practically change much as far as I could see except that color-tests.el maybe shouldn't assume that it's own internal functions are correct when testing. I mostly want good test data for the ciede2000 function, there is probably good test data available here but it's unlikely to be usable in emacs due to licensing. http://www2.ece.rochester.edu/~gsharma/ciede2000/ I might resume work on finding better test data a little later and then create a patch of it all. > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > --=20 Thomas Fr=C3=B6ssman http://t.jossystem.se --000000000000d91d1505b95674e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 19, 2021 at 4:37 AM Lars = Ingebrigtsen <larsi@gnus.org> w= rote:
Thomas Fr= =C3=B6ssman <t= homasf@jossystem.se> writes:

> 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)

Was this meant to be added to the solarized package, or to the in-tree
`color-rgb-to-hex' function?

Yes th= e in tree one, I added the change locally to that theme to avoid getting th= e rounding issues but I forgot to remove the prefix when posting to the e-m= ail list.

I am really not sure if rounding should = just always be applied or if it should be optional, I can't see many si= tuations when you would not want to round but at the same time it will chan= ge colors in existing code ever so slightly.
=C2=A0

> 2. typos (?) in color-srgb-to-xyz typos
>
> While looking at the issue and referencing the wikipedia sRGB page it<= br> > 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 try= ing
> to understand how to actually produce test case data that is based on<= br> > some verified numbers and not just the output of color.el's functi= ons.

I don't know, either.=C2=A0 Is this related to bug#41544, perhaps?
<= /blockquote>

I don't think color-distance has anythi= ng to do with color.el at all.

Fixing these small = value changes doesn't practically change much as far as I could see exc= ept that color-tests.el maybe shouldn't assume that it's own intern= al functions are correct when testing.=C2=A0

I mos= tly want good test data for the=C2=A0ciede2000 function, there is probably = good test data available here but it's unlikely to be usable in emacs d= ue to licensing. http://www2.ece.rochester.edu/~gsharma/ciede2000/ I might resume wo= rk on finding better test data a little later and then create a patch of it= all.
=C2=A0

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no


--
Thomas Fr=C3=B6ssman
--000000000000d91d1505b95674e7--