matplotlib-devel Mailing List for matplotlib (Page 2)

I don't have a mac to double-check, but reading through the
backend_cocoaagg.py, I don't see any creation of a navigation toolbar? Is
this assumption right?
Thanks!
Ben Root

Actually, I think I found it. It looks like each backend defines a
new_figure_manager() function. Then, in backends/__init__.py, not only do
the aliased FigureManager and FigureCanvas objects get imported from the
appropriate module, but so does that function. It is pylab_setup() in the
backends/__init__.py that creates the canvas object, it seems?
I guess this is one of those remaining issues that is keeping us from fully
separating pyplot from the rest of matplotlib?
Cheers!
Ben Root
On Sat, Nov 22, 2014 at 4:30 PM, Benjamin Root <ben...@ou...> wrote:
> I thought I had this understood, but now I am confused while working on my
> last chapter. I know that the Figure object never directly creates its own
> canvas object. It starts off with a None object as a placeholder and waits
> for one to be given to it. However, I can only find one place where the
> figure object's set_canvas() method is called, and that is in the canvas's
> print_figure() method to restore itself as the figure's canvas after
> temporaraily switching to another backend for saving.
>
> I thought that the FigureManager initializes the primary canvas object,
> but that doesn't seem to be the case. Where is it done?
>
> Cheers!
> Ben Root
>

I thought I had this understood, but now I am confused while working on my
last chapter. I know that the Figure object never directly creates its own
canvas object. It starts off with a None object as a placeholder and waits
for one to be given to it. However, I can only find one place where the
figure object's set_canvas() method is called, and that is in the canvas's
print_figure() method to restore itself as the figure's canvas after
temporaraily switching to another backend for saving.
I thought that the FigureManager initializes the primary canvas object, but
that doesn't seem to be the case. Where is it done?
Cheers!
Ben Root

