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
>

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

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

If working on XKCD style plotting for matplotlib taught me anything, it is
that playing with software in a way that it was not originally designed to
do can lead to some excellent discoveries (bugs) and generate new ideas and
generalisations - not to mention it being a lot of fun!

So, in that vein, I wanted to put together a simple Christmas e-card using
matplotlib. My main aim was to re-purpose some of the familiar matplotlib
functionality to generate a simple festive animation.

I decided to go for a snowy scene, with a snow-capped greeting and sprig of
holly. The snow is simply a scatter plot scaled by flake size and animated
to fall in a pleasing way. The text is making use of the path effects
functionality extended in v1.4 to add randomised "snow" around the text
(the same effect employed by XKCD as it happens). And the holly is a nice
demonstration of the power of Paths and vector rendering in matplotlib.

The source can be found at
https://gist.github.com/pelson/ca795a02a420a1b9bfbc, and it requires
matplotlib >= v1.4.

If you're impatient and don't want to run the code (don't do it), the
animation is available on YouTube at
https://www.youtube.com/watch?v=POnAkPpe770.

Finally, to all those taking some time off this festive season, I wish you
a very happy holiday and wish you all the best for the new year.

Phil Elson

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

P.S. I just found
http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker

On 22 December 2014 at 11:21, Phil Elson <pel...@gm...> wrote:

> Thanks for all the contributions so far. Looks like matplotlib is blessed
> with people who are far more knowledgeable than I on the subject, and I'd
> say we were pretty much at a consensus on requirements.
>
> Given these requirements, what we need is some proposed colormaps - Max's
> approach of generating an optimal solution in LAB space sounds interesting,
> as do the other approaches of minimising some parameters of existing
> colormaps.
>
> To facilitate this discussion, do we need a repository of proposed
> colormaps so that we can compare like with like? I notice that Mike Bostock
> has an interesting post to show various color spaces in d3.js which may be
> of interest http://bl.ocks.org/mbostock/3014589.
>
>
>
> On 4 December 2014 at 14:38, Maximilian Albert <
> max...@gm...> wrote:
>
>> Hi all,
>>
>> I had a discussion with Phil Elson about this last weekend during the
>> Bloomberg Open Source Day. I don't consider myself an expert on colormaps
>> by any means, but I started digging into them a while ago when I was
>> looking for a way of generating a perceptually linear *cyclic* colormap in
>> order to represent phase angle values. (I've been meaning to discuss this
>> issue on this list for a while but will do so in a different thread once I
>> get around to tidying up my results so far.) Phil encouraged me to reply to
>> this thread because he said that even non-expert views would be very
>> welcome, so here you go.
>>
>> Basically, I agree with most of what Nathaniel Smith suggested in his
>> email from November 21. I'm going to comment on some of his points inline
>> below and will finally suggest a way of designing a new colormap at the end.
>>
>>
>> Nathaniel Smith wrote:
>>
>> > it should be a sequential colormap [...]
>>
>> Agreed.
>>
>> > it should be perceptually uniform
>>
>> Agreed.
>>
>> > 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].
>>
>> I haven't had time to check this out in detail yet, but it looks pretty
>> interesting and will certainly be very useful to assess the quality of any
>> suggestions. However, can this help to actually *design* a new colormap?
>> The answer might be hidden in the referenced paper [Luo2006], but I haven't
>> read it yet.
>>
>> > or just using good-old-L*a*b* is a reasonable quick-and-dirty
>> approximation.
>>
>> Can you elaborate how "dirty" you think using L*a*b* would be? (See my
>> suggestion for finding a new colormap below.)
>>
>> >- it should have a perceptually uniform luminance ramp, i.e. if you
>> > convert to greyscale it should still be uniform.
>>
>> Agreed. What's unclear to me is how large this luminance ramp should be.
>> We certainly can't go all the way to full luminance because this won't be
>> visible on a white background. This probably needs experimenting (again see
>> below).
>>
>> > - 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.
>>
>> Agreed.
>>
>> > - 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.)
>>
>> Agreed. Are you aware of any simple ways of avoiding the most common
>> issues? Are there any blog posts or papers on designing colormaps that are
>> suitable for colorblind people?
>>
>> > 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.)
>>
>> Just out of interest, is there currently an easy way in matplotlib of
>> producing a 3d plot where luminance is used for lighting/shading as you
>> suggest?
>>
>>
>> Now the question is: how do we actually *design* a colormap with these
>> requirements? Leon Krischer's notebook [1] looks totally awesome, but if I
>> understand correctly the optimisation he uses "only" takes care of
>> linearising the luminance value, but this does not necessarily guarantee
>> that the hue values are also linear, right? It also feels somewhat clumsy
>> to me to start out with a colormap that's "wrong" (w.r.t. our requirements
>> above) and then "fix" it. However, the notebook looks like a great guidance
>> for finding suitable candidates and assessing their quality.
>>
>> It appears to me that a simple yet effective way of coming up with a good
>> colormap would be to pick two points in the L*a*b* color space that can be
>> represented by RGB values, connect them by a line and use the interpolated
>> values for the resulting colormap. Since L*a*b* space is (close to)
>> perceptually linear, this would pretty much guarantee all the requirements
>> above.
>>
>> What's missing is an easy way of doing this. I'm envisaging a simply GUI
>> which allows the user to easily pick two points in L*a*b* space, generates
>> a colormap from them as described above and also generates a few sample
>> plots to evaluate the quality of the colormap (along the lines of [1] or
>> the numerous blog posts linked to in the discussion). I am close to having
>> a prototype for such a GUI which should allow to do this relatively
>> painlessly. I'll try to finish it up over the weekend and will post here
>> once it's ready. Btw, if anyone has suggestions for sample datasets that
>> can help in assessing the quality of colormaps they would be much
>> appreciated.
>>
>> Any comments or clarifications of points that I misunderstood are very
>> welcome.
>>
>> Best wishes,
>> Max
>>
>> [1] http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Thanks for all the contributions so far. Looks like matplotlib is blessed
with people who are far more knowledgeable than I on the subject, and I'd
say we were pretty much at a consensus on requirements.

Given these requirements, what we need is some proposed colormaps - Max's
approach of generating an optimal solution in LAB space sounds interesting,
as do the other approaches of minimising some parameters of existing
colormaps.

To facilitate this discussion, do we need a repository of proposed
colormaps so that we can compare like with like? I notice that Mike Bostock
has an interesting post to show various color spaces in d3.js which may be
of interest http://bl.ocks.org/mbostock/3014589.



On 4 December 2014 at 14:38, Maximilian Albert <max...@gm...>
wrote:

> Hi all,
>
> I had a discussion with Phil Elson about this last weekend during the
> Bloomberg Open Source Day. I don't consider myself an expert on colormaps
> by any means, but I started digging into them a while ago when I was
> looking for a way of generating a perceptually linear *cyclic* colormap in
> order to represent phase angle values. (I've been meaning to discuss this
> issue on this list for a while but will do so in a different thread once I
> get around to tidying up my results so far.) Phil encouraged me to reply to
> this thread because he said that even non-expert views would be very
> welcome, so here you go.
>
> Basically, I agree with most of what Nathaniel Smith suggested in his
> email from November 21. I'm going to comment on some of his points inline
> below and will finally suggest a way of designing a new colormap at the end.
>
>
> Nathaniel Smith wrote:
>
> > it should be a sequential colormap [...]
>
> Agreed.
>
> > it should be perceptually uniform
>
> Agreed.
>
> > 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].
>
> I haven't had time to check this out in detail yet, but it looks pretty
> interesting and will certainly be very useful to assess the quality of any
> suggestions. However, can this help to actually *design* a new colormap?
> The answer might be hidden in the referenced paper [Luo2006], but I haven't
> read it yet.
>
> > or just using good-old-L*a*b* is a reasonable quick-and-dirty
> approximation.
>
> Can you elaborate how "dirty" you think using L*a*b* would be? (See my
> suggestion for finding a new colormap below.)
>
> >- it should have a perceptually uniform luminance ramp, i.e. if you
> > convert to greyscale it should still be uniform.
>
> Agreed. What's unclear to me is how large this luminance ramp should be.
> We certainly can't go all the way to full luminance because this won't be
> visible on a white background. This probably needs experimenting (again see
> below).
>
> > - 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.
>
> Agreed.
>
> > - 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.)
>
> Agreed. Are you aware of any simple ways of avoiding the most common
> issues? Are there any blog posts or papers on designing colormaps that are
> suitable for colorblind people?
>
> > 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.)
>
> Just out of interest, is there currently an easy way in matplotlib of
> producing a 3d plot where luminance is used for lighting/shading as you
> suggest?
>
>
> Now the question is: how do we actually *design* a colormap with these
> requirements? Leon Krischer's notebook [1] looks totally awesome, but if I
> understand correctly the optimisation he uses "only" takes care of
> linearising the luminance value, but this does not necessarily guarantee
> that the hue values are also linear, right? It also feels somewhat clumsy
> to me to start out with a colormap that's "wrong" (w.r.t. our requirements
> above) and then "fix" it. However, the notebook looks like a great guidance
> for finding suitable candidates and assessing their quality.
>
> It appears to me that a simple yet effective way of coming up with a good
> colormap would be to pick two points in the L*a*b* color space that can be
> represented by RGB values, connect them by a line and use the interpolated
> values for the resulting colormap. Since L*a*b* space is (close to)
> perceptually linear, this would pretty much guarantee all the requirements
> above.
>
> What's missing is an easy way of doing this. I'm envisaging a simply GUI
> which allows the user to easily pick two points in L*a*b* space, generates
> a colormap from them as described above and also generates a few sample
> plots to evaluate the quality of the colormap (along the lines of [1] or
> the numerous blog posts linked to in the discussion). I am close to having
> a prototype for such a GUI which should allow to do this relatively
> painlessly. I'll try to finish it up over the weekend and will post here
> once it's ready. Btw, if anyone has suggestions for sample datasets that
> can help in assessing the quality of colormaps they would be much
> appreciated.
>
> Any comments or clarifications of points that I misunderstood are very
> welcome.
>
> Best wishes,
> Max
>
> [1] http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Amit,

Thanks for your bug report and your PR for fixing the bug. I haven't had
time to look over it yet, and I won't have the ability to review it for the
upcoming week (in fact, I will be without internet connection). If no one
gets around to reviewing it in the next week due to the holiday season,
then just make sure you ping us again to remind us.

Cheers!
Ben Root


On Sat, Dec 20, 2014 at 9:02 PM, Amit Saha <ami...@gm...> wrote:

> Hi all,
>
> I submitted a PR yesterday:
> https://github.com/matplotlib/matplotlib/pull/3936 to add
> autoscale_view() in the add_patch() method.  This aims to fix:
> https://github.com/amitsaha/matplotlib/tree/issue3934
>
> I am very much a matplotlib user, so if the PR doesn't look right, I
> am willing to work on it so as to fix the issue with help.
>
> Thanks,
> Amit.
>
>
> --
> http://echorand.me
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,

I submitted a PR yesterday:
https://github.com/matplotlib/matplotlib/pull/3936 to add
autoscale_view() in the add_patch() method.  This aims to fix:
https://github.com/amitsaha/matplotlib/tree/issue3934

I am very much a matplotlib user, so if the PR doesn't look right, I
am willing to work on it so as to fix the issue with help.

Thanks,
Amit.


-- 
http://echorand.me

For Q and A no. But it's great for announcements, links to example of upcoming or new features, etc. 

—
Sent from Mailbox

On Sat, Dec 20, 2014 at 2:11 PM, Eric Firing <ef...@ha...> wrote:

> On 2014/12/20, 10:45 AM, Thomas Caswell wrote:
>> We have a Twitter account?!?
> It's news to me, too.  Maybe it was started by someone not closely 
> connected with matplotlib.  I've never paid any attention to twitter, 
> and don't expect to in the future.  If I had any control over it, I 
> would oppose any matplotlib presence on twitter.  It's not a suitable 
> medium for software-related Q&A.
> Eric
>>
>> On Fri, Dec 19, 2014, 20:05 Benjamin Root <ben...@ou...
>> <mailto:ben...@ou...>> wrote:
>>
>>     I just realized today that people have been posting questions to a
>>     matplotlib handle on twitter, but it hasn't posted any tweets since
>>     April.
>>
>>     Same issue for numpy as well, it seems.
>>
>>     Ben Root
>>
>>     ------------------------------__------------------------------__------------------
>>     Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>     from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>     with Interactivity, Sharing, Native Excel Exports, App Integration &
>>     more
>>     Get technology previously reserved for billion-dollar corporations, FREE
>>     http://pubads.g.doubleclick.__net/gampad/clk?id=164703151&__iu=/4140/ostg.clktrk
>>     <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk>_________________________________________________
>>     Matplotlib-devel mailing list
>>     Matplotlib-devel@lists.__sourceforge.net
>>     <mailto:Mat...@li...>
>>     https://lists.sourceforge.net/__lists/listinfo/matplotlib-__devel
>>     <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 2014/12/20, 10:45 AM, Thomas Caswell wrote:
> We have a Twitter account?!?

It's news to me, too.  Maybe it was started by someone not closely 
connected with matplotlib.  I've never paid any attention to twitter, 
and don't expect to in the future.  If I had any control over it, I 
would oppose any matplotlib presence on twitter.  It's not a suitable 
medium for software-related Q&A.

Eric

>
> On Fri, Dec 19, 2014, 20:05 Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>     I just realized today that people have been posting questions to a
>     matplotlib handle on twitter, but it hasn't posted any tweets since
>     April.
>
>     Same issue for numpy as well, it seems.
>
>     Ben Root
>
>     ------------------------------__------------------------------__------------------
>     Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>     from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>     with Interactivity, Sharing, Native Excel Exports, App Integration &
>     more
>     Get technology previously reserved for billion-dollar corporations, FREE
>     http://pubads.g.doubleclick.__net/gampad/clk?id=164703151&__iu=/4140/ostg.clktrk
>     <http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk>_________________________________________________
>     Matplotlib-devel mailing list
>     Matplotlib-devel@lists.__sourceforge.net
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/__lists/listinfo/matplotlib-__devel
>     <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

We have a Twitter account?!?

On Fri, Dec 19, 2014, 20:05 Benjamin Root <ben...@ou...> wrote:

> I just realized today that people have been posting questions to a
> matplotlib handle on twitter, but it hasn't posted any tweets since April.
>
> Same issue for numpy as well, it seems.
>
> Ben Root
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I just realized today that people have been posting questions to a
matplotlib handle on twitter, but it hasn't posted any tweets since April.

Same issue for numpy as well, it seems.

Ben Root

Hi,

On Tue, Oct 28, 2014 at 12:15 PM, Benjamin Root <ben...@ou...> wrote:
> Yeah, put together a PR, and we can evaluate it better that way. I think the
> current plot directive behavior might need this sort of tightening up

Thanks for the feedback, sorry for the delay:

https://github.com/matplotlib/matplotlib/pull/3916

Cheers,

Matthew

great! eventually I can "use" Eric as a beta tester :)

On Wed, Dec 10, 2014 at 8:11 PM, Benjamin Root <ben...@ou...> wrote:
> https://github.com/matplotlib/basemap
>
> You can follow the same guide for matplotlib (but I suspect Jeff Whittaker
> has been looser with handling it). Many of the safety checks we have in mpl
> are not in basemap like the PEP8 checking, I think.
>
> Cheers!
> Ben Root
>
>
> On Wed, Dec 10, 2014 at 1:41 PM, Sandro Tosi <mo...@de...> wrote:
>>
>> hey! well, eventually in the holiday break I could give them a look,
>> can you point a the bugs list? is there a devel guide for basemap in
>> particular or the mpl one should be followed?
>>
>> Cheers,
>> Sandro
>>
>> On Wed, Dec 10, 2014 at 6:01 PM, Benjamin Root <ben...@ou...> wrote:
>> > I just noticed that the last update to basemap's master branch was March
>> > 31st, but there are bug reports piling up, so people are still
>> > interested in
>> > at least seeing it still supported. Perhaps some of us should make a
>> > concerted effort to address some of its bug reports?
>> >
>> > Cheers!
>> > Ben Root
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>> > more
>> > Get technology previously reserved for billion-dollar corporations, FREE
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>>
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>
>



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

