Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Stefan Monnier]

> +(defun color-dark-p (rgb)
> +  "Whether RGB is more readable against white than black.
> +RGB is a 3-element list (R G B), each component in the range [0,1].
> +This predicate can be used both for determining a suitable (black or white)
> +contrast colour with RGB as background and as foreground."
> +  (unless (<= 0 (apply #'min rgb) (apply #'max rgb) 1)
> +    (error "RGB components %S not in [0,1]" rgb))
> +  ;; Compute the relative luminance after gamma-correcting (assuming sRGB),
> +  ;; and compare to a cut-off value determined experimentally.
> +  ;; See https://en.wikipedia.org/wiki/Relative_luminance for details.
> +  (let* ((sr (nth 0 rgb))
> +         (sg (nth 1 rgb))
> +         (sb (nth 2 rgb))
> +         ;; Gamma-correct the RGB components to linear values.
> +         ;; Use the power 2.2 as an approximation to sRGB gamma;
> +         ;; it should be good enough for the purpose of this function.
> +         (r (expt sr 2.2))
> +         (g (expt sg 2.2))
> +         (b (expt sb 2.2))
> +         (y (+ (* r 0.2126) (* g 0.7152) (* b 0.0722))))

Could we arrange to share the code with `color-srgb-to-xyz` (in `color.el`)?

> +    (< y (eval-when-compile (expt 0.6 2.2)))))

Where does this 0.6 come from?
I don't see it in https://en.wikipedia.org/wiki/Relative_luminance
[ I don't doubt it's a good choice, but I think we should document
  where these thing come from.  ]


        Stefan

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

10 juni 2020 kl. 21.20 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

> Could we arrange to share the code with `color-srgb-to-xyz` (in `color.el`)?

We could, but I thought it useful to have the freedom to tweak the coefficients (and the gamma conversion) as required for this specific purpose, rather than being stuck with the theoretical CIE luminance from sRGB. This gives us more degrees of freedom than just having the cut-off value as modifiable parameter.

Experiments with some alternative coefficients and exponents showed fairly good results, but I went with the safer set of numbers for the initial version.

> Where does this 0.6 come from?

It's documented above, "a cut-off value determined experimentally". I can move the comment closer to the number.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Stefan Monnier]

>> Where does this 0.6 come from?
> It's documented above, "a cut-off value determined experimentally".

I saw that part, but I was expecting a description of (or a pointer to)
the experiment.  Since it depends on the actual color, the human
subject, the monitor, and the ambient lighting (i.e. the search space is
very large), I expect these experiments took a significant amount of
work, so I'd expect some trace of it written down somewhere.


        Stefan

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Yuri Khan]

On Thu, 11 Jun 2020 at 02:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > +This predicate can be used both for determining a suitable (black or white)
> > +contrast colour with RGB as background and as foreground."

> > +  ;; and compare to a cut-off value determined experimentally.
> > +  ;; See https://en.wikipedia.org/wiki/Relative_luminance for details.

> > +    (< y (eval-when-compile (expt 0.6 2.2)))))
>
> Where does this 0.6 come from?
> I don't see it in https://en.wikipedia.org/wiki/Relative_luminance

Instead of comparing the relative luminance against an experimentally
determined cutoff, why not do the actual calculations of contrast
ratio against black and white?

The formula for contrast ratio is: C = (L1+0.05) / (L2+0.05) [1]
where L1 and L2 are relative luminances of the brighter and the darker colors.

So contrast against black is (L+0.05) / 0.05 and contrast against
white is 1.05 / (L+0.05). Solving for the middle ground L where these
give the same result:

(L+0.05) / 0.05 = 1.05 / (L+0.05)
(L+0.05)^2 = 1.05 * 0.05
L+0.05 = (1.05 * 0.05)^0.5
L = (1.05 * 0.05)^0.5 - 0.05 ≈ 0.18 corresponding to a gray around #767576

Experimentally, I find white and black over #767576 about equally easy
to read; over a light gray #cccbcc (L=0.6), black is much more
readable than white.

