Re: Colour manipulation

[Julien Danjou <julien@danjou.info>]

On Tue, Nov 23 2010, Ted Zlatanov wrote:

> BTW, the source code for color-lab.el is beautiful.  I like to see
> Unicode used properly like this, in code and identifiers.  I am
> surprised and glad that Emacs is happy with it all.

It works perfectly, and I'm even happier than you can imagine, because
using Unicode symbols is just easier when you re-read your work with
some math paper on your side. Reading things like DeltaLPrime just makes
things harder for your brain. :)

> I'm not personally colorblind, just interested in helping people with
> that disability.  So I can't test things too much without a conversion
> tool.  Still, it seems that color-lab.el will quickly become the
> standard place for color formulas in Emacs so I think we should
> anticipate this common need instead of fixing it later.

I agree. :)

> I posted a link to the color designer page at
> http://colorschemedesigner.com that lets you see any colors as a
> colorblind person would.  The source code is JavaScript and probably
> easy to obtain.  That kind of conversion tool is valuable.  Here are
> some more links:
>
> http://jfly.iam.u-tokyo.ac.jp/color/
> http://www.vischeck.com/info/ (LOTS of good links, check out Daltonize too)
>
> Vischeck came from open-source software and they may be willing to
> license their algorithm to the FSF.

That would be great. I don't think we even need the whole algorithm
because they are using S-CIELAB on images, something we can't do (but we
should to do better processing!). So even without the S-CIELAB part, but
with some color substitution algorithm we could do some good job.

> I would recommend to let users customize a color vision profile as part
> of color-lab (see my original long explanation of my work with colors in
> GUI design).  Maybe just a list of colors and their contrasting pairs
> (with a reasonable set of defaults for each of the various kinds of
> colorblindness), from which we can approximate what will look good
> anywhere in the colorspace, will be sufficient.  The algorithms are nice
> to have but not essential to the original requirement.

That sounds like an option indeed. I'll probably use that if I can't do
something better.

Now, what I have in mind…

I think the only colour blindness types we should consider are all forms
of dichromacy. In that case, since we use RGB (hehe), dropping one of
the 3 components (depending of the dichromacy type) and using the same
computing could work.

If I simulate protanopia with the following code and then correct it,
this is what I got:

--8<---------------cut here---------------start------------->8---
 (let* ((fg "#ffaabb")
        (bg "#aaffbb")
        (fg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values fg)))
        (bg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values bg))))
   (shr-color-check
    ;; No red color blindness
    (apply 'format "#00%02X%02X" (cdr fg-cb))
    (apply 'format "#00%02X%02X" (cdr bg-cb))))

==> ("#3effce" "#0096a6")
--8<---------------cut here---------------end--------------->8---

I simulate it by setting red to 0, and let the code correct the color.
It generates 2 new colors: #3effce #0096a6, which are 2 different blues.
Even #3effce without the red component (#00ffce) seems visible.

If I use 2 different reds like #ff0000 and #bb0000 it generates black
and grey: #000000 and #5e5e5e. The grey is probably viewed as #005e5e
which is some green-blue, and should be visible.

This is probably not perfect, but is this good enough? Any color blind
people in there? :)

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info