Re: [matplotlib-devel] Better defaults all around?

[Nicolas P. Rougier]

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

Re: [matplotlib-devel] How to move beyond JET as the default matplotlib colormap

[Phil Elson]

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

Re: [matplotlib-devel] Better defaults all around?

[Todd]

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" 
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  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 <
> ariza.feder...@gmail.com> 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"  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  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
> > defaul

Re: [matplotlib-devel] Better defaults all around?

[gary ruben]

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 
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  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 <
> ariza.feder...@gmail.com> 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 don

Re: [matplotlib-devel] How to move beyond JET as the default matplotlib colormap

[Benjamin Root]

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

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

[gary ruben]

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

> On 2014/11/21, 4:42 PM, Nathaniel Smith wrote:
> > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale  wrote:
> >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson 
> 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 m

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

[Thomas Caswell]

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  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  wrote:
>
>> On 2014/11/21, 4:42 PM, Nathaniel Smith wrote:
>> > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale 
>> wrote:
>> >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson 
>> 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-annot

[matplotlib-devel] chicken/egg (or figure/canvas) question

[Benjamin 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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] chicken/egg (or figure/canvas) question

[Benjamin 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  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
>
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] cocoaagg figure not have a navigation toolbar?

[Benjamin Root]

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
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel