bug#74055: 31.0.50; color-lighten-name not lightening black

bug#74055: 31.0.50; color-lighten-name not lightening black

[Gerd Möllmann]

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

bug#74055: 31.0.50; color-lighten-name not lightening black

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@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.

bug#74055: 31.0.50; color-lighten-name not lightening black

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

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@gnu.org> wrote:

> > From: Gerd Möllmann <gerd.moellmann@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.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3927 bytes --]

bug#74055: 31.0.50; color-lighten-name not lightening black

[Mattias Engdegård]

28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz@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.

bug#74055: 31.0.50; color-lighten-name not lightening black

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Mon, 28 Oct 2024 17:57:49 +0100
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  Julien Danjou <julien@danjou.info>,
>  74055@debbugs.gnu.org,
>  Noah Friedman <noah@splode.com>
> 
> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz@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?

bug#74055: 31.0.50; color-lighten-name not lightening black

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mattias Engdegård <mattias.engdegard@gmail.com>
>> Date: Mon, 28 Oct 2024 17:57:49 +0100
>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>>  Julien Danjou <julien@danjou.info>,
>>  74055@debbugs.gnu.org,
>>  Noah Friedman <noah@splode.com>
>> 
>> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz@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.

bug#74055: 31.0.50; color-lighten-name not lightening black

[Gerd Möllmann]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Mattias Engdegård <mattias.engdegard@gmail.com>
>>> Date: Mon, 28 Oct 2024 17:57:49 +0100
>>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>>>  Julien Danjou <julien@danjou.info>,
>>>  74055@debbugs.gnu.org,
>>>  Noah Friedman <noah@splode.com>
>>> 
>>> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz@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/

bug#74055: 31.0.50; color-lighten-name not lightening black

[Mattias Engdegård]

28 okt. 2024 kl. 18.24 skrev Eli Zaretskii <eliz@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.

bug#74055: 31.0.50; color-lighten-name not lightening black

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@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