https://github.com/matplotlib/basemap

You can follow the same guide for matplotlib (but I suspect Jeff Whittaker
has been looser with handling it). Many of the safety checks we have in mpl
are not in basemap like the PEP8 checking, I think.

Cheers!
Ben Root


On Wed, Dec 10, 2014 at 1:41 PM, Sandro Tosi <mo...@de...> wrote:

> hey! well, eventually in the holiday break I could give them a look,
> can you point a the bugs list? is there a devel guide for basemap in
> particular or the mpl one should be followed?
>
> Cheers,
> Sandro
>
> On Wed, Dec 10, 2014 at 6:01 PM, Benjamin Root <ben...@ou...> wrote:
> > I just noticed that the last update to basemap's master branch was March
> > 31st, but there are bug reports piling up, so people are still
> interested in
> > at least seeing it still supported. Perhaps some of us should make a
> > concerted effort to address some of its bug reports?
> >
> > Cheers!
> > Ben Root
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

hey! well, eventually in the holiday break I could give them a look,
can you point a the bugs list? is there a devel guide for basemap in
particular or the mpl one should be followed?

Cheers,
Sandro

On Wed, Dec 10, 2014 at 6:01 PM, Benjamin Root <ben...@ou...> wrote:
> I just noticed that the last update to basemap's master branch was March
> 31st, but there are bug reports piling up, so people are still interested in
> at least seeing it still supported. Perhaps some of us should make a
> concerted effort to address some of its bug reports?
>
> Cheers!
> Ben Root
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 2014/12/10, 8:01 AM, Benjamin Root wrote:
> I just noticed that the last update to basemap's master branch was March
> 31st, but there are bug reports piling up, so people are still
> interested in at least seeing it still supported. Perhaps some of us
> should make a concerted effort to address some of its bug reports?
>
> Cheers!
> Ben Root


Good idea, thanks for pointing this out.  I rely on it heavily, and 
expect to continue to do so for a long time.  Unfortunately, I don't 
expect to have much (any?) time to work on it.

Eric

I just noticed that the last update to basemap's master branch was March
31st, but there are bug reports piling up, so people are still interested
in at least seeing it still supported. Perhaps some of us should make a
concerted effort to address some of its bug reports?

Cheers!
Ben Root

Hi Benjamin and others:
Thx for your comments.  I've tried to follow your recommendations and simplify the code:http://pastebin.com/JHhkcCzt

Prior to these modifications I would at least see my axes render on the gridLayout object, but now that doesn't populate.  
Here's my attempt to talk through what I think is happening:LINE 9: I import the FigureCanvasQTAgg class.  A figureCanvas is an object on which we can attach figures, and subsequently axes and plots.  I guess since I want to embed this figureCanvas into a pyqt4 GUI, I'm importing a special type of figureCanvas from the backend_qtAgg library to do this??  Not sure if that's the case.
LINE 24: I want to create a FigureCanvas object called thePlot on which I will create a simple line plot.  It seems that in order to instantiate this new object, I need to pass a Figure object so I use LINE 24 to do that.  
LINE 25:  In this line I create a a FigureCanvas object called thePlot and pass the Figure I created in LINE 24.
LINE 26: My objective is to attached this plot to a pyqt4 GUI.  I've created a gridLayout on the GUI.  In this line I execute the addWidget method and pass thePlot object as argument.  A FigureCanvas is a QWidget apparently which makes this a reasonable thing to do I guess.... 
LINE 119: I'm now in the pushbutton signal function.  This line sets the parent of thePlot to None.  I have no idea what this does.  This is just something I put in there because I hoped it would help make things work.  Adding it didn't help.
LINE 120: Here I set the variable self.axes equal to the return of the fig function add_subplot.  This is something I just copied from an example.  I understand that add_subplot(111) creates one row and column of figures and selects the first one(from matlab), but I'm not really grasping what's really going on here.  I've followed the declaration of add_subplot and find that the function is return something called a subplot_class_factory.  I don't really know what this is either so I followed this declaration too.  I find that a subplot_class_factory is a function that creates a new class that inherits from SubplotBase.  Again I'm not sure what a subplotbase is and decide to just accept the original statement and hope it works.  Is looking at the declarations a reasonable way to figure out how things work in matplotlib?  I don't know a better strategy.  For somebody with so little experience, it's been very difficult to gain much benefit from.
Line 122: Lastly I attempt to plot.  I saw in an example that the .plot method is available from a subplotbase.  Here I try something very simple, just three numbers.
THE OUTCOME: The axes never rendered and the plot never appeared.  I really don't know why or how to troubleshoot this.  Does anybody have an idea why?
thxMatt

 

     On Friday, December 5, 2014 4:29 PM, Benjamin Root <ben...@ou...> wrote:
   

 I would look at line 24/25. You are constructing a MyStaticMplCanvas instance on 24, with a self.main_widget as the parent. But then on 25, you explicitly call the constructor again (which is not a good idea), but with the main window as the parent (the self argument). I bet that is throwing off a couple things.

