GNU bug report logs - #74055
31.0.50; color-lighten-name not lightening black

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74055 in the body.
You can then email your comments to 74055 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; color-lighten-name not lightening black
Date: Mon, 28 Oct 2024 09:27:29 +0100

The function color-lighten-name doesn't work as I would expect for
black:

  (color-lighten-name "#000000" 50)
  => "#000000000000"

I think there is even a test that checks that, in color-tests.el:

(ert-deftest color-tests-lighten-name ()
  (should (equal (color-lighten-name "black" 100) "#000000000000"))

I don't understand this, and it is different from what I'd expect, and
tools for the web return, for example

  https://mdigi.tools/lighten-color/#000000

In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.0.0, NS
 appkit-2566.00 Version 15.0.1 (Build 24A348)) of 2024-10-28 built on
 pro2
Repository revision: ea685170063b59855322ceffdeaaab4acaf8e388
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2566
System Description:  macOS 15.0.1

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Julien Danjou <julien <at> danjou.info>,
 Mattias Engdegård <mattiase <at> acm.org>
Cc: Noah Friedman <noah <at> splode.com>, 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 28 Oct 2024 14:39:17 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 28 Oct 2024 09:27:29 +0100
> 
> The function color-lighten-name doesn't work as I would expect for
> black:
> 
>   (color-lighten-name "#000000" 50)
>   => "#000000000000"
> 
> I think there is even a test that checks that, in color-tests.el:
> 
> (ert-deftest color-tests-lighten-name ()
>   (should (equal (color-lighten-name "black" 100) "#000000000000"))
> 
> I don't understand this, and it is different from what I'd expect, and
> tools for the web return, for example
> 
>   https://mdigi.tools/lighten-color/#000000

Our notion of "lighten color" seems to be to increase the color's
luminance by P percent.  Since the black color's luminance is zero,
increasing that by 50% still yields zero.

By contrast, the page you point to seems to interpret "lighten" to
mean that P is the percentage of the full scale, not of the original
color's luminance.

This goes back to commit 656c2dd66e, which was supposed to fix
bug#54514.  But maybe Noah's interpretation of "lighten" was
incorrect, and we should revert that change?  OTOH, if we do revert
it, then Noah's example will disagree with the above page.

So I guess our algorithm is incorrect somewhere?

Adding Julien and Mattias, in the hope that they could help unconfuse
us.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Julien Danjou <julien <at> danjou.info>, Noah Friedman <noah <at> splode.com>,
 74055 <at> debbugs.gnu.org, Mattias Engdegård <mattiase <at> acm.org>
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 28 Oct 2024 11:18:22 -0400

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

I use below to compute adjusted colors given that lighten doesn't work when
black multipliers are all zero.

(defun my/color-rgb-transform-by-frac (c1 c2 frac)
  "Compute RGB color from C1 adjusted closer to C2 by FRAC.
FRAC is a floating-point number between 0 and 1."
  (cl-destructuring-bind (c1-r c1-g c1-b) c1
    (cl-destructuring-bind (c2-r c2-g c2-b) c2
      (list (+ c1-r (* (- c2-r c1-r) frac))
            (+ c1-g (* (- c2-g c1-g) frac))
            (+ c1-b (* (- c2-b c1-b) frac))))))

(defun my/color-hex-transform-by-frac (c1 c2 frac)
  "Compute hex color from C1 adjusted closer to C2 by FRAC.
FRAC is a floating-point number between 0 and 1."
  (apply #'color-rgb-to-hex
         (my/color-rgb-transform-by-frac (color-name-to-rgb c1)
                                         (color-name-to-rgb c2)
                                         frac)))

;; e.g.,
(my/color-hex-transform-by-frac "black"
                                "white"
                                0.10) ; produces "#199919991999"
(color-lighten-name "black" 10) ; produces "#000000000000"

On Mon, Oct 28, 2024 at 8:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Date: Mon, 28 Oct 2024 09:27:29 +0100
> >
> > The function color-lighten-name doesn't work as I would expect for
> > black:
> >
> >   (color-lighten-name "#000000" 50)
> >   => "#000000000000"
> >
> > I think there is even a test that checks that, in color-tests.el:
> >
> > (ert-deftest color-tests-lighten-name ()
> >   (should (equal (color-lighten-name "black" 100) "#000000000000"))
> >
> > I don't understand this, and it is different from what I'd expect, and
> > tools for the web return, for example
> >
> >   https://mdigi.tools/lighten-color/#000000
>
> Our notion of "lighten color" seems to be to increase the color's
> luminance by P percent.  Since the black color's luminance is zero,
> increasing that by 50% still yields zero.
>
> By contrast, the page you point to seems to interpret "lighten" to
> mean that P is the percentage of the full scale, not of the original
> color's luminance.
>
> This goes back to commit 656c2dd66e, which was supposed to fix
> bug#54514.  But maybe Noah's interpretation of "lighten" was
> incorrect, and we should revert that change?  OTOH, if we do revert
> it, then Noah's example will disagree with the above page.
>
> So I guess our algorithm is incorrect somewhere?
>
> Adding Julien and Mattias, in the hope that they could help unconfuse
> us.
>
>
>
>

[Message part 2 (text/html, inline)]

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Julien Danjou <julien <at> danjou.info>, Noah Friedman <noah <at> splode.com>,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 28 Oct 2024 17:57:49 +0100

28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Our notion of "lighten color" seems to be to increase the color's
> luminance by P percent.  Since the black color's luminance is zero,
> increasing that by 50% still yields zero.
> 
> By contrast, the page you point to seems to interpret "lighten" to
> mean that P is the percentage of the full scale, not of the original
> color's luminance.
> 
> This goes back to commit 656c2dd66e, which was supposed to fix
> bug#54514.  But maybe Noah's interpretation of "lighten" was
> incorrect, and we should revert that change?  OTOH, if we do revert
> it, then Noah's example will disagree with the above page.

That change may have been made in haste. For example, it didn't touch the corresponding saturate and desaturate functions which use similar mechanics, so there is now an inconsistency in that respect.

But which interpretation is better isn't obvious. It doesn't have much to do with colour theory per se. As luminance is already a percentage of sorts, it's not at all clear what it means by increasing it by a certain percentage. Personally I wouldn't use either function because of how ill-defined they are.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, julien <at> danjou.info, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 28 Oct 2024 19:24:28 +0200

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 28 Oct 2024 17:57:49 +0100
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>  Julien Danjou <julien <at> danjou.info>,
>  74055 <at> debbugs.gnu.org,
>  Noah Friedman <noah <at> splode.com>
> 
> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > Our notion of "lighten color" seems to be to increase the color's
> > luminance by P percent.  Since the black color's luminance is zero,
> > increasing that by 50% still yields zero.
> > 
> > By contrast, the page you point to seems to interpret "lighten" to
> > mean that P is the percentage of the full scale, not of the original
> > color's luminance.
> > 
> > This goes back to commit 656c2dd66e, which was supposed to fix
> > bug#54514.  But maybe Noah's interpretation of "lighten" was
> > incorrect, and we should revert that change?  OTOH, if we do revert
> > it, then Noah's example will disagree with the above page.
> 
> That change may have been made in haste. For example, it didn't touch the corresponding saturate and desaturate functions which use similar mechanics, so there is now an inconsistency in that respect.
> 
> But which interpretation is better isn't obvious. It doesn't have much to do with colour theory per se. As luminance is already a percentage of sorts, it's not at all clear what it means by increasing it by a certain percentage. Personally I wouldn't use either function because of how ill-defined they are.

Maybe there are widely-accepted de-facto standards for that?

Or maybe we should support more than one interpretation, by way of
some user option?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: julien <at> danjou.info,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 noah <at> splode.com, 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Tue, 29 Oct 2024 05:41:59 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
>> Date: Mon, 28 Oct 2024 17:57:49 +0100
>> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>>  Julien Danjou <julien <at> danjou.info>,
>>  74055 <at> debbugs.gnu.org,
>>  Noah Friedman <noah <at> splode.com>
>> 
>> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> 
>> > Our notion of "lighten color" seems to be to increase the color's
>> > luminance by P percent.  Since the black color's luminance is zero,
>> > increasing that by 50% still yields zero.
>> > 
>> > By contrast, the page you point to seems to interpret "lighten" to
>> > mean that P is the percentage of the full scale, not of the original
>> > color's luminance.
>> > 
>> > This goes back to commit 656c2dd66e, which was supposed to fix
>> > bug#54514.  But maybe Noah's interpretation of "lighten" was
>> > incorrect, and we should revert that change?  OTOH, if we do revert
>> > it, then Noah's example will disagree with the above page.
>> 
>> That change may have been made in haste. For example, it didn't
>> touch the corresponding saturate and desaturate functions which use
>> similar mechanics, so there is now an inconsistency in that respect.
>> 
>> But which interpretation is better isn't obvious. It doesn't have
>> much to do with colour theory per se. As luminance is already a
>> percentage of sorts, it's not at all clear what it means by
>> increasing it by a certain percentage. Personally I wouldn't use
>> either function because of how ill-defined they are.
>
> Maybe there are widely-accepted de-facto standards for that?

I think HSL colors (Hue Saturation Luminescence) are used by CSS for
example, so that's good, and color.el has support for HSL colors. Except
that something is currently not working right, I guess.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: julien <at> danjou.info,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 noah <at> splode.com, 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Tue, 29 Oct 2024 09:25:38 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
>>> Date: Mon, 28 Oct 2024 17:57:49 +0100
>>> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>>>  Julien Danjou <julien <at> danjou.info>,
>>>  74055 <at> debbugs.gnu.org,
>>>  Noah Friedman <noah <at> splode.com>
>>> 
>>> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz <at> gnu.org>:
>>> 
>>> > Our notion of "lighten color" seems to be to increase the color's
>>> > luminance by P percent.  Since the black color's luminance is zero,
>>> > increasing that by 50% still yields zero.
>>> > 
>>> > By contrast, the page you point to seems to interpret "lighten" to
>>> > mean that P is the percentage of the full scale, not of the original
>>> > color's luminance.
>>> > 
>>> > This goes back to commit 656c2dd66e, which was supposed to fix
>>> > bug#54514.  But maybe Noah's interpretation of "lighten" was
>>> > incorrect, and we should revert that change?  OTOH, if we do revert
>>> > it, then Noah's example will disagree with the above page.
>>> 
>>> That change may have been made in haste. For example, it didn't
>>> touch the corresponding saturate and desaturate functions which use
>>> similar mechanics, so there is now an inconsistency in that respect.
>>> 
>>> But which interpretation is better isn't obvious. It doesn't have
>>> much to do with colour theory per se. As luminance is already a
>>> percentage of sorts, it's not at all clear what it means by
>>> increasing it by a certain percentage. Personally I wouldn't use
>>> either function because of how ill-defined they are.
>>
>> Maybe there are widely-accepted de-facto standards for that?
>
> I think HSL colors (Hue Saturation Luminescence) are used by CSS for
> example, so that's good, and color.el has support for HSL colors. Except
> that something is currently not working right, I guess.

TIL the L in HSL actually stands for lightness. And the math for RGB <->
HSL conversion is nicely explained here:

  https://www.niwa.nu/2013/05/math-behind-colorspace-conversions-rgb-hsl/

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, julien <at> danjou.info, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Tue, 29 Oct 2024 13:54:45 +0100

28 okt. 2024 kl. 18.24 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Maybe there are widely-accepted de-facto standards for that?

Perhaps the documentation should said 'percentage points' instead of just 'percent' to be unambiguous, since the lightness value is relative to the white-point.

I'd say the old model (percentage points) is better because it results in changes that are perceptually more uniform. For example, with the current code,

  (color-lighten-name C 5)

has much less effect when C is a dark colour than for a light one. Therefore the change was probably a mistake in hindsight.

> Or maybe we should support more than one interpretation, by way of
> some user option?

Don't think so -- only really a good solution for user preferences, not for an API.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: julien <at> danjou.info, Eli Zaretskii <eliz <at> gnu.org>, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Tue, 29 Oct 2024 19:27:14 +0100

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> I'd say the old model (percentage points) is better because it results
> in changes that are perceptually more uniform. For example, with the
> current code,
>
>   (color-lighten-name C 5)
>
> has much less effect when C is a dark colour than for a light one.
> Therefore the change was probably a mistake in hindsight.

+1

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: julien <at> danjou.info, mattias.engdegard <at> gmail.com, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Sat, 02 Nov 2024 18:17:34 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  julien <at> danjou.info,
>   74055 <at> debbugs.gnu.org,  noah <at> splode.com
> Date: Tue, 29 Oct 2024 19:27:14 +0100
> 
> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
> 
> > I'd say the old model (percentage points) is better because it results
> > in changes that are perceptually more uniform. For example, with the
> > current code,
> >
> >   (color-lighten-name C 5)
> >
> > has much less effect when C is a dark colour than for a light one.
> > Therefore the change was probably a mistake in hindsight.
> 
> +1

I hope I fixed that now, please take a look.

Noah's original example works as expected, and the comparison with Web
sites also seems to be working.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: julien <at> danjou.info, mattias.engdegard <at> gmail.com, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Sat, 02 Nov 2024 18:10:51 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  julien <at> danjou.info,
>>   74055 <at> debbugs.gnu.org,  noah <at> splode.com
>> Date: Tue, 29 Oct 2024 19:27:14 +0100
>> 
>> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>> 
>> > I'd say the old model (percentage points) is better because it results
>> > in changes that are perceptually more uniform. For example, with the
>> > current code,
>> >
>> >   (color-lighten-name C 5)
>> >
>> > has much less effect when C is a dark colour than for a light one.
>> > Therefore the change was probably a mistake in hindsight.
>> 
>> +1
>
> I hope I fixed that now, please take a look.
>
> Noah's original example works as expected, and the comparison with Web
> sites also seems to be working.

Works for me, too. Thanks!

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: julien <at> danjou.info, mattias.engdegard <at> gmail.com, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 04 Nov 2024 13:35:37 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  julien <at> danjou.info,
>>>   74055 <at> debbugs.gnu.org,  noah <at> splode.com
>>> Date: Tue, 29 Oct 2024 19:27:14 +0100
>>> 
>>> Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:
>>> 
>>> > I'd say the old model (percentage points) is better because it results
>>> > in changes that are perceptually more uniform. For example, with the
>>> > current code,
>>> >
>>> >   (color-lighten-name C 5)
>>> >
>>> > has much less effect when C is a dark colour than for a light one.
>>> > Therefore the change was probably a mistake in hindsight.
>>> 
>>> +1
>>
>> I hope I fixed that now, please take a look.
>>
>> Noah's original example works as expected, and the comparison with Web
>> sites also seems to be working.
>
> Works for me, too. Thanks!

Guess I can close this now.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: julien <at> danjou.info, mattias.engdegard <at> gmail.com, noah <at> splode.com,
 74055 <at> debbugs.gnu.org
Subject: Re: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 04 Nov 2024 15:31:35 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: julien <at> danjou.info,  mattias.engdegard <at> gmail.com,  noah <at> splode.com,
>   74055 <at> debbugs.gnu.org
> Date: Mon, 04 Nov 2024 13:35:37 +0100
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> >> I hope I fixed that now, please take a look.
> >>
> >> Noah's original example works as expected, and the comparison with Web
> >> sites also seems to be working.
> >
> > Works for me, too. Thanks!
> 
> Guess I can close this now.

Please do, and thanks.

Previous Next

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