[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544)
From: |
Mattias Engdegård |
Subject: |
Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544) |
Date: |
Thu, 11 Jun 2020 18:15:02 +0200 |
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), Stefan Monnier, 2020/06/10
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Mattias Engdegård, 2020/06/10
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Yuri Khan, 2020/06/11
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544),
Mattias Engdegård <=
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Yuri Khan, 2020/06/11
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Mattias Engdegård, 2020/06/12
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), tomas, 2020/06/12
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Yuri Khan, 2020/06/12
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Mattias Engdegård, 2020/06/13
- RE: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Drew Adams, 2020/06/12
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Stephen Leake, 2020/06/12
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Mattias Engdegård, 2020/06/18
- RE: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Drew Adams, 2020/06/18
- Re: master 68ae6fa: Improved light/dark colour predicate (bug#41544), Mattias Engdegård, 2020/06/18