matplotlib-devel Mailing List for matplotlib

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
>
>

There is no better way to do this at the moment. There have been talk of
integrating the animation interface into Figure objects so that creating an
animation would be similar to creating any other type of plot, with
references to the animation object stored in the figure like any other
Artist.
The basic rule of thumb is, if you are using a constructor, then assign the
constructed object somewhere!
I hope that clears it up!
Ben Root
On Sun, Dec 28, 2014 at 7:25 AM, Amit Saha <ami...@gm...> wrote:
> Hi all,
>
> I realize that once I create a FuncAnimation object, I must assign it
> to a label to make it persist [1]. Is this going to remain the case in
> the foreseeable future? Is there a better way of doing this now?
>
> Thanks,
> Amit.
>
>
> [1] https://github.com/matplotlib/matplotlib/issues/1656
>
> --
> http://echorand.me
>
>
> ------------------------------------------------------------------------------
> 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
>