[1]: https://www.w3.org/TR/WCAG21/#dfn-contrast-ratio

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

11 juni 2020 kl. 07.15 skrev Yuri Khan <yuri.v.khan@gmail.com>:
> 
> On Thu, 11 Jun 2020 at 02:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>> Where does this 0.6 come from?

This is an excellent question and so is Yuri's, so I'm going to try to answer both at the same time.

Originally, 0.6^2.2=0.325 was chosen in order to preserve the greyscale behaviour of the otherwise dubious R+G+B<0.6 criterion used by Emacs in various places, with the assumption that at least the brightness was carefully chosen. This appears to be sort-of true.

> L = (1.05 * 0.05)^0.5 - 0.05 ≈ 0.18 corresponding to a gray around #767576

Yes, and moreover Y=0.18 corresponds to a lightness of 50%, so I very much thought that it would be better than 0.325. However, the machines and screens I've looked at (various LCD and CRT displays, macOS, Linux, etc) don't bear that out. For example, white text is decidedly more readable than black onto a background of #8b7500 (gold4) everywhere. Of course, your equipment may be different!

(I'll be more careful to keep a lab notebook next time -- mostly do that for paid work/research only.)

> Experimentally, I find white and black over #767576 about equally easy
> to read; over a light gray #cccbcc (L=0.6), black is much more
> readable than white.

Unfortunately I only have access to my Mac right now, but here I find white to be somewhat easier to read than black against #767576 as background. That colour certainly looks darker than the balance point.

As it turned out, however, the exact cut-off value matters a lot less than anticipated. The most important property of contrasting colour selection is not picking the slightly better one but avoiding a disastrous choice, and there is a fairly wide interval of cut-off values that do reasonably well; a lot of colours in the middle work with either black or white.

In addition, although different screens and systems vary in their calibration and policy, it doesn't seem to matter much in this case. When the colours move, so does white, keeping the relations roughly the same.

Precision may be more important when the same predicate is used for selecting prearranged palettes for use against 'light' and 'dark' backgrounds. This still needs to be investigated.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Yuri Khan]

On Thu, 11 Jun 2020 at 23:15, Mattias Engdegård <mattiase@acm.org> wrote:
> For example, white text is decidedly more readable than black onto a background of #8b7500 (gold4) everywhere. Of course, your equipment may be different!

