matplotlib-devel Mailing List for matplotlib

This should probably be changed to use the new and improved container class
(along with error bar), but I should read the code to be sure.
On Mon, Feb 23, 2015, 11:44 Benjamin Root <ben...@ou...> wrote:
> Huh, how about that. ContourSet subclasses ScalarMappable, but not Artist.
> I don't know if that is intentional or not, but given that most plotting
> functions return artists, this would seem to be an anomaly. FuncAnimation
> expects a list of Artists. Since QuadContourSet is (apparently) not an
> Artist, then that is why it isn't working quite right.
>
> As for blitting, I doubt you are going to need it here. Blitting is really
> only advantagous if the computation/draw time of the animated portion is
> comparable to the computation/draw time of the unanimated portion.
> Contouring tends to be time-consuming (relatively speaking), so I doubt you
> will gain much benefit from blitting it.
>
> Ben Root
>
> On Mon, Feb 23, 2015 at 8:53 AM, Ignat Harczuk <ig...@gm...> wrote:
>
>> Firstly I would like to apologize in case this should belong in the
>> matplotlib-users, I'm not sure if this is dev or users related.
>>
>>
>> Let us say we want to animate a 2D contour plot, then passing the blit =
>> True argument to FuncAnimation fails since the QuadContourSet has no axes
>> attribute.
>>
>> Is it for some specific it is implemented like this? And maybe there a
>> hack to get this to work?
>>
>> A working code example with the actually wanted one commented out.
>>
>> import numpy as np
>> import matplotlib.animation as animation
>> from matplotlib import pyplot as plt
>>
>> fig, ax = plt.subplots()
>>
>> x = np.linspace( -np.pi, np.pi, 50 )
>> y = np.linspace( -np.pi, np.pi, 50 )
>> X, Y = np.meshgrid( x, y )
>> Z = np.zeros( X.shape )
>>
>> def init():
>> cont = ax.contourf( X, Y, Z )
>> cbar = plt.colorbar( cont )
>> return cont,
>>
>> def animate( t ):
>> k = np.array( [1,1] )
>> omega = 0.5
>>
>> x = np.linspace( -np.pi, np.pi, 50 )
>> y = np.linspace( -np.pi, np.pi, 50 )
>> X, Y = np.meshgrid( x, y )
>> Z = np.exp( 1j * (omega* t - X*k[0] ) ) * np.exp( - 1j * k[1]*Y )
>> cont = ax.contourf( X, Y, Z )
>> return cont,
>>
>> #ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
>> repeat = False, blit = True, init_func = init,)
>> ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
>> repeat = False, init_func = init,)
>> plt.show()
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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=190641631&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=190641631&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2015年02月18日 2:39 PM, Nathaniel Smith wrote:
> On Feb 16, 2015 3:39 PM, "Eric Firing" <ef...@ha...> wrote:
>>
>> On 2015年02月16日 1:29 PM, Michael Waskom wrote:
>>
>>> Nathaniel's January 9 message in that thread (can't figure out how to
>>> link to it in the archives) had a suggestion that I thought was very
>>> promising, to do something similar to Parula but rotate around the hue
>>> circle the other direction so that the hues would go blue - purple - red
>>> - yellow. I don't think we've seen an example of exactly what it would
>>> look like, but I reckon it would be similar to the middle colormap here
>>> http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
>>> (from the elegant figures block series linked above), which I've always
>>> found quite attractive.
>>
>> Certainly it can be considered--but we have to have a real implementation.
>
> While I hate to promise vaporware, I actually was planning to have a
> go at implementing such a colormap in the next few weeks, based on
> optimizing the same set of parameters that viscm visualizes... FWIW.
It might be worth quite a bit--and the sooner, the better.
>
> Are we planning to make other default appearance changes at the same
> time? The idea of changing the color cycle and/or dot-dash cycle has
> already come up in this thread, and this earlier thread proposed
> several more good ideas [1]:
> http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166
Thank you for the link. The ideas certainly deserve review at this 
point. There is some danger in that the more things we try to change, 
the harder it might be to approach consensus.
>
> I agree that now is definitely the time to get serious about making
> these changes, but it seems like there's enough to be worked out that
> sticking to the original plan and keeping mainline quasi-frozen until
> 2.0 is ready might create frustration and hasty decisions. Maybe it
> would be less stressful all around if we let mainline development
> proceed at whatever pace makes sense while these things get sorted
> out, and then once the appearance changes are ready make the call
> about whether to cut a quick 1.5 first or not? Presumably these
> defaults will stick around for many years so it's worth taking a few
> months to get a complete proposal together, get feedback, etc., IMO.
Good point; this can work provided we can keep the momentum up, so that 
we actually converge on a feasible proposal.
>
> In an ideal world version 1.last might even provide a
> style.use("matplotlib2") command to preview what 2.0 will do, just
> like 2.0 will presumably have a style.use("matplotlib1") command for
> those who want to (temporarily) revert.
I like this style-based preview idea.
Eric
>
> -n
>
> [1] well I would think that wouldn't I ;-)
>

