matplotlib-devel Mailing List for matplotlib

On Fri, Nov 21, 2014 at 10:53 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年11月21日, 4:42 PM, Nathaniel Smith wrote:
>> On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale <dsd...@gm...> wrote:
>>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...> wrote:
>>>>
>>>> Please use this thread to discuss the best choice for a new default
>>>> matplotlib colormap.
>>>>
>>>> This follows on from a discussion on the matplotlib-devel mailing list
>>>> entitled "How to move beyond JET as the default matplotlib colormap".
>>>
>>>
>>> I remember reading a (peer-reviewed, I think) article about how "jet" was a
>>> very unfortunate choice of default. I can't find the exact article now, but
>>> I did find some other useful ones:
>>>
>>> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
>>> http://www.sandia.gov/~kmorel/documents/ColorMaps/
>>> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
>>
>> Those are good articles. There's a lot of literature on the problems
>> with "jet", and lots of links in the matplotlib issue [1]. For those
>> trying to get up to speed quickly, MathWorks recently put together a
>> nice review of the literature [2]. One particularly striking paper
>> they cite studied a group of medical students and found that (a) they
>> were used to/practiced at using jet, (b) when given a choice of
>> colormaps they said that they preferred jet, (c) they nonetheless made
>> more *medical diagnostic errors* when using jet than with better
>> designed colormaps (Borkin et al, 2011).
>>
>> I won't suggest a specific colormap, but I do propose that whatever we
>> chose satisfy the following criteria:
>>
>> - it should be a sequential colormap, because diverging colormaps are
>> really misleading unless you know where the "center" of the data is,
>> and for a default colormap we generally won't.
>>
>> - it should be perceptually uniform, i.e., human subjective judgements
>> of how far apart nearby colors are should correspond as linearly as
>> possible to the difference between the numerical values they
>> represent, at least locally. There's lots of research on how to
>> measure perceptual distance -- a colleague and I happen to have
>> recently implemented a state-of-the-art model of this for another
>> project, in case anyone wants to play with it [3], or just using
>> good-old-L*a*b* is a reasonable quick-and-dirty approximation.
>>
>> - it should have a perceptually uniform luminance ramp, i.e. if you
>> convert to greyscale it should still be uniform. This is useful both
>> in practical terms (greyscale printers are still a thing!) and because
>> luminance is a very strong and natural cue to magnitude.
>>
>> - it should also have some kind of variation in hue, because hue
>> variation is a really helpful additional cue to perception, having two
>> cues is better than one, and there's no reason not to do it.
>>
>> - the hue variation should be chosen to produce reasonable results
>> even for viewers with the more common types of colorblindness. (Which
>> rules out things like red-to-green.)
>>
>> And, for bonus points, it would be nice to choose a hue ramp that
>> still works if you throw away the luminance variation, because then we
>> could use the version with varying luminance for 2d plots, and the
>> version with just hue variation for 3d plots. (In 3d plots you really
>> want to reserve the luminance channel for lighting/shading, because
>> your brain is *really* good at extracting 3d shape from luminance
>> variation. If the 3d surface itself has massively varying luminance
>> then this screws up the ability to see shape.)
>>
>> Do these seem like good requirements?
>
> Goals, yes, though I wouldn't put much weight on the "bonus" criterion.
> I would add that it should be aesthetically pleasing, or at least
> comfortable, to most people. Perfection might not be attainable, and
> some tradeoffs may be required. Is anyone set up to produce test images
> and/or metrics for judging existing colormaps, or newly designed ones,
> on all of these criteria?
I had some time on a plane today, so I wrote a little script for
visualizing colormaps (esp. WRT perceptual uniformity and
colorblindness). To try it:
$ git clone https://github.com/njsmith/pycam02ucs.git
$ cd pycam02ucs
$ ipython
In [1]: %matplotlib
In [2]: from pycam02ucs.viscm import viscm
In [3]: viscm("jet")
(Or substitute your favorite built-in colormap, or pass a matplotlib
colormap object, i.e. a callable that takes an array of values in the
range [0, 1] and returns an array of RGBA values with shape (n, 4).)
I'm attaching an example, plus an annotated example explaining what
the different bits show.
It's a bit crude, but has definitely reached the
fun-to-play-around-with stage :-). If anyone makes improvements send
me a PR!
Hidden feature: you can pass show_gamut=True to get a crude
approximation of the space of possible sRGB colors drawn onto the 3d
plot at the bottom. The idea is if trying to design a better colormap
it's useful to have a sense of what potential colors are available to
use. It's pretty crude and somewhat distracting though so I left it
off by default for now.
-n
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org