My equipment (which is two myopic and slightly astigmatic eyes looking
through corrective glasses at a 24″ IPS-based Dell P2415Q running at
native resolution and with contrast and brightness knobs tuned to not
be painful but still pass the tests at
<http://www.lagom.nl/lcd-test/>) says that shade of gold in fact
performs okay in all four scenarios: gold on black, gold on white,
white on gold, black on gold.

> Precision may be more important when the same predicate is used for selecting prearranged palettes for use against 'light' and 'dark' backgrounds. This still needs to be investigated.

WCAG recommends a color contrast of at least 4.5 for most uses of text
below 18pt (or 14pt bold). The range of color contrast (1 to 21) and
the inherent properties of real numbers (4.5^2 = 20.25) suggest that
there is only a fairly narrow band of colors that satisfies that
contrast level against both white and black.

Further, if you were to pick a palette consisting of white, black, and
multiple colors from that band, you’d get another problem. Namely, all
your text is the same relative luminance. That means you have to
distinguish e.g. syntax elements solely by their hue. Users with color
vision anomalies might not even be able to do that.

A good palette meets or exceeds the recommended contrast ratio against
the background for all text colors, and provides at least *some*
variation in relative luminance of text colors.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

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

11 juni 2020 kl. 21.22 skrev Yuri Khan <yuri.v.khan@gmail.com>:

> My equipment [...] says that shade of gold in fact
> performs okay in all four scenarios

I have no reason to doubt your observations. Let's try a plebiscite!

                      * * *

Dear Emacs developer or user,

Please load the attached code (any Emacs version), and run M-x contrast-compare with various cutoff values on your favourite system, to find what value is best for readability of the colour names (first column).

Colours with luminance (last column) below the cutoff will be use white text, others black. It is mainly Emacs in graphical (non-TTY) mode that is of interest.

Please reply (to emacs-devel or to me) the following pieces of information:

* the cutoff value you found optimal
* system information: window system, screen, anything you think is relevant
* whether you use a light or dark background in your Emacs


[-- Attachment #2: color-contrast.el --]
[-- Type: application/octet-stream, Size: 1727 bytes --]

;;; -*- lexical-binding: t -*-

(defconst contrast-default-cutoff 0.325)

(defun contrast-compare (cutoff)
  "Compare black and white text on various colours."
  (interactive
   (list (string-to-number
          (read-from-minibuffer "Cutoff value: "
                                (number-to-string contrast-default-cutoff)))))

  (with-current-buffer (get-buffer-create "*Contrast comparison*")
    (erase-buffer)
    (let ((cols nil)
          (seen (make-hash-table :test 'equal)))
      (dolist (name (defined-colors))
        (let ((cv (color-values name)))
          (unless (gethash cv seen)
            (puthash cv cv seen)
            (push (cons cv name) cols))))
      (insert (format "cutoff = %f\n" cutoff))
      (dolist (c (reverse cols))
        (let* ((cv (car c))
               (name (cdr c))
               (hex (apply #'format "#%02x%02x%02x"
                           (mapcar (lambda (x) (/ x 256)) cv)))
               (rgb (mapcar (lambda (x) (/ x 65535.0)) cv))
               (r (expt (nth 0 rgb) 2.2))
               (g (expt (nth 1 rgb) 2.2))
               (b (expt (nth 2 rgb) 2.2))
               (y (+ (* r 0.2126) (* g 0.7152) (* b 0.0722)))
               (fg (if (< y cutoff) "#ffffff" "#000000")))
          (insert
           (propertize
            (format "  %-20.20s  " name)
            'face (list :background name :foreground fg))
           (propertize
            (format " %s " hex)
            'face (list :background name :foreground "#ffffff"))
           (propertize
            (format " %s " hex)
            'face (list :background name :foreground "#000000"))
           (format "  %.5f\n" y)))))
    (let ((pop-up-windows t))
      (display-buffer (current-buffer)))))

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[tomas]

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

On Fri, Jun 12, 2020 at 05:50:32PM +0200, Mattias Engdegård wrote:
> 11 juni 2020 kl. 21.22 skrev Yuri Khan <yuri.v.khan@gmail.com>:
> 
> > My equipment [...] says that shade of gold in fact
> > performs okay in all four scenarios
> 
> I have no reason to doubt your observations. Let's try a plebiscite!
> 
>                       * * *
> 
> Dear Emacs developer or user,
> 
> Please load the attached code (any Emacs version), and run M-x contrast-compare with various cutoff values on your favourite system, to find what value is best for readability of the colour names (first column).
> 
> Colours with luminance (last column) below the cutoff will be use white text, others black. It is mainly Emacs in graphical (non-TTY) mode that is of interest.
> 
> Please reply (to emacs-devel or to me) the following pieces of information:
> 
> * the cutoff value you found optimal

You mean: where the color name is most readable against all
backgrounds? 0.375 (although 0.325 gives fine results too)

> * system information: window system, screen, anything you think is relevant

X on Gnu/Linux, thinkpad X230 with the cheaper screen (no IPS)

> * whether you use a light or dark background in your Emacs

Dark Emacs (but not too dark, #333333-ish)

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Yuri Khan]

On Fri, 12 Jun 2020 at 22:50, Mattias Engdegård <mattiase@acm.org> wrote:

> Please load the attached code (any Emacs version), and run M-x contrast-compare with various cutoff values on your favourite system, to find what value is best for readability of the colour names (first column).
> Please reply (to emacs-devel or to me) the following pieces of information:
>
> * the cutoff value you found optimal
> * system information: window system, screen, anything you think is relevant
> * whether you use a light or dark background in your Emacs

Despite science calling for .18, I find that my subjective optimal
cutoff is somewhere between .25 and .31, even if I change the formulae
to more accurately model the piecewise gamma correction of sRGB:

-               (r (expt (nth 0 rgb) 2.2))
+               (R (nth 0 rgb))
+               (r (if (<= R 0.03928)
+                      (/ R 12.92)
+                    (expt (/ (+ R 0.055) 1.055) 2.4)))

(same for g and b.)

I am on GTK+3/X11, Dell P2415Q (HiDPI IPS), RGB-subpixel slight-hinted
Cousine font at 10.5pt, on overall dark gray background (#414042).

RE: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Drew Adams]

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

> Please load the attached code (any Emacs version), and run M-x contrast-
> compare with various cutoff values on your favourite system, to find what
> value is best for readability of the colour names (first column).
> 
> Colours with luminance (last column) below the cutoff will be use white text,
> others black. It is mainly Emacs in graphical (non-TTY) mode that is of
> interest.
> 
> Please reply (to emacs-devel or to me) the following pieces of information:
> 
> * the cutoff value you found optimal
> * system information: window system, screen, anything you think is relevant
> * whether you use a light or dark background in your Emacs


Emacs 26.3, MS Windows 10, fairly old Dell monitor.

With emacs -Q, so light background: 

Cutoff 0.325 (default) is OK.
.2, .4, .5, and .6 are all OK. 

To me, showing the same color in both black & white,
next to each other, was the most helpful for deciding.
I looked mostly at the grays, and looked at their hex
codes, which are shown in both black & white.

Based on that, I'd say that that gray60 is about the
crossover point: black or white foreground are equally
readable for gray60 and immediate neighbors.  And that
corresponds to your default cutoff of about 0.325.
See attached screenshot.

Around that area, white text was generally more
visible/noticeable, but it was less _readable_.

But it makes no difference, with that comparison,
whether the frame background is light or dark.  Why?
because the areas to be compared provide their own
background - the frame background is seen only with
the rightmost (decimal-number) field.

[-- Attachment #2: throw-color-contrast-grays.png --]
[-- Type: image/png, Size: 18573 bytes --]

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Stephen Leake]

Mattias Engdegård <mattiase@acm.org> writes:

> * the cutoff value you found optimal

0.325 works for me; I found it hard to see any difference between 0.2
and 0.5 (some colors did switch from light to dark foreground, but they
were equally readable. I did not spend much time studying all the colors.

> * system information: window system, screen, anything you think is
> relevant 

Windows 8, LG IPS LED display, 2560 x 1440, 27 inch diagonal

> * whether you use a light or dark background in your Emacs

(:background "light goldenrod yellow" :foreground "black")

-- 
-- Stephe

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

A "plebiscite" means counting votes.  That is not a good way to decide
which features to include.

You have asked people to give important information about what works
well or badly for each of them.  That is a useful thing to do, because
using their responses it may be possible to figure out a solution that
works ok for all users, or nearly all users.

It may also be possible to figure out a good rule for choosing between
one behavior and another.  That could work well for everyone.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

12 juni 2020 kl. 20.36 skrev Yuri Khan <yuri.v.khan@gmail.com>:

> Despite science calling for .18, I find that my subjective optimal
> cutoff is somewhere between .25 and .31, even if I change the formulae
> to more accurately model the piecewise gamma correction of sRGB:

Thanks for the report, and yes, I did test with the exact sRGB gamma curve and noticed almost no significant differences.
The only differences in the standard colour table are: #999999 (grey60), #ee7600 (darkorange2), #ee7621 (chocolate2) and #bc8f8f (rosybrown), all categorised as 'light' with power 2.2 and 'dark' with the exact sRGB gamma function, assuming a cutoff of 0.325. It's really hard to say which one is right.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

Thanks to those who replied -- the originally proposed 0.325 luminance limit seems to be fairly uncontroversial and can be changed if evidence indicates that it was badly chosen. Most of all, the value seems to work well across all platforms and a sufficient variety of equipment, which is the important part.

Special thanks to Yuri for helping me confirm that the theoretical 50% lightness of luminance 0.18 wasn't necessarily an optimal value in this case. Trust my own eyes, but verify!

The constant has now been given a (provisional) name, for extra clarity and ease of adjustment.

RE: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Drew Adams]

> Thanks to those who replied -- the originally proposed 0.325 luminance limit
> seems to be fairly uncontroversial and can be changed if evidence indicates
> that it was badly chosen. Most of all, the value seems to work well across
> all platforms and a sufficient variety of equipment, which is the important
> part.
> 
> Special thanks to Yuri for helping me confirm that the theoretical 50%
> lightness of luminance 0.18 wasn't necessarily an optimal value in this case.
> Trust my own eyes, but verify!
> 
> The constant has now been given a (provisional) name, for extra clarity and
> ease of adjustment.

Not to belabor this, and I don't recall all that's
involved.

But if there are different eyes, screens, whatever,
would it make sense to use a defvar, or even a defcustom,
instead of a defconst?  Why decide this definitively
at design time?  Does it make sense to hard-code it?

If the question isn't useful, please ignore.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Basil L. Contovounesios]

Mattias Engdegård <mattiase@acm.org> writes:

> Thanks to those who replied -- the originally proposed 0.325 luminance limit
> seems to be fairly uncontroversial and can be changed if evidence indicates that
> it was badly chosen. Most of all, the value seems to work well across all
> platforms and a sufficient variety of equipment, which is the important part.
>
> Special thanks to Yuri for helping me confirm that the theoretical 50% lightness
> of luminance 0.18 wasn't necessarily an optimal value in this case. Trust my own
> eyes, but verify!
>
> The constant has now been given a (provisional) name, for extra clarity and ease of adjustment.

Thanks!  Could the constant's docstring please follow the convention
described under (info "(elisp) Documentation Tips") of keeping the first
sentence on a single line?

-- 
Basil

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

18 juni 2020 kl. 21.40 skrev Basil L. Contovounesios <contovob@tcd.ie>:

> Thanks!  Could the constant's docstring please follow the convention
> described under (info "(elisp) Documentation Tips") of keeping the first
> sentence on a single line?

Certainly -- improvement made and pushed.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

18 juni 2020 kl. 21.35 skrev Drew Adams <drew.adams@oracle.com>:

> But if there are different eyes, screens, whatever,
> would it make sense to use a defvar, or even a defcustom,
> instead of a defconst?  Why decide this definitively
> at design time?  Does it make sense to hard-code it?

Well, it isn't really hard-coded in the sense that it cannot be changed later on, or be turned into a defcustom; both perfectly possible. However, I'd rather not get carried away and add yet another customisable variable before we have more substantial evidence that it would make sense to do so.

RE: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Drew Adams]

> > But if there are different eyes, screens, whatever,
> > would it make sense to use a defvar, or even a defcustom,
> > instead of a defconst?  Why decide this definitively
> > at design time?  Does it make sense to hard-code it?
> 
> Well, it isn't really hard-coded in the sense that it cannot be changed later
> on, or be turned into a defcustom; both perfectly possible. However, I'd
> rather not get carried away and add yet another customisable variable before
> we have more substantial evidence that it would make sense to do so.

A defvar would be fine.  defconst explicitly signals
the intention that neither users nor code should
change the value.  That's the wrong signal, I think.

Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)

[Mattias Engdegård]

18 juni 2020 kl. 22.32 skrev Drew Adams <drew.adams@oracle.com>:

> A defvar would be fine.  defconst explicitly signals
> the intention that neither users nor code should
> change the value.  That's the wrong signal, I think.

We'll have to disagree then -- the amount isn't changed programmatically and not intended to be changed by the user any more than any numeric literal inside a function. Again, this can be changed if it turns out to be useful.