My eyes are definitely favoring the L20-80 over the L5-95 colormaps. Does
Luminosity take into account human's non-linearity in perceiving
brightness? I remember a few years ago many of the open-source graphics
tools (such as GIMP) had to be fixed because it assumed a linear brightness
perception. IIRC, humans are better at perceiving brightness gradients on
one end of the range than on the other end.
On Mon, Feb 23, 2015 at 1:30 PM, Eric Firing <ef...@ha...> wrote:
> On 2015年02月23日 8:16 AM, Benjamin Root wrote:
> > Interesting choices, and I think we are on the right paths (no pun
> > intended) through the two possible colors. However, I think the same
> > problem arises that I noted before. Both ends of the colormap are nearly
> > black to nearly white. IIRC, our perception of luminosity has a much
> > greater range than it does for chroma. While it is nice to take
> > advantage of that, I wonder if we are going too far in the luminosity
> > range? Perhaps these colormaps would be better if the luminosity range
> > wasn't as full as it is here?
> >
> > Ben Root
>
> Ben,
>
> I was noticing the same thing, except that at least on my screen, the
> problem is mainly at the dark end, and it varies with the actual set of
> control points. The very last one, for example (Purple Red Yellow
> L5-95) has what looks like a fairly linear ramp from end to end on my
> screen, while "Blue Green Yellow L10-90" lacks contrast on the dark end.
> I suspect all this will be quite dependent on the particular screen
> (or printer--including the whole chain of color conversions ending up in
> ink or toner dots) being used. It doesn't look to me like a problem
> with the luminosity range as such. We have a highly nonlinear problem
> here.
>
> In any case, this looks like a nice tool. Maybe it can be combined with
> Nathaniel's code, which shows other aspects of the colormap?
>
> Eric
>
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2015年02月23日 8:16 AM, Benjamin Root wrote:
> Interesting choices, and I think we are on the right paths (no pun
> intended) through the two possible colors. However, I think the same
> problem arises that I noted before. Both ends of the colormap are nearly
> black to nearly white. IIRC, our perception of luminosity has a much
> greater range than it does for chroma. While it is nice to take
> advantage of that, I wonder if we are going too far in the luminosity
> range? Perhaps these colormaps would be better if the luminosity range
> wasn't as full as it is here?
>
> Ben Root
Ben,
I was noticing the same thing, except that at least on my screen, the 
problem is mainly at the dark end, and it varies with the actual set of 
control points. The very last one, for example (Purple Red Yellow 
L5-95) has what looks like a fairly linear ramp from end to end on my 
screen, while "Blue Green Yellow L10-90" lacks contrast on the dark end. 
 I suspect all this will be quite dependent on the particular screen 
(or printer--including the whole chain of color conversions ending up in 
ink or toner dots) being used. It doesn't look to me like a problem 
with the luminosity range as such. We have a highly nonlinear problem here.
In any case, this looks like a nice tool. Maybe it can be combined with 
Nathaniel's code, which shows other aspects of the colormap?
Eric

Interesting choices, and I think we are on the right paths (no pun
intended) through the two possible colors. However, I think the same
problem arises that I noted before. Both ends of the colormap are nearly
black to nearly white. IIRC, our perception of luminosity has a much
greater range than it does for chroma. While it is nice to take advantage
of that, I wonder if we are going too far in the luminosity range? Perhaps
these colormaps would be better if the luminosity range wasn't as full as
it is here?
Ben Root
On Mon, Feb 23, 2015 at 12:36 PM, Pierre Haessig <pie...@cr...>
wrote:
> Hi,
>
> Le 16/02/2015 23:01, Eric Firing a écrit :
> > For a long time there has been discussion of replacing the matplotlib
> > default color map [...]
> I've started building a small interactive Lab point editor to build a
> sequential colormap.
> https://github.com/pierre-haessig/lab-colormap-creator
>
> The main interest of it is the ability to quickly check that the points
> stay in the sRGB gamut.
>
> There are some colormap results I just got this afternoon with it in the
> companion notebook
> (
> http://nbviewer.ipython.org/github/pierre-haessig/lab-colormap-creator/blob/master/test_plots.ipynb
> )
>
> It feels there are indeed only two routes: the Blue-Green-Yellow and the
> Blue-Red-Yellow one. Maybe it is possible to squeeze in a more "snaky"
> path, but it might look weird.
>
> best,
> Pierre
>
>
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi,
Le 16/02/2015 23:01, Eric Firing a écrit :
> For a long time there has been discussion of replacing the matplotlib 
> default color map [...]
I've started building a small interactive Lab point editor to build a
sequential colormap.
https://github.com/pierre-haessig/lab-colormap-creator
The main interest of it is the ability to quickly check that the points
stay in the sRGB gamut.
There are some colormap results I just got this afternoon with it in the
companion notebook
(http://nbviewer.ipython.org/github/pierre-haessig/lab-colormap-creator/blob/master/test_plots.ipynb)
It feels there are indeed only two routes: the Blue-Green-Yellow and the
Blue-Red-Yellow one. Maybe it is possible to squeeze in a more "snaky"
path, but it might look weird.
best,
Pierre

Huh, how about that. ContourSet subclasses ScalarMappable, but not Artist.
I don't know if that is intentional or not, but given that most plotting
functions return artists, this would seem to be an anomaly. FuncAnimation
expects a list of Artists. Since QuadContourSet is (apparently) not an
Artist, then that is why it isn't working quite right.
As for blitting, I doubt you are going to need it here. Blitting is really
only advantagous if the computation/draw time of the animated portion is
comparable to the computation/draw time of the unanimated portion.
Contouring tends to be time-consuming (relatively speaking), so I doubt you
will gain much benefit from blitting it.
Ben Root
On Mon, Feb 23, 2015 at 8:53 AM, Ignat Harczuk <ig...@gm...> wrote:
> Firstly I would like to apologize in case this should belong in the
> matplotlib-users, I'm not sure if this is dev or users related.
>
>
> Let us say we want to animate a 2D contour plot, then passing the blit =
> True argument to FuncAnimation fails since the QuadContourSet has no axes
> attribute.
>
> Is it for some specific it is implemented like this? And maybe there a
> hack to get this to work?
>
> A working code example with the actually wanted one commented out.
>
> import numpy as np
> import matplotlib.animation as animation
> from matplotlib import pyplot as plt
>
> fig, ax = plt.subplots()
>
> x = np.linspace( -np.pi, np.pi, 50 )
> y = np.linspace( -np.pi, np.pi, 50 )
> X, Y = np.meshgrid( x, y )
> Z = np.zeros( X.shape )
>
> def init():
> cont = ax.contourf( X, Y, Z )
> cbar = plt.colorbar( cont )
> return cont,
>
> def animate( t ):
> k = np.array( [1,1] )
> omega = 0.5
>
> x = np.linspace( -np.pi, np.pi, 50 )
> y = np.linspace( -np.pi, np.pi, 50 )
> X, Y = np.meshgrid( x, y )
> Z = np.exp( 1j * (omega* t - X*k[0] ) ) * np.exp( - 1j * k[1]*Y )
> cont = ax.contourf( X, Y, Z )
> return cont,
>
> #ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
> repeat = False, blit = True, init_func = init,)
> ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
> repeat = False, init_func = init,)
> plt.show()
>
>
>
> ------------------------------------------------------------------------------
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Firstly I would like to apologize in case this should belong in the
matplotlib-users, I'm not sure if this is dev or users related.
Let us say we want to animate a 2D contour plot, then passing the blit =
True argument to FuncAnimation fails since the QuadContourSet has no axes
attribute.
Is it for some specific it is implemented like this? And maybe there a hack
to get this to work?
A working code example with the actually wanted one commented out.
import numpy as np
import matplotlib.animation as animation
from matplotlib import pyplot as plt
fig, ax = plt.subplots()
x = np.linspace( -np.pi, np.pi, 50 )
y = np.linspace( -np.pi, np.pi, 50 )
X, Y = np.meshgrid( x, y )
Z = np.zeros( X.shape )
def init():
 cont = ax.contourf( X, Y, Z )
 cbar = plt.colorbar( cont )
 return cont,
def animate( t ):
 k = np.array( [1,1] )
 omega = 0.5
 x = np.linspace( -np.pi, np.pi, 50 )
 y = np.linspace( -np.pi, np.pi, 50 )
 X, Y = np.meshgrid( x, y )
 Z = np.exp( 1j * (omega* t - X*k[0] ) ) * np.exp( - 1j * k[1]*Y )
 cont = ax.contourf( X, Y, Z )
 return cont,
#ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
repeat = False, blit = True, init_func = init,)
ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
repeat = False, init_func = init,)
plt.show()