The code is extremely hard to follow, and I think it is a bad example to build off of in the first place (unnescessary subclassing). Perhaps a different example would be more suitable? What programming language are you coming from?

Ben Root


On Fri, Dec 5, 2014 at 4:12 PM, Matthew Albert <mat...@ya...> wrote:

I'm sure this is a simple problem, but I've been going around in circles several days trying to figure this out.  
Here's my code.http://pastebin.com/n83dGhG4

Basically, I'm trying to get my pyqt4 button signal to execute the plot command (line 122).  A lot of this code was copied from the matplotlib example page.  If I uncomment line 148, the figure will successfully plot.  I don't understand why what I'm doing on line 122 isn't equivalent to line 148.
thx for your help.Matt
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





   

Paris (U.E.), le 08/12/2014

	The transition to MacOS X 10.10 (and more precisely 10.10.1) is proving quite problematic. One problem I am currently stuck with prevents me from using matplotlib.

	Whether using matplotlib 1.4.2 and freetype 2.3.12 (combination A) or matplotlib 59eda228e6a77e842c63078c3af870868120e70c and freetype 2.5.3 (combination B), importing matplotlib.pylab results in a crash. I have not tried other combinations…

	In the case of combination A, the crash occurs because FT_Set_Char_Size (ft2font.cpp, line 909) returns an error because of the font “/System/Library/Fonts/Apple Color Emoji.ttf” and an uncaught exception is then thrown on line 916.

	In the case of combination B, the crash occurs because FT_Set_Char_Size (ft2font.cpp, line 508) returns an error because of an unidentified font (I could not quickly find a way, in this version of the file, to access the name of the font being tested…) and an uncaught exception is then thrown on line 510.

	As the font “/System/Library/Fonts/Apple Color Emoji.ttf” is a system font, and therefore off-limits to most users, it would be unadvisable to mess with it (including removing it from the system), and even though I would personally be quite unlikely to use it in conjunction with matplotlib, our Japanese colleagues might see things differently. At any rate, it does not seem to be corrupt (it may be complex, though, as TypeTool displays it differently from Font Book, which is hardly surprising as it is a *color* font…).

	Barring a more sophisticated treatment of such fonts, could it be possible to catch the exception, just not take these fonts into account, and move on to the rest of the work? I have not grasped the organisation of the source that well to know where to propose a patch. Any hint welcome!

		Hubert Holin

P.S.: I have also not found a way of creating a figure without having to import matplotlib.pylab.

I would look at line 24/25. You are constructing a MyStaticMplCanvas
instance on 24, with a self.main_widget as the parent. But then on 25, you
explicitly call the constructor again (which is not a good idea), but with
the main window as the parent (the self argument). I bet that is throwing
off a couple things.

The code is extremely hard to follow, and I think it is a bad example to
build off of in the first place (unnescessary subclassing). Perhaps a
different example would be more suitable? What programming language are you
coming from?

Ben Root


On Fri, Dec 5, 2014 at 4:12 PM, Matthew Albert <mat...@ya...>
wrote:

