Re: [matplotlib-devel] Matplotlib's new default colormap

[Benjamin R. <ben...@ou...>]

Neat stuff! Just a quick note about the 3D plot. By default, the scatter
markers are shaded to give an illusion of depth. This is often what we
want, but I think in this case, it might make sense to not do that. Add
depthshade=False to the scatter call to turn it off. I think that was added
for mpl version 1.3.

Ben Root

On Tue, Dec 23, 2014 at 4:16 AM, Nathaniel Smith <nj...@po...> wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>