The contents of that talk are also in our documentation
http://matplotlib.org/users/colormaps.html
Tom
On Sat Nov 22 2014 at 9:33:11 AM gary ruben <gar...@gm...> wrote:
> There was a talk by Kristen Thyng at scipy2014 that might be a good
> backgrounder for this:
> http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps
>
> At the end she references this site http://mycarta.wordpress.com/ of
> Matteo Niccoli which is full of good content. I wonder if it's worth
> contacting Kristen or Matteo to let them know there's a discussion going on
> here that they might be interested in?
>
>
> On 22 November 2014 at 09:53, 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?
>>
>> Eric
>>
>> >
>> > -n
>> >
>> > [1] https://github.com/matplotlib/matplotlib/issues/875
>> > [2]
>> http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
>> > [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
>> > of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
>> > the perceptual distance between two RGB colors. It's also possible to
>> > use the underlying color model stuff to do things like generate colors
>> > with evenly spaced luminance and hues, or draw 3d plots of the shape
>> > of the human color space. It's pretty fun to play with :-)
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=157005751&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=157005751&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

There was a talk by Kristen Thyng at scipy2014 that might be a good
backgrounder for this:
http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps
At the end she references this site http://mycarta.wordpress.com/ of Matteo
Niccoli which is full of good content. I wonder if it's worth contacting
Kristen or Matteo to let them know there's a discussion going on here that
they might be interested in?
On 22 November 2014 at 09:53, 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?
>
> Eric
>
> >
> > -n
> >
> > [1] https://github.com/matplotlib/matplotlib/issues/875
> > [2]
> http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
> > [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
> > of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
> > the perceptual distance between two RGB colors. It's also possible to
> > use the underlying color model stuff to do things like generate colors
> > with evenly spaced luminance and hues, or draw 3d plots of the shape
> > of the human color space. It's pretty fun to play with :-)
> >
>
>
>
> ------------------------------------------------------------------------------
> 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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

We now have the style system in-place. I envision the 1.5 release as having
the attempt at encoding the current visual style as "classic" (which would
be default), and to put together a "bleeding" (or "trendy" or "hipster")
style that would encode many of the proposed changes to the defaults. Come
mpl2.0, any remaining bugs in the style system should be ironed out, and we
can canonicalize the "hipster" style into a "stable" style. We can even
then utilize "hipster" as a playground of sorts to get feedback on proposed
changes that would work their way into "stable". Each release could also
alias "stable" with a "mplX.Y" style. Another reason why I like this
approach is that it gives us a way to explicitly deprecate various styles
(with warnings and user notes) if an older style becomes a maintenance
burden as matplotlib evolves.
I am also liking the argument that mpl2.0 should be focused on just visual
changes. And logically organized styles will provide users with the needed
"out" to hang onto most of the old visual styles (they would just need to
add a single line to their programs or maybe a config file somewhere).
I am still not convinced that all of the CXX/AGG issues have been ironed
out. While nominal situations seems to have been fairly straight-forward, I
am concerned about error-handling in the interactive backends. As I have
already discovered, the change did introduce a segfaulting error handling
path that merely errored out previously (seems to be fixed now with the
copy constructor fix). These sorts of things aren't covered by our test
suite and can be very backend-dependent.
Cheers!
Ben Root
On Sat, Nov 22, 2014 at 5:16 AM, Phil Elson <pel...@gm...> wrote:
> Given the workload that making a release causes, is it necessary to put
> out a v1.4.3 at all? On a similar sounding argument, given that the removal
> of CXX doesn't break user APIs, and has been on master for several weeks
> with fewer than anticipated side-effects, do we even need a v1.5?
> Essentially, what is the barrier from moving straight to a v2.0 in Feb?
>
> What I'd like to avoid is this idea of "we're talking about a making a
> major release so let's fix everything that was ever broken" - my definition
> of a v2.0 release is really just v1.5+new default cmap. If there are other
> things that need fixing in a backwards incompatible way then we should
> discuss and plan how we are going to do that, and if there is developer
> appetite, there is no reason not to talk about releasing a v3.0 in 18-24
> months (which is currently ~2 mpl minor release cycles).
>
>
> On 21 November 2014 18:56, Thomas Caswell <tca...@gm...> wrote:
>
>> I am a bit wary of doing a 2.0 _just_ to change the color map, but when
>> every I try to write out why, they don't sound convincing. We may end up
>> with a 3.0 within a year or so due to the possible plotting API/pyplot work
>> that is (hopefully) coming.
>>
>> If we are going to do this, I think we should do the 1.4.3 release
>> (scheduled for Feb 1, RCs in mid January), then put one commit to change
>> the color map on top of that, tag 2.0 and then master turns into 2.1.x
>> (targeted for right after scipy?).
>>
>> There is also the thought to get the major c++ refactor work tagged and
>> released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
>> 2.0 in Feb with 2.0 based off of 1.5 not 1.4.
>>
>> On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben...@ou...> wrote:
>>
>>> As a point of clarification, is this proposed 2.0 release different from
>>> the 1.5 release?
>>>
>>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
>>> wrote:
>>>
>>>> Many of you will be aware of there has been an ongoing issue (#875,
>>>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the
>>>> default colormap in matplotlib.
>>>>
>>>> The argument against Jet is compelling and I think that as a group who
>>>> care about high quality visualisation we should be seriously discussing how
>>>> matplotlib can move beyond Jet.
>>>>
>>>> There was recently an open letter to the climate science community
>>>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking
>>>> for scientists to "pledge" against using rainbow like colormaps (such as
>>>> Jet), and there are similar initiatives in other scientific fields, as well
>>>> as there being a plethora of well researched literature on the subject.
>>>>
>>>> As such, it's time to agree on a solution on how matplotlib can reach
>>>> the end of the rainbow.
>>>>
>>>>
>>>> The two major hurdles, AFAICS, to replacing the three little characters
>>>> which control the default colormap of matplotlib are:
>>>>
>>>> * We haven't had a clear (decisive) discussion about what we should
>>>> replace Jet with.
>>>> * There are concerns about changing the default as it would change the
>>>> existing widespread behaviour.
>>>>
>>>> To address the first point I'll start a new mailinglist thread
>>>> (entitled "Matplotlib's new default colormap") where new default colormap
>>>> suggestions can be made. The thread should strictly avoid "+1" type
>>>> comments, and generally try to stick to reference-able/demonstrable fact,
>>>> rather than opinion. There *will* be a difference of opinion, however
>>>> the final decision has to come down to the project lead (sorry Mike) who I
>>>> know will do whatever is necessary to make the best choice for matplotlib.
>>>>
>>>> The second point is a reasonable response when we consider that
>>>> matplotlib as a project has no *clear* statement on backwards
>>>> compatibility. As a result, matplotlib is highly change averse between
>>>> minor releases (to use semantic versioning terms) and therefore changing
>>>> the default colormap is unpalatable in the v1.x release series. As a result
>>>> I'd like to propose that the next release of matplotlib be called 2.0, with
>>>> the *only* major backwards-incompatible change be the removal of Jet
>>>> as the default colormap.
>>>>
>>>> As a project matplotlib mustn't get caught up in the trap of shying
>>>> away from a major version release when the need arises, and in my opinion
>>>> helping our users to avoid using a misleading colormap is a worthy cause
>>>> for a v2.0.
>>>>
>>>> Please try to keep this thread on the "how", and not on the "what" of
>>>> the replacement default colormap, for which there is a dedicated thread.
>>>>
>>>> Thanks,
>>>>
>>>> Phil
>>>>
>>>> (#endrainbow)
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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=157005751&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=157005751&
>>> iu=/4140/ostg.clktrk_______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>

A few thoughts to add to the excellent ones to date, to do with colorbar
behaviour.
My general comment would be that if the axis tick formatter defaults are
changed not to forget about the colorbar as I typically find it needs more
tweaking than the main axes.
I'll make a couple of suggestions, but these are low on the list compared
to the suggestions that others have made.
1. consider rasterizing colorbar contents by default
2. make colorbar axis sizing for matshow behave like imshow
1. consider rasterizing colorbar contents by default
Eric describes this here
http://matplotlib.1069221.n5.nabble.com/rasterized-colorbar-td39582.html
and suggests that rasterizing the colorbar may not be desirable, although
I'm not totally sure why. Perhaps it is because I have noticed that mixing
rasterized content with vector lines/axes in matplotlib is generally
imperfect. If saving the figure as a pdf or svg with dpi left at default,
you can usually see offsets and scaling problems. For example after
rasterizing a colorbar I usually see white pixels along the top and side
within the vector colorbar frame. This also shows up when using imshow or
matshow to show images. I don't know if this is an agg limitation, a
backend limitation or a bug. If it's a known limitation, maybe avoid this
suggestion, but if it's a bug, maybe it can be fixed and then rasterizing
the colorbar might become a better default option.
For colorbars I usually do lots of tweaking along the lines of:
cb = plt.colorbar(format=ScalarFormatter(useMathText=True))
cb.formatter.set_useOffset(False)
cb.formatter.set_scientific(True)
cb.formatter.set_powerlimits((0,2))
cb.update_ticks()
cb.solids.set_rasterized(True)
although I'm not sure about advocating useMathText and set_scientific for
defaults. I wonder what other think about this?
Things like default powerlimits for the colorbar might be rethought. I
think colorbars typically have too many ticks and associated labels and
they should perhaps favour integer labels over floating point
representation if possible.
In the extreme case, for continuous colormaps, often a tick at just the top
and bottom of the range would be adequate.
2. I'm not sure how much pyplot.matshow is generally used but I still use
it.
Could the colorbar height for matshow pick up the axis height of the main
figure, or maybe imshow could default to interpolation='nearest' so I
wouldn't be tempted to use matshow any more?
For example,
plt.matshow(rand(20,20))
plt.colorbar()
doesn't behave nicely like
plt.imshow(rand(20,20), interpolation='nearest')
plt.colorbar()
Gary
On 22 November 2014 at 19:06, Nicolas P. Rougier <Nic...@in...>
wrote:
>
> I would be also quite interested in having better defaults. My list of
> "complains" are:
>
> * Easy way to get only two lines for axis (left and down, instead of four)
> * Better default font (Source Sans Pro / Source Code Pro for example (open
> source))
> * Better default colormap
> * Better axis limit (when you draw with thick lines, they get cut)
> * Better icons for the toolbar (there are a lot of free icons around)
> * Better colors (more pastel)
> * Less "cluttered" figures
> * Lighter grids
>
> + All Nathaniel's suggestions
>
>
> Ideally, we could have a set of standard figures for each main type (plot,
> scatter, quiver) and tweak parameters to search for the best output.
>
>
> Nicolas
>
>
> > On 22 Nov 2014, at 04:18, Benjamin Root <ben...@ou...> wrote:
> >
> > With regards to defaults for 2.0, I am actually all for breaking them
> for the better. What I find important is giving users an easy mechanism to
> use an older style, if it is important to them. The current behavior isn't
> "buggy" (for the most part) and failing to give users a way to get behavior
> that they found desirable would be alienating. I think this is why projects
> like prettyplotlib and seaborn have been so important to matplotlib. It
> enables those who are in the right position to judge styles to explore the
> possibilities easily without commiting matplotlib to any early decision and
> allowing it to have a level of stability that many users find attractive.
> >
> > At the moment, the plans for the OO interface changes should not result
> in any (major) API breaks, so I am not concerned about that at the moment.
> Let's keep focused on style related issues in this thread.
> >
> > Tabbed figures? Intriguing... And I really do need to review that MEP of
> yours...
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <
> ari...@gm...> wrote:
> > I like the idea of aligning a set of changes for 2.0 even if still far
> away.
> >
> > Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> > Take for example the OO interface (not defined yet) this is very
> probable to break the current pyplot interface but still this is a change
> that needs to be done.
> >
> > In terms of defaults. I would like to see the new Navigation as default
> (if it gets merged) and tabbed figures (to come after navigation), having
> separate figures feel kind of ..."old"
> >
> > On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> > Some of your wishes are in progress already:
> https://github.com/matplotlib/matplotlib/pull/3818
> > There is also an issue open about scaling the dashes with the line
> width, and you are right, the spacing for the dashes are terrible.
> >
> > I can definitely see the argument to making a bunch of these visual
> changes together. Preferably, I would like to do these changes via style
> sheets so that we can provide a "classic" stylesheet for backwards
> compatibility.
> >
> > I do actually like the autoscaling system as it exists now. The problem
> is that the data margins feature is applied haphazardly. The power spectra
> example is a good example of where we could "smarten" the system. As for
> the ticks... I think that is a very obscure edge-case. I personally prefer
> inward.
> >
> > It is good to get these grievances enumerated. I am interested in seeing
> where this discussion goes.
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> > Hi all,
> >
> > Since we're considering the possibility of making a matplotlib 2.0
> > release with a better default colormap, it occurred to me that it
> > might make sense to take this opportunity to improve other visual
> > defaults.
> >
> > Defaults are important. Obviously for publication graphs you'll want
> > to end up tweaking every detail, but (a) not everyone does but we
> > still have to read their graphs, and (b) probably only 1% of the plots
> > I make are for publication; the rest are quick one-offs that I make
> > on-the-fly to help me understand my own data. For such plots it's
> > usually not worth spending much/any time tweaking layout details, I
> > just want something usable, quickly. And I think there's a fair amount
> > of low-hanging improvements possible.
> >
> > Batching multiple visual changes like this together seems much better
> > than spreading them out over multiple releases. It keeps the messaging
> > super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> > will still work, the only difference is that your plots will look
> > better by default". And grouping these changes together makes it
> > easier to provide for users who need to revert back to the old
> > defaults -- it's easy to provide simple binary choice between "before
> > 2.0" versus "after 2.0", harder to keep track of a bunch of different
> > changes spread over multiple releases.
> >
> > Some particular annoyances I often run into and that might be
> > candidates for changing:
> >
> > - The default method of choosing axis limits is IME really, really
> > annoying, because of the way it tries to find "round number"
> > boundaries. It's a clever idea, but in practice I've almost never seen
> > this pick axis limits that are particularly meaningful for my data,
> > and frequently it picks particularly bad ones. For example, suppose
> > you want to plot the spectrum of a signal; because of FFT's preference
> > for power-of-two sizes works it's natural to end up with samples
> > ranging from 0 to 255. If you plot this, matplotlib will give you an
> > xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> > way this method of choosing xlims can actually obscure data -- if the
> > extreme values in your data set happen to fall exactly on a "round
> > number", then this will be used as the axis limits, and you'll end up
> > with data plotted directly underneath the axis spine. I frequently
> > encounter this when making scatter plots of data in the 0-1 range --
> > the points located at exactly 0 and 1 are very important to see, but
> > are nearly invisible by default. A similar case I ran into recently
> > was when plotting autocorrelation functions for different signals. For
> > reference I wanted to include the theoretically ideal ACF for white
> > noise, which looks like this:
> > plt.plot(np.arange(1000), [1] + [0] * 999)
> > Good luck reading that plot!
> >
> > R's default rule for deciding axis limits is very simple: extend the
> > data range by 4% on each side; those are your limits. IME this rule --
> > while obviously not perfect -- always produces something readable and
> > unobjectionable.
> >
> > - Axis tickmarks should point outwards rather than inwards: There's
> > really no advantage to making them point inwards, and pointing inwards
> > means they can obscure data. My favorite example of this is plotting a
> > histogram with 100 bins -- that's an obvious thing to do, right? Check
> > it out:
> > plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> > This makes me do a double-take every few months until I remember
> > what's going on: "WTF why is the bar on the left showing a *stacked*
> > barplot...ohhhhh right those are just the ticks, which happen to be
> > exactly the same width as the bar." Very confusing.
> >
> > Seaborn's built-in themes give you the options of (1) no axis ticks at
> > all, just a background grid (by default the white-on-light-grey grid
> > as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> > option seems like a better default to me!
> >
> > - Default line colors: The rgbcmyk color cycle for line plots doesn't
> > appear to be based on any real theory about visualization -- it's just
> > the corners of the RGB color cube, which is a highly perceptually
> > non-uniform space. The resulting lines aren't terribly high contrast
> > against the default white background, and the different colors have
> > varying luminance that makes some lines "pop out" more than others.
> >
> > Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
> >
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> > ggplot2 uses isoluminant colors with maximally-separated hues, which
> > also works well. E.g.:
> >
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> >
> > - Line thickness: basically every time I make a line plot I wish the
> > lines were thicker. This is another thing that seaborn simply changes
> > unconditionally.
> >
> > In general I guess we could do a lot worse than to simply adopt
> > seaborn's defaults as the matplotlib defaults :-) Their full list of
> > overrides can be seen here:
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
> >
> > - Dash styles: a common recommendation for line plots is to
> > simultaneously vary both the color and the dash style of your lines,
> > because redundant cues are good and dash styles are more robust than
> > color in the face of greyscale printing etc. But every time I try to
> > follow this advice I find myself having to define new dashes from
> > scratch, because matplotlib's default dash styles ("-", "--", "-.",
> > ":") have wildly varying weights; in particular I often find it hard
> > to even see the dots in the ":" and "-." styles. Here's someone with a
> > similar complaint:
> >
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
> >
> > Just as very rough numbers, something along the lines of "--" = [7,
> > 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
> >
> > It might also make sense to consider baking the advice I mentioned
> > above into matplotlib directly, and having a non-trivial dash cycle
> > enabled by default. (So the first line plotted uses "-", second uses
> > "--" or similar, etc.) This would also have the advantage that if we
> > make the length of the color cycle and the dash cycle relatively
> > prime, then we'll dramatically increase the number of lines that can
> > be plotted on the same graph with distinct appearances. (I often run
> > into the annoying situation where I throw up a quick-and-dirty plot,
> > maybe with something like pandas's dataframe.plot(), and then discover
> > that I have multiple indistinguishable lines.)
> >
> > Obviously one could quibble with my specific proposals here, but does
> > in general seem like a useful thing to do?
> >
> > -n
> >
> > --
> > Nathaniel J. Smith
> > Postdoctoral researcher - Informatics - University of Edinburgh
> > http://vorpus.org
> >
> >
> ------------------------------------------------------------------------------
> > 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=157005751&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=157005751&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=157005751&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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I think using native icons would be the best scenario, at least whet the
backend and platform support it.
On Nov 22, 2014 9:08 AM, "Nicolas P. Rougier" <Nic...@in...>
wrote:
>
> I would be also quite interested in having better defaults. My list of
> "complains" are:
>
> * Easy way to get only two lines for axis (left and down, instead of four)
> * Better default font (Source Sans Pro / Source Code Pro for example (open
> source))
> * Better default colormap
> * Better axis limit (when you draw with thick lines, they get cut)
> * Better icons for the toolbar (there are a lot of free icons around)
> * Better colors (more pastel)
> * Less "cluttered" figures
> * Lighter grids
>
> + All Nathaniel's suggestions
>
>
> Ideally, we could have a set of standard figures for each main type (plot,
> scatter, quiver) and tweak parameters to search for the best output.
>
>
> Nicolas
>
>
> > On 22 Nov 2014, at 04:18, Benjamin Root <ben...@ou...> wrote:
> >
> > With regards to defaults for 2.0, I am actually all for breaking them
> for the better. What I find important is giving users an easy mechanism to
> use an older style, if it is important to them. The current behavior isn't
> "buggy" (for the most part) and failing to give users a way to get behavior
> that they found desirable would be alienating. I think this is why projects
> like prettyplotlib and seaborn have been so important to matplotlib. It
> enables those who are in the right position to judge styles to explore the
> possibilities easily without commiting matplotlib to any early decision and
> allowing it to have a level of stability that many users find attractive.
> >
> > At the moment, the plans for the OO interface changes should not result
> in any (major) API breaks, so I am not concerned about that at the moment.
> Let's keep focused on style related issues in this thread.
> >
> > Tabbed figures? Intriguing... And I really do need to review that MEP of
> yours...
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <
> ari...@gm...> wrote:
> > I like the idea of aligning a set of changes for 2.0 even if still far
> away.
> >
> > Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> > Take for example the OO interface (not defined yet) this is very
> probable to break the current pyplot interface but still this is a change
> that needs to be done.
> >
> > In terms of defaults. I would like to see the new Navigation as default
> (if it gets merged) and tabbed figures (to come after navigation), having
> separate figures feel kind of ..."old"
> >
> > On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> > Some of your wishes are in progress already:
> https://github.com/matplotlib/matplotlib/pull/3818
> > There is also an issue open about scaling the dashes with the line
> width, and you are right, the spacing for the dashes are terrible.
> >
> > I can definitely see the argument to making a bunch of these visual
> changes together. Preferably, I would like to do these changes via style
> sheets so that we can provide a "classic" stylesheet for backwards
> compatibility.
> >
> > I do actually like the autoscaling system as it exists now. The problem
> is that the data margins feature is applied haphazardly. The power spectra
> example is a good example of where we could "smarten" the system. As for
> the ticks... I think that is a very obscure edge-case. I personally prefer
> inward.
> >
> > It is good to get these grievances enumerated. I am interested in seeing
> where this discussion goes.
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> > Hi all,
> >
> > Since we're considering the possibility of making a matplotlib 2.0
> > release with a better default colormap, it occurred to me that it
> > might make sense to take this opportunity to improve other visual
> > defaults.
> >
> > Defaults are important. Obviously for publication graphs you'll want
> > to end up tweaking every detail, but (a) not everyone does but we
> > still have to read their graphs, and (b) probably only 1% of the plots
> > I make are for publication; the rest are quick one-offs that I make
> > on-the-fly to help me understand my own data. For such plots it's
> > usually not worth spending much/any time tweaking layout details, I
> > just want something usable, quickly. And I think there's a fair amount
> > of low-hanging improvements possible.
> >
> > Batching multiple visual changes like this together seems much better
> > than spreading them out over multiple releases. It keeps the messaging
> > super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> > will still work, the only difference is that your plots will look
> > better by default". And grouping these changes together makes it
> > easier to provide for users who need to revert back to the old
> > defaults -- it's easy to provide simple binary choice between "before
> > 2.0" versus "after 2.0", harder to keep track of a bunch of different
> > changes spread over multiple releases.
> >
> > Some particular annoyances I often run into and that might be
> > candidates for changing:
> >
> > - The default method of choosing axis limits is IME really, really
> > annoying, because of the way it tries to find "round number"
> > boundaries. It's a clever idea, but in practice I've almost never seen
> > this pick axis limits that are particularly meaningful for my data,
> > and frequently it picks particularly bad ones. For example, suppose
> > you want to plot the spectrum of a signal; because of FFT's preference
> > for power-of-two sizes works it's natural to end up with samples
> > ranging from 0 to 255. If you plot this, matplotlib will give you an
> > xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> > way this method of choosing xlims can actually obscure data -- if the
> > extreme values in your data set happen to fall exactly on a "round
> > number", then this will be used as the axis limits, and you'll end up
> > with data plotted directly underneath the axis spine. I frequently
> > encounter this when making scatter plots of data in the 0-1 range --
> > the points located at exactly 0 and 1 are very important to see, but
> > are nearly invisible by default. A similar case I ran into recently
> > was when plotting autocorrelation functions for different signals. For
> > reference I wanted to include the theoretically ideal ACF for white
> > noise, which looks like this:
> > plt.plot(np.arange(1000), [1] + [0] * 999)
> > Good luck reading that plot!
> >
> > R's default rule for deciding axis limits is very simple: extend the
> > data range by 4% on each side; those are your limits. IME this rule --
> > while obviously not perfect -- always produces something readable and
> > unobjectionable.
> >
> > - Axis tickmarks should point outwards rather than inwards: There's
> > really no advantage to making them point inwards, and pointing inwards
> > means they can obscure data. My favorite example of this is plotting a
> > histogram with 100 bins -- that's an obvious thing to do, right? Check
> > it out:
> > plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> > This makes me do a double-take every few months until I remember
> > what's going on: "WTF why is the bar on the left showing a *stacked*
> > barplot...ohhhhh right those are just the ticks, which happen to be
> > exactly the same width as the bar." Very confusing.
> >
> > Seaborn's built-in themes give you the options of (1) no axis ticks at
> > all, just a background grid (by default the white-on-light-grey grid
> > as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> > option seems like a better default to me!
> >
> > - Default line colors: The rgbcmyk color cycle for line plots doesn't
> > appear to be based on any real theory about visualization -- it's just
> > the corners of the RGB color cube, which is a highly perceptually
> > non-uniform space. The resulting lines aren't terribly high contrast
> > against the default white background, and the different colors have
> > varying luminance that makes some lines "pop out" more than others.
> >
> > Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
> >
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> > ggplot2 uses isoluminant colors with maximally-separated hues, which
> > also works well. E.g.:
> >
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> >
> > - Line thickness: basically every time I make a line plot I wish the
> > lines were thicker. This is another thing that seaborn simply changes
> > unconditionally.
> >
> > In general I guess we could do a lot worse than to simply adopt
> > seaborn's defaults as the matplotlib defaults :-) Their full list of
> > overrides can be seen here:
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
> >
> > - Dash styles: a common recommendation for line plots is to
> > simultaneously vary both the color and the dash style of your lines,
> > because redundant cues are good and dash styles are more robust than
> > color in the face of greyscale printing etc. But every time I try to
> > follow this advice I find myself having to define new dashes from
> > scratch, because matplotlib's default dash styles ("-", "--", "-.",
> > ":") have wildly varying weights; in particular I often find it hard
> > to even see the dots in the ":" and "-." styles. Here's someone with a
> > similar complaint:
> >
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
> >
> > Just as very rough numbers, something along the lines of "--" = [7,
> > 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
> >
> > It might also make sense to consider baking the advice I mentioned
> > above into matplotlib directly, and having a non-trivial dash cycle
> > enabled by default. (So the first line plotted uses "-", second uses
> > "--" or similar, etc.) This would also have the advantage that if we
> > make the length of the color cycle and the dash cycle relatively
> > prime, then we'll dramatically increase the number of lines that can
> > be plotted on the same graph with distinct appearances. (I often run
> > into the annoying situation where I throw up a quick-and-dirty plot,
> > maybe with something like pandas's dataframe.plot(), and then discover
> > that I have multiple indistinguishable lines.)
> >
> > Obviously one could quibble with my specific proposals here, but does
> > in general seem like a useful thing to do?
> >
> > -n
> >
> > --
> > Nathaniel J. Smith
> > Postdoctoral researcher - Informatics - University of Edinburgh
> > http://vorpus.org
> >
> >
> ------------------------------------------------------------------------------
> > 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=157005751&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=157005751&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=157005751&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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Given the workload that making a release causes, is it necessary to put out
a v1.4.3 at all? On a similar sounding argument, given that the removal of
CXX doesn't break user APIs, and has been on master for several weeks with
fewer than anticipated side-effects, do we even need a v1.5? Essentially,
what is the barrier from moving straight to a v2.0 in Feb?
What I'd like to avoid is this idea of "we're talking about a making a
major release so let's fix everything that was ever broken" - my definition
of a v2.0 release is really just v1.5+new default cmap. If there are other
things that need fixing in a backwards incompatible way then we should
discuss and plan how we are going to do that, and if there is developer
appetite, there is no reason not to talk about releasing a v3.0 in 18-24
months (which is currently ~2 mpl minor release cycles).
On 21 November 2014 18:56, Thomas Caswell <tca...@gm...> wrote:
> I am a bit wary of doing a 2.0 _just_ to change the color map, but when
> every I try to write out why, they don't sound convincing. We may end up
> with a 3.0 within a year or so due to the possible plotting API/pyplot work
> that is (hopefully) coming.
>
> If we are going to do this, I think we should do the 1.4.3 release
> (scheduled for Feb 1, RCs in mid January), then put one commit to change
> the color map on top of that, tag 2.0 and then master turns into 2.1.x
> (targeted for right after scipy?).
>
> There is also the thought to get the major c++ refactor work tagged and
> released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
> 2.0 in Feb with 2.0 based off of 1.5 not 1.4.
>
> On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben...@ou...> wrote:
>
>> As a point of clarification, is this proposed 2.0 release different from
>> the 1.5 release?
>>
>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
>> wrote:
>>
>>> Many of you will be aware of there has been an ongoing issue (#875,
>>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the
>>> default colormap in matplotlib.
>>>
>>> The argument against Jet is compelling and I think that as a group who
>>> care about high quality visualisation we should be seriously discussing how
>>> matplotlib can move beyond Jet.
>>>
>>> There was recently an open letter to the climate science community
>>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking for
>>> scientists to "pledge" against using rainbow like colormaps (such as Jet),
>>> and there are similar initiatives in other scientific fields, as well as
>>> there being a plethora of well researched literature on the subject.
>>>
>>> As such, it's time to agree on a solution on how matplotlib can reach
>>> the end of the rainbow.
>>>
>>>
>>> The two major hurdles, AFAICS, to replacing the three little characters
>>> which control the default colormap of matplotlib are:
>>>
>>> * We haven't had a clear (decisive) discussion about what we should
>>> replace Jet with.
>>> * There are concerns about changing the default as it would change the
>>> existing widespread behaviour.
>>>
>>> To address the first point I'll start a new mailinglist thread (entitled
>>> "Matplotlib's new default colormap") where new default colormap suggestions
>>> can be made. The thread should strictly avoid "+1" type comments, and
>>> generally try to stick to reference-able/demonstrable fact, rather than
>>> opinion. There *will* be a difference of opinion, however the final
>>> decision has to come down to the project lead (sorry Mike) who I know will
>>> do whatever is necessary to make the best choice for matplotlib.
>>>
>>> The second point is a reasonable response when we consider that
>>> matplotlib as a project has no *clear* statement on backwards
>>> compatibility. As a result, matplotlib is highly change averse between
>>> minor releases (to use semantic versioning terms) and therefore changing
>>> the default colormap is unpalatable in the v1.x release series. As a result
>>> I'd like to propose that the next release of matplotlib be called 2.0, with
>>> the *only* major backwards-incompatible change be the removal of Jet as
>>> the default colormap.
>>>
>>> As a project matplotlib mustn't get caught up in the trap of shying away
>>> from a major version release when the need arises, and in my opinion
>>> helping our users to avoid using a misleading colormap is a worthy cause
>>> for a v2.0.
>>>
>>> Please try to keep this thread on the "how", and not on the "what" of
>>> the replacement default colormap, for which there is a dedicated thread.
>>>
>>> Thanks,
>>>
>>> Phil
>>>
>>> (#endrainbow)
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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=157005751&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=157005751&
>> iu=/4140/ostg.clktrk_______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

I would be also quite interested in having better defaults. My list of "complains" are:
* Easy way to get only two lines for axis (left and down, instead of four)
* Better default font (Source Sans Pro / Source Code Pro for example (open source))
* Better default colormap
* Better axis limit (when you draw with thick lines, they get cut)
* Better icons for the toolbar (there are a lot of free icons around)
* Better colors (more pastel)
* Less "cluttered" figures
* Lighter grids
+ All Nathaniel's suggestions
Ideally, we could have a set of standard figures for each main type (plot, scatter, quiver) and tweak parameters to search for the best output.
Nicolas
> On 22 Nov 2014, at 04:18, Benjamin Root <ben...@ou...> wrote:
> 
> With regards to defaults for 2.0, I am actually all for breaking them for the better. What I find important is giving users an easy mechanism to use an older style, if it is important to them. The current behavior isn't "buggy" (for the most part) and failing to give users a way to get behavior that they found desirable would be alienating. I think this is why projects like prettyplotlib and seaborn have been so important to matplotlib. It enables those who are in the right position to judge styles to explore the possibilities easily without commiting matplotlib to any early decision and allowing it to have a level of stability that many users find attractive.
> 
> At the moment, the plans for the OO interface changes should not result in any (major) API breaks, so I am not concerned about that at the moment. Let's keep focused on style related issues in this thread.
> 
> Tabbed figures? Intriguing... And I really do need to review that MEP of yours...
> 
> Cheers!
> Ben Root
> 
> On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <ari...@gm...> wrote:
> I like the idea of aligning a set of changes for 2.0 even if still far away.
> 
> Regarding to backwards compatibility I think that indeed it is important but when changing mayor version (1.x to 2.0) becomes less important and we must take care of prioritizing evolution. 
> Take for example the OO interface (not defined yet) this is very probable to break the current pyplot interface but still this is a change that needs to be done.
> 
> In terms of defaults. I would like to see the new Navigation as default (if it gets merged) and tabbed figures (to come after navigation), having separate figures feel kind of ..."old"
> 
> On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> Some of your wishes are in progress already: https://github.com/matplotlib/matplotlib/pull/3818
> There is also an issue open about scaling the dashes with the line width, and you are right, the spacing for the dashes are terrible.
> 
> I can definitely see the argument to making a bunch of these visual changes together. Preferably, I would like to do these changes via style sheets so that we can provide a "classic" stylesheet for backwards compatibility.
> 
> I do actually like the autoscaling system as it exists now. The problem is that the data margins feature is applied haphazardly. The power spectra example is a good example of where we could "smarten" the system. As for the ticks... I think that is a very obscure edge-case. I personally prefer inward.
> 
> It is good to get these grievances enumerated. I am interested in seeing where this discussion goes.
> 
> Cheers!
> Ben Root
> 
> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> Hi all,
> 
> Since we're considering the possibility of making a matplotlib 2.0
> release with a better default colormap, it occurred to me that it
> might make sense to take this opportunity to improve other visual
> defaults.
> 
> Defaults are important. Obviously for publication graphs you'll want
> to end up tweaking every detail, but (a) not everyone does but we
> still have to read their graphs, and (b) probably only 1% of the plots
> I make are for publication; the rest are quick one-offs that I make
> on-the-fly to help me understand my own data. For such plots it's
> usually not worth spending much/any time tweaking layout details, I
> just want something usable, quickly. And I think there's a fair amount
> of low-hanging improvements possible.
> 
> Batching multiple visual changes like this together seems much better
> than spreading them out over multiple releases. It keeps the messaging
> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> will still work, the only difference is that your plots will look
> better by default". And grouping these changes together makes it
> easier to provide for users who need to revert back to the old
> defaults -- it's easy to provide simple binary choice between "before
> 2.0" versus "after 2.0", harder to keep track of a bunch of different
> changes spread over multiple releases.
> 
> Some particular annoyances I often run into and that might be
> candidates for changing:
> 
> - The default method of choosing axis limits is IME really, really
> annoying, because of the way it tries to find "round number"
> boundaries. It's a clever idea, but in practice I've almost never seen
> this pick axis limits that are particularly meaningful for my data,
> and frequently it picks particularly bad ones. For example, suppose
> you want to plot the spectrum of a signal; because of FFT's preference
> for power-of-two sizes works it's natural to end up with samples
> ranging from 0 to 255. If you plot this, matplotlib will give you an
> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> way this method of choosing xlims can actually obscure data -- if the
> extreme values in your data set happen to fall exactly on a "round
> number", then this will be used as the axis limits, and you'll end up
> with data plotted directly underneath the axis spine. I frequently
> encounter this when making scatter plots of data in the 0-1 range --
> the points located at exactly 0 and 1 are very important to see, but
> are nearly invisible by default. A similar case I ran into recently
> was when plotting autocorrelation functions for different signals. For
> reference I wanted to include the theoretically ideal ACF for white
> noise, which looks like this:
> plt.plot(np.arange(1000), [1] + [0] * 999)
> Good luck reading that plot!
> 
> R's default rule for deciding axis limits is very simple: extend the
> data range by 4% on each side; those are your limits. IME this rule --
> while obviously not perfect -- always produces something readable and
> unobjectionable.
> 
> - Axis tickmarks should point outwards rather than inwards: There's
> really no advantage to making them point inwards, and pointing inwards
> means they can obscure data. My favorite example of this is plotting a
> histogram with 100 bins -- that's an obvious thing to do, right? Check
> it out:
> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> This makes me do a double-take every few months until I remember
> what's going on: "WTF why is the bar on the left showing a *stacked*
> barplot...ohhhhh right those are just the ticks, which happen to be
> exactly the same width as the bar." Very confusing.
> 
> Seaborn's built-in themes give you the options of (1) no axis ticks at
> all, just a background grid (by default the white-on-light-grey grid
> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> option seems like a better default to me!
> 
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The resulting lines aren't terribly high contrast
> against the default white background, and the different colors have
> varying luminance that makes some lines "pop out" more than others.
> 
> Seaborn's default is to use a nice isoluminant variant on matplotlib's default:
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> ggplot2 uses isoluminant colors with maximally-separated hues, which
> also works well. E.g.:
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> 
> - Line thickness: basically every time I make a line plot I wish the
> lines were thicker. This is another thing that seaborn simply changes
> unconditionally.
> 
> In general I guess we could do a lot worse than to simply adopt
> seaborn's defaults as the matplotlib defaults :-) Their full list of
> overrides can be seen here:
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
> 
> - Dash styles: a common recommendation for line plots is to
> simultaneously vary both the color and the dash style of your lines,
> because redundant cues are good and dash styles are more robust than
> color in the face of greyscale printing etc. But every time I try to
> follow this advice I find myself having to define new dashes from
> scratch, because matplotlib's default dash styles ("-", "--", "-.",
> ":") have wildly varying weights; in particular I often find it hard
> to even see the dots in the ":" and "-." styles. Here's someone with a
> similar complaint:
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
> 
> Just as very rough numbers, something along the lines of "--" = [7,
> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
> 
> It might also make sense to consider baking the advice I mentioned
> above into matplotlib directly, and having a non-trivial dash cycle
> enabled by default. (So the first line plotted uses "-", second uses
> "--" or similar, etc.) This would also have the advantage that if we
> make the length of the color cycle and the dash cycle relatively
> prime, then we'll dramatically increase the number of lines that can
> be plotted on the same graph with distinct appearances. (I often run
> into the annoying situation where I throw up a quick-and-dirty plot,
> maybe with something like pandas's dataframe.plot(), and then discover
> that I have multiple indistinguishable lines.)
> 
> Obviously one could quibble with my specific proposals here, but does
> in general seem like a useful thing to do?
> 
> -n
> 
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> 
> ------------------------------------------------------------------------------
> 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=157005751&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=157005751&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=157005751&iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

With regards to defaults for 2.0, I am actually all for breaking them for
the better. What I find important is giving users an easy mechanism to use
an older style, if it is important to them. The current behavior isn't
"buggy" (for the most part) and failing to give users a way to get behavior
that they found desirable would be alienating. I think this is why projects
like prettyplotlib and seaborn have been so important to matplotlib. It
enables those who are in the right position to judge styles to explore the
possibilities easily without commiting matplotlib to any early decision and
allowing it to have a level of stability that many users find attractive.
At the moment, the plans for the OO interface changes should not result in
any (major) API breaks, so I am not concerned about that at the moment.
Let's keep focused on style related issues in this thread.
Tabbed figures? Intriguing... And I really do need to review that MEP of
yours...
Cheers!
Ben Root
On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <ari...@gm...>
wrote:
> I like the idea of aligning a set of changes for 2.0 even if still far
> away.
>
> Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> Take for example the OO interface (not defined yet) this is very probable
> to break the current pyplot interface but still this is a change that needs
> to be done.
>
> In terms of defaults. I would like to see the new Navigation as default
> (if it gets merged) and tabbed figures (to come after navigation), having
> separate figures feel kind of ..."old"
> On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
>
>> Some of your wishes are in progress already:
>> https://github.com/matplotlib/matplotlib/pull/3818
>> There is also an issue open about scaling the dashes with the line width,
>> and you are right, the spacing for the dashes are terrible.
>>
>> I can definitely see the argument to making a bunch of these visual
>> changes together. Preferably, I would like to do these changes via style
>> sheets so that we can provide a "classic" stylesheet for backwards
>> compatibility.
>>
>> I do actually like the autoscaling system as it exists now. The problem
>> is that the data margins feature is applied haphazardly. The power spectra
>> example is a good example of where we could "smarten" the system. As for
>> the ticks... I think that is a very obscure edge-case. I personally prefer
>> inward.
>>
>> It is good to get these grievances enumerated. I am interested in seeing
>> where this discussion goes.
>>
>> Cheers!
>> Ben Root
>>
>> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
>>
>>> Hi all,
>>>
>>> Since we're considering the possibility of making a matplotlib 2.0
>>> release with a better default colormap, it occurred to me that it
>>> might make sense to take this opportunity to improve other visual
>>> defaults.
>>>
>>> Defaults are important. Obviously for publication graphs you'll want
>>> to end up tweaking every detail, but (a) not everyone does but we
>>> still have to read their graphs, and (b) probably only 1% of the plots
>>> I make are for publication; the rest are quick one-offs that I make
>>> on-the-fly to help me understand my own data. For such plots it's
>>> usually not worth spending much/any time tweaking layout details, I
>>> just want something usable, quickly. And I think there's a fair amount
>>> of low-hanging improvements possible.
>>>
>>> Batching multiple visual changes like this together seems much better
>>> than spreading them out over multiple releases. It keeps the messaging
>>> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
>>> will still work, the only difference is that your plots will look
>>> better by default". And grouping these changes together makes it
>>> easier to provide for users who need to revert back to the old
>>> defaults -- it's easy to provide simple binary choice between "before
>>> 2.0" versus "after 2.0", harder to keep track of a bunch of different
>>> changes spread over multiple releases.
>>>
>>> Some particular annoyances I often run into and that might be
>>> candidates for changing:
>>>
>>> - The default method of choosing axis limits is IME really, really
>>> annoying, because of the way it tries to find "round number"
>>> boundaries. It's a clever idea, but in practice I've almost never seen
>>> this pick axis limits that are particularly meaningful for my data,
>>> and frequently it picks particularly bad ones. For example, suppose
>>> you want to plot the spectrum of a signal; because of FFT's preference
>>> for power-of-two sizes works it's natural to end up with samples
>>> ranging from 0 to 255. If you plot this, matplotlib will give you an
>>> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
>>> way this method of choosing xlims can actually obscure data -- if the
>>> extreme values in your data set happen to fall exactly on a "round
>>> number", then this will be used as the axis limits, and you'll end up
>>> with data plotted directly underneath the axis spine. I frequently
>>> encounter this when making scatter plots of data in the 0-1 range --
>>> the points located at exactly 0 and 1 are very important to see, but
>>> are nearly invisible by default. A similar case I ran into recently
>>> was when plotting autocorrelation functions for different signals. For
>>> reference I wanted to include the theoretically ideal ACF for white
>>> noise, which looks like this:
>>> plt.plot(np.arange(1000), [1] + [0] * 999)
>>> Good luck reading that plot!
>>>
>>> R's default rule for deciding axis limits is very simple: extend the
>>> data range by 4% on each side; those are your limits. IME this rule --
>>> while obviously not perfect -- always produces something readable and
>>> unobjectionable.
>>>
>>> - Axis tickmarks should point outwards rather than inwards: There's
>>> really no advantage to making them point inwards, and pointing inwards
>>> means they can obscure data. My favorite example of this is plotting a
>>> histogram with 100 bins -- that's an obvious thing to do, right? Check
>>> it out:
>>> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
>>> This makes me do a double-take every few months until I remember
>>> what's going on: "WTF why is the bar on the left showing a *stacked*
>>> barplot...ohhhhh right those are just the ticks, which happen to be
>>> exactly the same width as the bar." Very confusing.
>>>
>>> Seaborn's built-in themes give you the options of (1) no axis ticks at
>>> all, just a background grid (by default the white-on-light-grey grid
>>> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
>>> option seems like a better default to me!
>>>
>>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>>> appear to be based on any real theory about visualization -- it's just
>>> the corners of the RGB color cube, which is a highly perceptually
>>> non-uniform space. The resulting lines aren't terribly high contrast
>>> against the default white background, and the different colors have
>>> varying luminance that makes some lines "pop out" more than others.
>>>
>>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>>> default:
>>>
>>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>>> also works well. E.g.:
>>>
>>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>>>
>>> - Line thickness: basically every time I make a line plot I wish the
>>> lines were thicker. This is another thing that seaborn simply changes
>>> unconditionally.
>>>
>>> In general I guess we could do a lot worse than to simply adopt
>>> seaborn's defaults as the matplotlib defaults :-) Their full list of
>>> overrides can be seen here:
>>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
>>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>>>
>>> - Dash styles: a common recommendation for line plots is to
>>> simultaneously vary both the color and the dash style of your lines,
>>> because redundant cues are good and dash styles are more robust than
>>> color in the face of greyscale printing etc. But every time I try to
>>> follow this advice I find myself having to define new dashes from
>>> scratch, because matplotlib's default dash styles ("-", "--", "-.",
>>> ":") have wildly varying weights; in particular I often find it hard
>>> to even see the dots in the ":" and "-." styles. Here's someone with a
>>> similar complaint:
>>>
>>> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>>>
>>> Just as very rough numbers, something along the lines of "--" = [7,
>>> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>>>
>>> It might also make sense to consider baking the advice I mentioned
>>> above into matplotlib directly, and having a non-trivial dash cycle
>>> enabled by default. (So the first line plotted uses "-", second uses
>>> "--" or similar, etc.) This would also have the advantage that if we
>>> make the length of the color cycle and the dash cycle relatively
>>> prime, then we'll dramatically increase the number of lines that can
>>> be plotted on the same graph with distinct appearances. (I often run
>>> into the annoying situation where I throw up a quick-and-dirty plot,
>>> maybe with something like pandas's dataframe.plot(), and then discover
>>> that I have multiple indistinguishable lines.)
>>>
>>> Obviously one could quibble with my specific proposals here, but does
>>> in general seem like a useful thing to do?
>>>
>>> -n
>>>
>>> --
>>> Nathaniel J. Smith
>>> Postdoctoral researcher - Informatics - University of Edinburgh
>>> http://vorpus.org
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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=157005751&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=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>

I like the idea of aligning a set of changes for 2.0 even if still far
away.
Regarding to backwards compatibility I think that indeed it is important
but when changing mayor version (1.x to 2.0) becomes less important and we
must take care of prioritizing evolution.
Take for example the OO interface (not defined yet) this is very probable
to break the current pyplot interface but still this is a change that needs
to be done.
In terms of defaults. I would like to see the new Navigation as default (if
it gets merged) and tabbed figures (to come after navigation), having
separate figures feel kind of ..."old"
On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> Some of your wishes are in progress already:
> https://github.com/matplotlib/matplotlib/pull/3818
> There is also an issue open about scaling the dashes with the line width,
> and you are right, the spacing for the dashes are terrible.
>
> I can definitely see the argument to making a bunch of these visual
> changes together. Preferably, I would like to do these changes via style
> sheets so that we can provide a "classic" stylesheet for backwards
> compatibility.
>
> I do actually like the autoscaling system as it exists now. The problem is
> that the data margins feature is applied haphazardly. The power spectra
> example is a good example of where we could "smarten" the system. As for
> the ticks... I think that is a very obscure edge-case. I personally prefer
> inward.
>
> It is good to get these grievances enumerated. I am interested in seeing
> where this discussion goes.
>
> Cheers!
> Ben Root
>
> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
>
>> Hi all,
>>
>> Since we're considering the possibility of making a matplotlib 2.0
>> release with a better default colormap, it occurred to me that it
>> might make sense to take this opportunity to improve other visual
>> defaults.
>>
>> Defaults are important. Obviously for publication graphs you'll want
>> to end up tweaking every detail, but (a) not everyone does but we
>> still have to read their graphs, and (b) probably only 1% of the plots
>> I make are for publication; the rest are quick one-offs that I make
>> on-the-fly to help me understand my own data. For such plots it's
>> usually not worth spending much/any time tweaking layout details, I
>> just want something usable, quickly. And I think there's a fair amount
>> of low-hanging improvements possible.
>>
>> Batching multiple visual changes like this together seems much better
>> than spreading them out over multiple releases. It keeps the messaging
>> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
>> will still work, the only difference is that your plots will look
>> better by default". And grouping these changes together makes it
>> easier to provide for users who need to revert back to the old
>> defaults -- it's easy to provide simple binary choice between "before
>> 2.0" versus "after 2.0", harder to keep track of a bunch of different
>> changes spread over multiple releases.
>>
>> Some particular annoyances I often run into and that might be
>> candidates for changing:
>>
>> - The default method of choosing axis limits is IME really, really
>> annoying, because of the way it tries to find "round number"
>> boundaries. It's a clever idea, but in practice I've almost never seen
>> this pick axis limits that are particularly meaningful for my data,
>> and frequently it picks particularly bad ones. For example, suppose
>> you want to plot the spectrum of a signal; because of FFT's preference
>> for power-of-two sizes works it's natural to end up with samples
>> ranging from 0 to 255. If you plot this, matplotlib will give you an
>> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
>> way this method of choosing xlims can actually obscure data -- if the
>> extreme values in your data set happen to fall exactly on a "round
>> number", then this will be used as the axis limits, and you'll end up
>> with data plotted directly underneath the axis spine. I frequently
>> encounter this when making scatter plots of data in the 0-1 range --
>> the points located at exactly 0 and 1 are very important to see, but
>> are nearly invisible by default. A similar case I ran into recently
>> was when plotting autocorrelation functions for different signals. For
>> reference I wanted to include the theoretically ideal ACF for white
>> noise, which looks like this:
>> plt.plot(np.arange(1000), [1] + [0] * 999)
>> Good luck reading that plot!
>>
>> R's default rule for deciding axis limits is very simple: extend the
>> data range by 4% on each side; those are your limits. IME this rule --
>> while obviously not perfect -- always produces something readable and
>> unobjectionable.
>>
>> - Axis tickmarks should point outwards rather than inwards: There's
>> really no advantage to making them point inwards, and pointing inwards
>> means they can obscure data. My favorite example of this is plotting a
>> histogram with 100 bins -- that's an obvious thing to do, right? Check
>> it out:
>> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
>> This makes me do a double-take every few months until I remember
>> what's going on: "WTF why is the bar on the left showing a *stacked*
>> barplot...ohhhhh right those are just the ticks, which happen to be
>> exactly the same width as the bar." Very confusing.
>>
>> Seaborn's built-in themes give you the options of (1) no axis ticks at
>> all, just a background grid (by default the white-on-light-grey grid
>> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
>> option seems like a better default to me!
>>
>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>> appear to be based on any real theory about visualization -- it's just
>> the corners of the RGB color cube, which is a highly perceptually
>> non-uniform space. The resulting lines aren't terribly high contrast
>> against the default white background, and the different colors have
>> varying luminance that makes some lines "pop out" more than others.
>>
>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>> default:
>>
>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>> also works well. E.g.:
>>
>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>>
>> - Line thickness: basically every time I make a line plot I wish the
>> lines were thicker. This is another thing that seaborn simply changes
>> unconditionally.
>>
>> In general I guess we could do a lot worse than to simply adopt
>> seaborn's defaults as the matplotlib defaults :-) Their full list of
>> overrides can be seen here:
>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>>
>> - Dash styles: a common recommendation for line plots is to
>> simultaneously vary both the color and the dash style of your lines,
>> because redundant cues are good and dash styles are more robust than
>> color in the face of greyscale printing etc. But every time I try to
>> follow this advice I find myself having to define new dashes from
>> scratch, because matplotlib's default dash styles ("-", "--", "-.",
>> ":") have wildly varying weights; in particular I often find it hard
>> to even see the dots in the ":" and "-." styles. Here's someone with a
>> similar complaint:
>>
>> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>>
>> Just as very rough numbers, something along the lines of "--" = [7,
>> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>>
>> It might also make sense to consider baking the advice I mentioned
>> above into matplotlib directly, and having a non-trivial dash cycle
>> enabled by default. (So the first line plotted uses "-", second uses
>> "--" or similar, etc.) This would also have the advantage that if we
>> make the length of the color cycle and the dash cycle relatively
>> prime, then we'll dramatically increase the number of lines that can
>> be plotted on the same graph with distinct appearances. (I often run
>> into the annoying situation where I throw up a quick-and-dirty plot,
>> maybe with something like pandas's dataframe.plot(), and then discover
>> that I have multiple indistinguishable lines.)
>>
>> Obviously one could quibble with my specific proposals here, but does
>> in general seem like a useful thing to do?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith
>> Postdoctoral researcher - Informatics - University of Edinburgh
>> http://vorpus.org
>>
>>
>> ------------------------------------------------------------------------------
>> 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=157005751&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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Some of your wishes are in progress already:
https://github.com/matplotlib/matplotlib/pull/3818
There is also an issue open about scaling the dashes with the line width,
and you are right, the spacing for the dashes are terrible.
I can definitely see the argument to making a bunch of these visual changes
together. Preferably, I would like to do these changes via style sheets so
that we can provide a "classic" stylesheet for backwards compatibility.
I do actually like the autoscaling system as it exists now. The problem is
that the data margins feature is applied haphazardly. The power spectra
example is a good example of where we could "smarten" the system. As for
the ticks... I think that is a very obscure edge-case. I personally prefer
inward.
It is good to get these grievances enumerated. I am interested in seeing
where this discussion goes.
Cheers!
Ben Root
On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> Hi all,
>
> Since we're considering the possibility of making a matplotlib 2.0
> release with a better default colormap, it occurred to me that it
> might make sense to take this opportunity to improve other visual
> defaults.
>
> Defaults are important. Obviously for publication graphs you'll want
> to end up tweaking every detail, but (a) not everyone does but we
> still have to read their graphs, and (b) probably only 1% of the plots
> I make are for publication; the rest are quick one-offs that I make
> on-the-fly to help me understand my own data. For such plots it's
> usually not worth spending much/any time tweaking layout details, I
> just want something usable, quickly. And I think there's a fair amount
> of low-hanging improvements possible.
>
> Batching multiple visual changes like this together seems much better
> than spreading them out over multiple releases. It keeps the messaging
> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> will still work, the only difference is that your plots will look
> better by default". And grouping these changes together makes it
> easier to provide for users who need to revert back to the old
> defaults -- it's easy to provide simple binary choice between "before
> 2.0" versus "after 2.0", harder to keep track of a bunch of different
> changes spread over multiple releases.
>
> Some particular annoyances I often run into and that might be
> candidates for changing:
>
> - The default method of choosing axis limits is IME really, really
> annoying, because of the way it tries to find "round number"
> boundaries. It's a clever idea, but in practice I've almost never seen
> this pick axis limits that are particularly meaningful for my data,
> and frequently it picks particularly bad ones. For example, suppose
> you want to plot the spectrum of a signal; because of FFT's preference
> for power-of-two sizes works it's natural to end up with samples
> ranging from 0 to 255. If you plot this, matplotlib will give you an
> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> way this method of choosing xlims can actually obscure data -- if the
> extreme values in your data set happen to fall exactly on a "round
> number", then this will be used as the axis limits, and you'll end up
> with data plotted directly underneath the axis spine. I frequently
> encounter this when making scatter plots of data in the 0-1 range --
> the points located at exactly 0 and 1 are very important to see, but
> are nearly invisible by default. A similar case I ran into recently
> was when plotting autocorrelation functions for different signals. For
> reference I wanted to include the theoretically ideal ACF for white
> noise, which looks like this:
> plt.plot(np.arange(1000), [1] + [0] * 999)
> Good luck reading that plot!
>
> R's default rule for deciding axis limits is very simple: extend the
> data range by 4% on each side; those are your limits. IME this rule --
> while obviously not perfect -- always produces something readable and
> unobjectionable.
>
> - Axis tickmarks should point outwards rather than inwards: There's
> really no advantage to making them point inwards, and pointing inwards
> means they can obscure data. My favorite example of this is plotting a
> histogram with 100 bins -- that's an obvious thing to do, right? Check
> it out:
> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> This makes me do a double-take every few months until I remember
> what's going on: "WTF why is the bar on the left showing a *stacked*
> barplot...ohhhhh right those are just the ticks, which happen to be
> exactly the same width as the bar." Very confusing.
>
> Seaborn's built-in themes give you the options of (1) no axis ticks at
> all, just a background grid (by default the white-on-light-grey grid
> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> option seems like a better default to me!
>
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The resulting lines aren't terribly high contrast
> against the default white background, and the different colors have
> varying luminance that makes some lines "pop out" more than others.
>
> Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
>
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> ggplot2 uses isoluminant colors with maximally-separated hues, which
> also works well. E.g.:
>
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
> - Line thickness: basically every time I make a line plot I wish the
> lines were thicker. This is another thing that seaborn simply changes
> unconditionally.
>
> In general I guess we could do a lot worse than to simply adopt
> seaborn's defaults as the matplotlib defaults :-) Their full list of
> overrides can be seen here:
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>
> - Dash styles: a common recommendation for line plots is to
> simultaneously vary both the color and the dash style of your lines,
> because redundant cues are good and dash styles are more robust than
> color in the face of greyscale printing etc. But every time I try to
> follow this advice I find myself having to define new dashes from
> scratch, because matplotlib's default dash styles ("-", "--", "-.",
> ":") have wildly varying weights; in particular I often find it hard
> to even see the dots in the ":" and "-." styles. Here's someone with a
> similar complaint:
>
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>
> Just as very rough numbers, something along the lines of "--" = [7,
> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>
> It might also make sense to consider baking the advice I mentioned
> above into matplotlib directly, and having a non-trivial dash cycle
> enabled by default. (So the first line plotted uses "-", second uses
> "--" or similar, etc.) This would also have the advantage that if we
> make the length of the color cycle and the dash cycle relatively
> prime, then we'll dramatically increase the number of lines that can
> be plotted on the same graph with distinct appearances. (I often run
> into the annoying situation where I throw up a quick-and-dirty plot,
> maybe with something like pandas's dataframe.plot(), and then discover
> that I have multiple indistinguishable lines.)
>
> Obviously one could quibble with my specific proposals here, but does
> in general seem like a useful thing to do?
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
>
>
> ------------------------------------------------------------------------------
> 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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,
Since we're considering the possibility of making a matplotlib 2.0
release with a better default colormap, it occurred to me that it
might make sense to take this opportunity to improve other visual
defaults.
Defaults are important. Obviously for publication graphs you'll want
to end up tweaking every detail, but (a) not everyone does but we
still have to read their graphs, and (b) probably only 1% of the plots
I make are for publication; the rest are quick one-offs that I make
on-the-fly to help me understand my own data. For such plots it's
usually not worth spending much/any time tweaking layout details, I
just want something usable, quickly. And I think there's a fair amount
of low-hanging improvements possible.
Batching multiple visual changes like this together seems much better
than spreading them out over multiple releases. It keeps the messaging
super easy to understand: "matplotlib 2.0 is just like 1.x, your code
will still work, the only difference is that your plots will look
better by default". And grouping these changes together makes it
easier to provide for users who need to revert back to the old
defaults -- it's easy to provide simple binary choice between "before
2.0" versus "after 2.0", harder to keep track of a bunch of different
changes spread over multiple releases.
Some particular annoyances I often run into and that might be
candidates for changing:
- The default method of choosing axis limits is IME really, really
annoying, because of the way it tries to find "round number"
boundaries. It's a clever idea, but in practice I've almost never seen
this pick axis limits that are particularly meaningful for my data,
and frequently it picks particularly bad ones. For example, suppose
you want to plot the spectrum of a signal; because of FFT's preference
for power-of-two sizes works it's natural to end up with samples
ranging from 0 to 255. If you plot this, matplotlib will give you an
xlim of (0, 300), which looks pretty ridiculous. But even worse is the
way this method of choosing xlims can actually obscure data -- if the
extreme values in your data set happen to fall exactly on a "round
number", then this will be used as the axis limits, and you'll end up
with data plotted directly underneath the axis spine. I frequently
encounter this when making scatter plots of data in the 0-1 range --
the points located at exactly 0 and 1 are very important to see, but
are nearly invisible by default. A similar case I ran into recently
was when plotting autocorrelation functions for different signals. For
reference I wanted to include the theoretically ideal ACF for white
noise, which looks like this:
 plt.plot(np.arange(1000), [1] + [0] * 999)
Good luck reading that plot!
R's default rule for deciding axis limits is very simple: extend the
data range by 4% on each side; those are your limits. IME this rule --
while obviously not perfect -- always produces something readable and
unobjectionable.
- Axis tickmarks should point outwards rather than inwards: There's
really no advantage to making them point inwards, and pointing inwards
means they can obscure data. My favorite example of this is plotting a
histogram with 100 bins -- that's an obvious thing to do, right? Check
it out:
 plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
This makes me do a double-take every few months until I remember
what's going on: "WTF why is the bar on the left showing a *stacked*
barplot...ohhhhh right those are just the ticks, which happen to be
exactly the same width as the bar." Very confusing.
Seaborn's built-in themes give you the options of (1) no axis ticks at
all, just a background grid (by default the white-on-light-grey grid
as popularized by ggplot2), (2) outwards pointing tickmarks. Either
option seems like a better default to me!
- Default line colors: The rgbcmyk color cycle for line plots doesn't
appear to be based on any real theory about visualization -- it's just
the corners of the RGB color cube, which is a highly perceptually
non-uniform space. The resulting lines aren't terribly high contrast
against the default white background, and the different colors have
varying luminance that makes some lines "pop out" more than others.
Seaborn's default is to use a nice isoluminant variant on matplotlib's default:
 http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
ggplot2 uses isoluminant colors with maximally-separated hues, which
also works well. E.g.:
 http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
- Line thickness: basically every time I make a line plot I wish the
lines were thicker. This is another thing that seaborn simply changes
unconditionally.
In general I guess we could do a lot worse than to simply adopt
seaborn's defaults as the matplotlib defaults :-) Their full list of
overrides can be seen here:
 https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
 https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
- Dash styles: a common recommendation for line plots is to
simultaneously vary both the color and the dash style of your lines,
because redundant cues are good and dash styles are more robust than
color in the face of greyscale printing etc. But every time I try to
follow this advice I find myself having to define new dashes from
scratch, because matplotlib's default dash styles ("-", "--", "-.",
":") have wildly varying weights; in particular I often find it hard
to even see the dots in the ":" and "-." styles. Here's someone with a
similar complaint:
 http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
Just as very rough numbers, something along the lines of "--" = [7,
4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
It might also make sense to consider baking the advice I mentioned
above into matplotlib directly, and having a non-trivial dash cycle
enabled by default. (So the first line plotted uses "-", second uses
"--" or similar, etc.) This would also have the advantage that if we
make the length of the color cycle and the dash cycle relatively
prime, then we'll dramatically increase the number of lines that can
be plotted on the same graph with distinct appearances. (I often run
into the annoying situation where I throw up a quick-and-dirty plot,
maybe with something like pandas's dataframe.plot(), and then discover
that I have multiple indistinguishable lines.)
Obviously one could quibble with my specific proposals here, but does
in general seem like a useful thing to do?
-n
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

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?
Eric
>
> -n
>
> [1] https://github.com/matplotlib/matplotlib/issues/875
> [2] http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
> [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
> of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
> the perceptual distance between two RGB colors. It's also possible to
> use the underlying color model stuff to do things like generate colors
> with evenly spaced luminance and hues, or draw 3d plots of the shape
> of the human color space. It's pretty fun to play with :-)
>

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?
-n
[1] https://github.com/matplotlib/matplotlib/issues/875
[2] http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
[3] https://github.com/njsmith/pycam02ucs ; install (or just run out
of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
the perceptual distance between two RGB colors. It's also possible to
use the underlying color model stuff to do things like generate colors
with evenly spaced luminance and hues, or draw 3d plots of the shape
of the human color space. It's pretty fun to play with :-)
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

I am a bit wary of doing a 2.0 _just_ to change the color map, but when
every I try to write out why, they don't sound convincing. We may end up
with a 3.0 within a year or so due to the possible plotting API/pyplot work
that is (hopefully) coming.
If we are going to do this, I think we should do the 1.4.3 release
(scheduled for Feb 1, RCs in mid January), then put one commit to change
the color map on top of that, tag 2.0 and then master turns into 2.1.x
(targeted for right after scipy?).
There is also the thought to get the major c++ refactor work tagged and
released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
2.0 in Feb with 2.0 based off of 1.5 not 1.4.
On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben...@ou...> wrote:
> As a point of clarification, is this proposed 2.0 release different from
> the 1.5 release?
>
> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...> wrote:
>
>> Many of you will be aware of there has been an ongoing issue (#875,
>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the default
>> colormap in matplotlib.
>>
>> The argument against Jet is compelling and I think that as a group who
>> care about high quality visualisation we should be seriously discussing how
>> matplotlib can move beyond Jet.
>>
>> There was recently an open letter to the climate science community
>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking for
>> scientists to "pledge" against using rainbow like colormaps (such as Jet),
>> and there are similar initiatives in other scientific fields, as well as
>> there being a plethora of well researched literature on the subject.
>>
>> As such, it's time to agree on a solution on how matplotlib can reach the
>> end of the rainbow.
>>
>>
>> The two major hurdles, AFAICS, to replacing the three little characters
>> which control the default colormap of matplotlib are:
>>
>> * We haven't had a clear (decisive) discussion about what we should
>> replace Jet with.
>> * There are concerns about changing the default as it would change the
>> existing widespread behaviour.
>>
>> To address the first point I'll start a new mailinglist thread (entitled
>> "Matplotlib's new default colormap") where new default colormap suggestions
>> can be made. The thread should strictly avoid "+1" type comments, and
>> generally try to stick to reference-able/demonstrable fact, rather than
>> opinion. There *will* be a difference of opinion, however the final
>> decision has to come down to the project lead (sorry Mike) who I know will
>> do whatever is necessary to make the best choice for matplotlib.
>>
>> The second point is a reasonable response when we consider that
>> matplotlib as a project has no *clear* statement on backwards
>> compatibility. As a result, matplotlib is highly change averse between
>> minor releases (to use semantic versioning terms) and therefore changing
>> the default colormap is unpalatable in the v1.x release series. As a result
>> I'd like to propose that the next release of matplotlib be called 2.0, with
>> the *only* major backwards-incompatible change be the removal of Jet as
>> the default colormap.
>>
>> As a project matplotlib mustn't get caught up in the trap of shying away
>> from a major version release when the need arises, and in my opinion
>> helping our users to avoid using a misleading colormap is a worthy cause
>> for a v2.0.
>>
>> Please try to keep this thread on the "how", and not on the "what" of the
>> replacement default colormap, for which there is a dedicated thread.
>>
>> Thanks,
>>
>> Phil
>>
>> (#endrainbow)
>>
>>
>> ------------------------------------------------------------------------------
>> 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=157005751&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=157005751&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

As a point of clarification, is this proposed 2.0 release different from
the 1.5 release?
On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...> wrote:
> Many of you will be aware of there has been an ongoing issue (#875,
> http://goo.gl/xLZvuL) which recommends the removal of Jet as the default
> colormap in matplotlib.
>
> The argument against Jet is compelling and I think that as a group who
> care about high quality visualisation we should be seriously discussing how
> matplotlib can move beyond Jet.
>
> There was recently an open letter to the climate science community
> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking for
> scientists to "pledge" against using rainbow like colormaps (such as Jet),
> and there are similar initiatives in other scientific fields, as well as
> there being a plethora of well researched literature on the subject.
>
> As such, it's time to agree on a solution on how matplotlib can reach the
> end of the rainbow.
>
>
> The two major hurdles, AFAICS, to replacing the three little characters
> which control the default colormap of matplotlib are:
>
> * We haven't had a clear (decisive) discussion about what we should
> replace Jet with.
> * There are concerns about changing the default as it would change the
> existing widespread behaviour.
>
> To address the first point I'll start a new mailinglist thread (entitled
> "Matplotlib's new default colormap") where new default colormap suggestions
> can be made. The thread should strictly avoid "+1" type comments, and
> generally try to stick to reference-able/demonstrable fact, rather than
> opinion. There *will* be a difference of opinion, however the final
> decision has to come down to the project lead (sorry Mike) who I know will
> do whatever is necessary to make the best choice for matplotlib.
>
> The second point is a reasonable response when we consider that matplotlib
> as a project has no *clear* statement on backwards compatibility. As a
> result, matplotlib is highly change averse between minor releases (to use
> semantic versioning terms) and therefore changing the default colormap is
> unpalatable in the v1.x release series. As a result I'd like to propose
> that the next release of matplotlib be called 2.0, with the *only* major
> backwards-incompatible change be the removal of Jet as the default colormap.
>
> As a project matplotlib mustn't get caught up in the trap of shying away
> from a major version release when the need arises, and in my opinion
> helping our users to avoid using a misleading colormap is a worthy cause
> for a v2.0.
>
> Please try to keep this thread on the "how", and not on the "what" of the
> replacement default colormap, for which there is a dedicated thread.
>
> Thanks,
>
> Phil
>
> (#endrainbow)
>
>
> ------------------------------------------------------------------------------
> 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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

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
Darren

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".
It is accepted that there can never be a *best* colormap for *all* data, so
some documentation on choosing an appropriate colormap for specific data
should always be sought. Nonetheless, matplotlib does need a default, and
it has been shown just how damaging the Jet (matplotlib's current default)
colormap really is, so we need to come up with a genuine alternative.
To keep this thread as useful as possible please avoid posting "+1" type
messages. If you'd like to suggest a colormap for consideration as
matplotlib's new *default* please try to keep to
reference-able/demonstrable fact.
Thanks,
Phil

Many of you will be aware of there has been an ongoing issue (#875,
http://goo.gl/xLZvuL) which recommends the removal of Jet as the default
colormap in matplotlib.
The argument against Jet is compelling and I think that as a group who care
about high quality visualisation we should be seriously discussing how
matplotlib can move beyond Jet.
There was recently an open letter to the climate science community
<http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking for
scientists to "pledge" against using rainbow like colormaps (such as Jet),
and there are similar initiatives in other scientific fields, as well as
there being a plethora of well researched literature on the subject.
As such, it's time to agree on a solution on how matplotlib can reach the
end of the rainbow.
The two major hurdles, AFAICS, to replacing the three little characters
which control the default colormap of matplotlib are:
 * We haven't had a clear (decisive) discussion about what we should
replace Jet with.
 * There are concerns about changing the default as it would change the
existing widespread behaviour.
To address the first point I'll start a new mailinglist thread (entitled
"Matplotlib's new default colormap") where new default colormap suggestions
can be made. The thread should strictly avoid "+1" type comments, and
generally try to stick to reference-able/demonstrable fact, rather than
opinion. There *will* be a difference of opinion, however the final
decision has to come down to the project lead (sorry Mike) who I know will
do whatever is necessary to make the best choice for matplotlib.
The second point is a reasonable response when we consider that matplotlib
as a project has no *clear* statement on backwards compatibility. As a
result, matplotlib is highly change averse between minor releases (to use
semantic versioning terms) and therefore changing the default colormap is
unpalatable in the v1.x release series. As a result I'd like to propose
that the next release of matplotlib be called 2.0, with the *only* major
backwards-incompatible change be the removal of Jet as the default colormap.
As a project matplotlib mustn't get caught up in the trap of shying away
from a major version release when the need arises, and in my opinion
helping our users to avoid using a misleading colormap is a worthy cause
for a v2.0.
Please try to keep this thread on the "how", and not on the "what" of the
replacement default colormap, for which there is a dedicated thread.
Thanks,
Phil
(#endrainbow)

Good idea. I'll put together something tonight.
On Thu, Nov 20, 2014 at 2:44 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年11月18日, 9:55 PM, Benjamin Root wrote:
> > Why do we have a function in setupext.py called
> > "hardcoded_tcl_config()"? In any case, it looks like all I needed to do
> > was change the default value for line 156 to be the prefix location of
> > my miniconda install, and things started to work again!
> >
> > Perhaps we need to take another look through setupext.py, and try to get
> > it using prefixes more (or at least consolidate all of these hard-coded
> > values into one place!)
>
> Ben,
>
> Good idea; perhaps you would like to turn it into a github issue to
> reduce the likelihood it is dropped.
>
> Eric
>
> >
> > Cheers!
> > Ben Root
> >
> >
> > On Tue, Nov 18, 2014 at 12:06 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> > Indeed, there are some oddities, but mostly with regards to Qt and
> > forcing it to build and link against (presumedly) the conda package
> > of it. There is a modification of the setupext.py that happens at
> > build time to replace all instances of "/usr/local" with "$PREFIX".
> > Perhaps what is happening is that my local builds of matplotlib is
> > compiling and linking against my system install of the tk/tcl
> > headers and libraries, and that might be conflicting with the
> > conda-shipped tk/tcl packages?
> >
> > I'll have to experiment a bit more tonight. Thanks for the
> suggestion!
> >
> > Ben Root
> >
> > On Mon, Nov 17, 2014 at 11:07 PM, Thomas Caswell <tca...@gm...
> > <mailto:tca...@gm...>> wrote:
> >
> > Have a look at the recipe in conda-rescipes for matplotlib, they
> > might be doing some funny patching.
> >
> > On Mon, Nov 17, 2014, 22:48 Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> > Ok, I am just really confused now. I have confirmed that
> > using the matplotlib supplied by miniconda (v1.4.2) works
> > just fine. Ripping that out and building version 1.4.2 from
> > source results in the traceback. Same thing for v1.3.1. I
> > have even tried checking out PR#3811 which addresses the
> > weird constructor issues we found today, and I still get the
> > segfault.
> >
> > Maybe I should try getting out of the conda environment
> > entirely and try EPD instead to see if that makes a
> difference?
> >
> > Ben Root
> >
> > On Mon, Nov 17, 2014 at 5:17 AM, Phil Elson
> > <pel...@gm... <mailto:pel...@gm...>> wrote:
> >
> > Mike made some changes to this recently.
> > https://github.com/matplotlib/matplotlib/pull/3778
> >
> > May be the cause.
> >
> > On 16 November 2014 18:12, Benjamin Root
> > <ben...@ou... <mailto:ben...@ou...>> wrote:
> >
> > And with my continuing saga of backend-specific
> > things...
> >
> > I was using conda, but because it does not ship with
> > pygtk support, I had to manually install pygtk into
> > the conda environment and then install matplotlib
> > from source. All that seemed to work fine when I
> > worked on Wx and Gtk examples for my book.
> >
> > I went back to a (previously working) Tk example to
> > polish it, and I get all sorts of errors now. I have
> > tried multiple releases of matplotlib from source
> > (doing a git clean -fxd between them), all with
> > similar errors. In fact, with master, the error
> > causes a segfault:
> >
> > ben@tigger:~/Documents/InteractiveMPL$ python
> > chp5/slider_tk.py
> > Exception in Tkinter callback
> > Traceback (most recent call last):
> > File
> >
> "/home/ben/miniconda/lib/python2.7/lib-tk/Tkinter.py",
> > line 1486, in __call__
> > return self.func(*args)
> > File
> >
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> > line 278, in resize
> > self.show()
> > File
> >
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> > line 350, in draw
> > tkagg.blit(self._tkphoto,
> > self.renderer._renderer, colormode=2)
> > File
> >
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/tkagg.py",
> > line 30, in blit
> > id(data), colormode, id(bbox_array))
> > TclError
> > alloc: invalid block: 0x2cfe3b0: 0 0
> > Aborted (core dumped)
> >
> > The line in question is (at least in v1.3.1, it is
> > slightly different in more recent versions):
> > tk.call("PyAggImagePhoto", photoimage, id(aggimage),
> > colormode, id(bbox_array))
> >
> > This happens regardless of what example I use (my
> > own or otherwise). There is no blit-specific code in
> > the examples. All of this worked with the
> > conda-supplied matplotlib, but never the
> > from-source-into-a-conda-environment install.
> >
> > Thoughts?
> > Ben Root
> >
> >
> ------------------------------------------------------------------------------
> > Comprehensive Server Monitoring with Site24x7.
> > Monitor 10 servers for 9ドル/Month.
> > Get alerted through email, SMS, voice calls or
> > mobile push notifications.
> > Take corrective actions from your mobile device.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > <mailto: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=157005751&__iu=/4140/ostg.clktrk
> > <
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&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=157005751&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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2014年11月18日, 9:55 PM, Benjamin Root wrote:
> Why do we have a function in setupext.py called
> "hardcoded_tcl_config()"? In any case, it looks like all I needed to do
> was change the default value for line 156 to be the prefix location of
> my miniconda install, and things started to work again!
>
> Perhaps we need to take another look through setupext.py, and try to get
> it using prefixes more (or at least consolidate all of these hard-coded
> values into one place!)
Ben,
Good idea; perhaps you would like to turn it into a github issue to 
reduce the likelihood it is dropped.
Eric
>
> Cheers!
> Ben Root
>
>
> On Tue, Nov 18, 2014 at 12:06 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> Indeed, there are some oddities, but mostly with regards to Qt and
> forcing it to build and link against (presumedly) the conda package
> of it. There is a modification of the setupext.py that happens at
> build time to replace all instances of "/usr/local" with "$PREFIX".
> Perhaps what is happening is that my local builds of matplotlib is
> compiling and linking against my system install of the tk/tcl
> headers and libraries, and that might be conflicting with the
> conda-shipped tk/tcl packages?
>
> I'll have to experiment a bit more tonight. Thanks for the suggestion!
>
> Ben Root
>
> On Mon, Nov 17, 2014 at 11:07 PM, Thomas Caswell <tca...@gm...
> <mailto:tca...@gm...>> wrote:
>
> Have a look at the recipe in conda-rescipes for matplotlib, they
> might be doing some funny patching.
>
> On Mon, Nov 17, 2014, 22:48 Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
> Ok, I am just really confused now. I have confirmed that
> using the matplotlib supplied by miniconda (v1.4.2) works
> just fine. Ripping that out and building version 1.4.2 from
> source results in the traceback. Same thing for v1.3.1. I
> have even tried checking out PR#3811 which addresses the
> weird constructor issues we found today, and I still get the
> segfault.
>
> Maybe I should try getting out of the conda environment
> entirely and try EPD instead to see if that makes a difference?
>
> Ben Root
>
> On Mon, Nov 17, 2014 at 5:17 AM, Phil Elson
> <pel...@gm... <mailto:pel...@gm...>> wrote:
>
> Mike made some changes to this recently.
> https://github.com/matplotlib/matplotlib/pull/3778
>
> May be the cause.
>
> On 16 November 2014 18:12, Benjamin Root
> <ben...@ou... <mailto:ben...@ou...>> wrote:
>
> And with my continuing saga of backend-specific
> things...
>
> I was using conda, but because it does not ship with
> pygtk support, I had to manually install pygtk into
> the conda environment and then install matplotlib
> from source. All that seemed to work fine when I
> worked on Wx and Gtk examples for my book.
>
> I went back to a (previously working) Tk example to
> polish it, and I get all sorts of errors now. I have
> tried multiple releases of matplotlib from source
> (doing a git clean -fxd between them), all with
> similar errors. In fact, with master, the error
> causes a segfault:
>
> ben@tigger:~/Documents/InteractiveMPL$ python
> chp5/slider_tk.py
> Exception in Tkinter callback
> Traceback (most recent call last):
> File
> "/home/ben/miniconda/lib/python2.7/lib-tk/Tkinter.py",
> line 1486, in __call__
> return self.func(*args)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> line 278, in resize
> self.show()
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py",
> line 350, in draw
> tkagg.blit(self._tkphoto,
> self.renderer._renderer, colormode=2)
> File
> "/home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/tkagg.py",
> line 30, in blit
> id(data), colormode, id(bbox_array))
> TclError
> alloc: invalid block: 0x2cfe3b0: 0 0
> Aborted (core dumped)
>
> The line in question is (at least in v1.3.1, it is
> slightly different in more recent versions):
> tk.call("PyAggImagePhoto", photoimage, id(aggimage),
> colormode, id(bbox_array))
>
> This happens regardless of what example I use (my
> own or otherwise). There is no blit-specific code in
> the examples. All of this worked with the
> conda-supplied matplotlib, but never the
> from-source-into-a-conda-environment install.
>
> Thoughts?
> Ben Root
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for 9ドル/Month.
> Get alerted through email, SMS, voice calls or
> mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto: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=157005751&__iu=/4140/ostg.clktrk
> <http://pubads.g.doubleclick.net/gampad/clk?id=157005751&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=157005751&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Ah, never mind then, I just got out of sync.
On Wed, Nov 19, 2014, 04:04 Joel B. Mohler <jo...@ki...> wrote:
> On 11/18/2014 08:29 PM, Thomas Caswell wrote:
>
> Is there an issue for this (and if not can you make one)?
>
>
> This is https://github.com/matplotlib/matplotlib/pull/3811 which is fixed
> and merged. Should it still be an issue?
>
>
>
> On Mon, Nov 17, 2014, 09:56 Joel B. Mohler <jo...@ki...> wrote:
>
>> On Mon, Nov 17, 2014 at 09:36:50AM -0500, Joel B. Mohler wrote:
>> > I think I see a breakage of the scatter call that I think should work
>> and did
>> > work before
>> >
>> https://github.com/matplotlib/matplotlib/commit/be34210a8c09fcd639ece583eb5c0acb855222b6
>> >
>> > This is running on windows 7 (32 bit) with numpy 1.8 and current master.
>>
>> Ugh, I tried this same example on my ubuntu box and it works. I update
>> this
>> diagnosis to "scatter is broken on windows since removing PyCXX"; note
>> that I
>> do not get a traceback with the code below if I replace "scatter" with
>> "plot".
>>
>> Being that windows devs are scarce, I'll be digging into this more. I
>> certainly welcome any clues as it seems very bizarre to me so far.
>>
>> Joel
>>
>> >
>> > The example is:
>> >
>> > ***
>> > import numpy
>> > from matplotlib.backends.backend_agg import FigureCanvasAgg as
>> FigureCanvas
>> > from matplotlib.figure import Figure
>> >
>> > POINTS = 500
>> >
>> > figure = Figure(figsize=(6, 6), dpi=72)
>> > ax = figure.add_subplot(1, 1, 1, projection=None)
>> > scat = ax.scatter(numpy.arange(POINTS), numpy.sin(numpy.arange(POINTS)))
>> > ***
>> >
>> > I get on current master
>> >
>> > ***
>> > Traceback (most recent call last):
>> > File "C:\work\mpl_scatter_example.py", line 9, in <module>
>> > scat = ax.scatter(numpy.arange(POINTS),
>> numpy.sin(numpy.arange(POINTS)))
>> > File "C:\Python27\lib\site-packages\matplotlib\axes\_axes.py", line
>> 3690, in scatter
>> > self.add_collection(collection)
>> > File "C:\Python27\lib\site-packages\matplotlib\axes\_base.py", line
>> 1459, in add_collection
>> > self.update_datalim(collection.get_datalim(self.transData))
>> > File "C:\Python27\lib\site-packages\matplotlib\collections.py", line
>> 198, in get_datalim
>> > offsets, transOffset.frozen())
>> > File "C:\Python27\lib\site-packages\matplotlib\path.py", line 977, in
>> get_path_collection_extents
>> > master_transform, paths, transforms, offsets,offset_transform))
>> > ValueError: object too deep for desired array
>> > ***
>> >
>> > I did very little troubleshooting beyond confirming that this works
>> before the
>> > merge mentioned in the first paragraph.
>> >
>> > Joel
>>
>>
>> ------------------------------------------------------------------------------
>> 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=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

On 11/18/2014 08:29 PM, Thomas Caswell wrote:
> Is there an issue for this (and if not can you make one)?
This is https://github.com/matplotlib/matplotlib/pull/3811 which is 
fixed and merged. Should it still be an issue?
>
> On Mon, Nov 17, 2014, 09:56 Joel B. Mohler <jo...@ki... 
> <mailto:jo...@ki...>> wrote:
>
> On Mon, Nov 17, 2014 at 09:36:50AM -0500, Joel B. Mohler wrote:
> > I think I see a breakage of the scatter call that I think should
> work and did
> > work before
> >
> https://github.com/matplotlib/matplotlib/commit/be34210a8c09fcd639ece583eb5c0acb855222b6
> >
> > This is running on windows 7 (32 bit) with numpy 1.8 and current
> master.
>
> Ugh, I tried this same example on my ubuntu box and it works. I
> update this
> diagnosis to "scatter is broken on windows since removing PyCXX";
> note that I
> do not get a traceback with the code below if I replace "scatter"
> with "plot".
>
> Being that windows devs are scarce, I'll be digging into this more. I
> certainly welcome any clues as it seems very bizarre to me so far.
>
> Joel
>
> >
> > The example is:
> >
> > ***
> > import numpy
> > from matplotlib.backends.backend_agg import FigureCanvasAgg as
> FigureCanvas
> > from matplotlib.figure import Figure
> >
> > POINTS = 500
> >
> > figure = Figure(figsize=(6, 6), dpi=72)
> > ax = figure.add_subplot(1, 1, 1, projection=None)
> > scat = ax.scatter(numpy.arange(POINTS),
> numpy.sin(numpy.arange(POINTS)))
> > ***
> >
> > I get on current master
> >
> > ***
> > Traceback (most recent call last):
> > File "C:\work\mpl_scatter_example.py", line 9, in <module>
> > scat = ax.scatter(numpy.arange(POINTS),
> numpy.sin(numpy.arange(POINTS)))
> > File "C:\Python27\lib\site-packages\matplotlib\axes\_axes.py",
> line 3690, in scatter
> > self.add_collection(collection)
> > File "C:\Python27\lib\site-packages\matplotlib\axes\_base.py",
> line 1459, in add_collection
> > self.update_datalim(collection.get_datalim(self.transData))
> > File
> "C:\Python27\lib\site-packages\matplotlib\collections.py", line
> 198, in get_datalim
> > offsets, transOffset.frozen())
> > File "C:\Python27\lib\site-packages\matplotlib\path.py", line
> 977, in get_path_collection_extents
> > master_transform, paths, transforms, offsets,offset_transform))
> > ValueError: object too deep for desired array
> > ***
> >
> > I did very little troubleshooting beyond confirming that this
> works before the
> > merge mentioned in the first paragraph.
> >
> > Joel
>
> ------------------------------------------------------------------------------
> 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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>