> I'm sure this is a simple problem, but I've been going around in circles
> several days trying to figure this out.
>
> Here's my code.
> http://pastebin.com/n83dGhG4
>
> Basically, I'm trying to get my pyqt4 button signal to execute the plot
> command (line 122).  A lot of this code was copied from the matplotlib
> example page.  If I uncomment line 148, the figure will successfully plot.
> I don't understand why what I'm doing on line 122 isn't equivalent to line
> 148.
>
> thx for your help.
> Matt
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I'm sure this is a simple problem, but I've been going around in circles several days trying to figure this out.  
Here's my code.http://pastebin.com/n83dGhG4

Basically, I'm trying to get my pyqt4 button signal to execute the plot command (line 122).  A lot of this code was copied from the matplotlib example page.  If I uncomment line 148, the figure will successfully plot.  I don't understand why what I'm doing on line 122 isn't equivalent to line 148.
thx for your help.Matt

Hi all,

I had a discussion with Phil Elson about this last weekend during the
Bloomberg Open Source Day. I don't consider myself an expert on colormaps
by any means, but I started digging into them a while ago when I was
looking for a way of generating a perceptually linear *cyclic* colormap in
order to represent phase angle values. (I've been meaning to discuss this
issue on this list for a while but will do so in a different thread once I
get around to tidying up my results so far.) Phil encouraged me to reply to
this thread because he said that even non-expert views would be very
welcome, so here you go.

Basically, I agree with most of what Nathaniel Smith suggested in his email
from November 21. I'm going to comment on some of his points inline below
and will finally suggest a way of designing a new colormap at the end.


Nathaniel Smith wrote:

> it should be a sequential colormap [...]

Agreed.

> it should be perceptually uniform

Agreed.

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

I haven't had time to check this out in detail yet, but it looks pretty
interesting and will certainly be very useful to assess the quality of any
suggestions. However, can this help to actually *design* a new colormap?
The answer might be hidden in the referenced paper [Luo2006], but I haven't
read it yet.

> or just using good-old-L*a*b* is a reasonable quick-and-dirty
approximation.

Can you elaborate how "dirty" you think using L*a*b* would be? (See my
suggestion for finding a new colormap below.)

>- it should have a perceptually uniform luminance ramp, i.e. if you
> convert to greyscale it should still be uniform.

Agreed. What's unclear to me is how large this luminance ramp should be. We
certainly can't go all the way to full luminance because this won't be
visible on a white background. This probably needs experimenting (again see
below).

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

Agreed.

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

Agreed. Are you aware of any simple ways of avoiding the most common
issues? Are there any blog posts or papers on designing colormaps that are
suitable for colorblind people?

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

Just out of interest, is there currently an easy way in matplotlib of
producing a 3d plot where luminance is used for lighting/shading as you
suggest?


Now the question is: how do we actually *design* a colormap with these
requirements? Leon Krischer's notebook [1] looks totally awesome, but if I
understand correctly the optimisation he uses "only" takes care of
linearising the luminance value, but this does not necessarily guarantee
that the hue values are also linear, right? It also feels somewhat clumsy
to me to start out with a colormap that's "wrong" (w.r.t. our requirements
above) and then "fix" it. However, the notebook looks like a great guidance
for finding suitable candidates and assessing their quality.

It appears to me that a simple yet effective way of coming up with a good
colormap would be to pick two points in the L*a*b* color space that can be
represented by RGB values, connect them by a line and use the interpolated
values for the resulting colormap. Since L*a*b* space is (close to)
perceptually linear, this would pretty much guarantee all the requirements
above.

What's missing is an easy way of doing this. I'm envisaging a simply GUI
which allows the user to easily pick two points in L*a*b* space, generates
a colormap from them as described above and also generates a few sample
plots to evaluate the quality of the colormap (along the lines of [1] or
the numerous blog posts linked to in the discussion). I am close to having
a prototype for such a GUI which should allow to do this relatively
painlessly. I'll try to finish it up over the weekend and will post here
once it's ready. Btw, if anyone has suggestions for sample datasets that
can help in assessing the quality of colormaps they would be much
appreciated.

Any comments or clarifications of points that I misunderstood are very
welcome.

Best wishes,
Max

[1] http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5