unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattiase@acm.org>
To: Yuri Khan <yuri.v.khan@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)
Date: Thu, 11 Jun 2020 18:15:02 +0200	[thread overview]
Message-ID: <C6328020-026D-4C48-AADB-5C4E35002DBA@acm.org> (raw)
In-Reply-To: <CAP_d_8W6h_naaLc7phSe=RM4ofoOsw8AQosf7=KF9RZWv5yqAg@mail.gmail.com>

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.




  reply	other threads:[~2020-06-11 16:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200610181238.9796.44750@vcs0.savannah.gnu.org>
     [not found] ` <20200610181239.947C4204DF@vcs0.savannah.gnu.org>
2020-06-10 19:20   ` master 68ae6fa: Improved light/dark colour predicate (bug#41544) Stefan Monnier
2020-06-10 19:34     ` Mattias Engdegård
2020-06-10 20:01       ` Stefan Monnier
2020-06-11  5:15     ` Yuri Khan
2020-06-11 16:15       ` Mattias Engdegård [this message]
2020-06-11 19:22         ` Yuri Khan
2020-06-12 15:50           ` Mattias Engdegård
2020-06-12 16:22             ` tomas
2020-06-12 18:36             ` Yuri Khan
2020-06-13 10:55               ` Mattias Engdegård
2020-06-12 19:02             ` Drew Adams
2020-06-12 19:09             ` Stephen Leake
2020-06-18 19:28               ` Mattias Engdegård
2020-06-18 19:35                 ` Drew Adams
2020-06-18 20:04                   ` Mattias Engdegård
2020-06-18 20:32                     ` Drew Adams
2020-06-21  7:51                       ` Mattias Engdegård
2020-06-18 19:40                 ` Basil L. Contovounesios
2020-06-18 19:58                   ` Mattias Engdegård
2020-06-13  4:05             ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C6328020-026D-4C48-AADB-5C4E35002DBA@acm.org \
    --to=mattiase@acm.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=yuri.v.khan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).