matplotlib-devel Mailing List for matplotlib (Page 2)

Hello,
I have attached a patch that addresses the following:
 plot accepts the linestyles arguments '-','--','-.',':' [+ some more]
and the Collection class accepts the
 linestyle arguments 'solid','dashed','dashdot','dotted'.
This patch allows to use both notations. A test script is attached too. 
So its possible to use
 plot(x,y, linestyle='--') # old (preferred) style
 plot(x,y, linestyle='dashed') # now also possible
and also
 contour(Z, linestyles='dotted') # old style
 contour(Z, linestyles=':') # now also possible
The latter case is probably more useful than the first, but both work.
Any comments ?
Manuel

I'm running Idle via X forwarding to my Windows desktop (running Cygwin).
I've installed tcl/tk and python with Tkinter as a backend.
When I call pylab.show(), I always get the error :
 >>> pylab.show()
Exception in Tkinter callback
Traceback (most recent call last):
 File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
 return self.func(*args)
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 151, in resize
 self.show()
 File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
line 155, in draw
 tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
 File "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", 
line 14, in blit
 _tkagg.tkinit(id(tk), 0)
AttributeError: 'module' object has no attribute 'tkinit'
And an empty matplotlib window opens on my desktop.
Should I try gtk as a backend???
TIA
-- Andrew

Michael Droettboom wrote:
> Sorry -- I see it now. Disregard my earlier message. It is now fixed 
> in SVN r5004.
Hi Michael,
thanks. Unfortunately there is now still some duplicity of text in the 
docs. I've attached a patch (against svn 5008) that fixes this and also 
adds the doc for '+' and 'x' markers which is missing.
Manuel
> Manuel Metz wrote:
>> Happend with your commit from version 4979 -> 4989. Who's going to fix 
>> that ? Whom can I directly contact ?
>>
>> -------- Original Message --------
>> Subject: [matplotlib-devel] axes.py scatter doc-bug
>> Date: 2008年3月12日 12:30:12 +0100
>> From: Manuel Metz <mm...@as...>
>> To: mat...@li...
>> CC: John Hunter <jd...@gm...>
>>
>> Hi,
>> the doc-string of the axes scatter method is buggy. Somehow the
>> svn-conflict messages got committed to the repository:
>> I mean this
>>
>> <<<<<<< .working
>> [...]
>> =======
>> [...]
>> >>>>>>> .merge-right.r4987
>>
>> ... stuff)
>>
>> Manuel
>>

On Tuesday 18 March 2008 02:30:29 pm Michael Droettboom wrote:
> Darren Dale wrote:
> > I discovered another blitting bug in backend_qt4agg.py. Qt expects a
> > pixmap stringBuffer formatted in ARGB, but mpl formats in RGBA. The qt4
> > backend usually uses the _renderer.tostring_bgra method to return a
> > properly formatted buffer:
> >
> > if QtCore.QSysInfo.ByteOrder == QtCore.QSysInfo.LittleEndian:
> > stringBuffer = self.renderer._renderer.tostring_bgra()
> > else:
> > stringBuffer = self.renderer._renderer.tostring_argb()
> >
> > The problem I am seeing is when we are blitting, and the tostring_bgra is
> > not available.
> > The blitting code in backend_qt4agg.py, starting around line 112,
> > gets a buffer from a region copied from a bbox:
> >
> > reg = self.copy_from_bbox(bbox)
> > stringBuffer = reg.to_string()
> > qImage = QtGui.QImage(stringBuffer, w, h, QtGui.QImage.Format_ARGB32)
> >
> > reg does not have a method to swap the byte order, and Qt does not have a
> > Format_RGBA32. Could anyone suggest how to swap the byte order?
>
> There might be some numpy "trick" to massage the data. However, it
> looks to me like BufferRegion (in _backend_agg.cpp) needs to grow a
> byte-swapped version of to_string()... but maybe someone with more
> experience with the Qt backend has a better idea whether this used to
> work and why it may have stopped working.
Thanks for responding. I don't think it ever worked properly with the Qt 
backends. I just dropped back to the maintenance branch to check the 
following script:
from matplotlib import rcParams
rcParams['backend']='qt4agg'
from pylab import *
from matplotlib.widgets import Cursor
ax=axes()
ax.plot([1, 2, 3, 4, 5], 'ro', ms=10)
cursor = Cursor(ax, useblit=True)
show()
and it shows the same behavior.
Darren

Sorry -- I see it now. Disregard my earlier message. It is now fixed 
in SVN r5004.
Manuel Metz wrote:
> Happend with your commit from version 4979 -> 4989. Who's going to fix 
> that ? Whom can I directly contact ?
>
> -------- Original Message --------
> Subject: [matplotlib-devel] axes.py scatter doc-bug
> Date: 2008年3月12日 12:30:12 +0100
> From: Manuel Metz <mm...@as...>
> To: mat...@li...
> CC: John Hunter <jd...@gm...>
>
> Hi,
> the doc-string of the axes scatter method is buggy. Somehow the
> svn-conflict messages got committed to the repository:
> I mean this
>
> <<<<<<< .working
> [...]
> =======
> [...]
> >>>>>>> .merge-right.r4987
>
> ... stuff)
>
> Manuel
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ryan May wrote:
> Eric Firing wrote:
> 
>> Ryan,
>>
>> The pcolor implementation is fundamentally unsuited to large arrays. 
>> Therefore I made the pcolorfast axes method, which tries to use the 
>> fastest available Agg extension code, depending on the characteristics 
>> of the spatial grid. If the grid is rectangular and regular in both 
>> directions it uses a slight modification of the image code; if it is 
>> rectangular but with irregular spacing, it uses the nonuniform image 
>> code; and if it is not rectangular it uses the quadmesh code. It sounds 
>> like what you need is the quadmesh version, which you can access either 
>> via pcolormesh or pcolorfast. Neither is exposed via the pylab or 
>> pyplot API at present; both are axes methods. The pcolorfast API also 
>> may change slightly in the future; it probably needs a little more work.
>> 
>
> Yeah, I think for purposes of plotting radar data, quadmesh is what i need.
>
> 
>> The quadmesh code has problems with masked arrays in the released 
>> version of mpl, but not in the svn version. It is *much* faster than 
>> pcolor, but may not be fast enough for your needs.
>> 
>
> My latest testing with the trunk with both pcolorfast and pcolormesh 
> would seem to indicate that it's still a bit too slow for me.
>
> 
>> If you are looking into what sounds like an OpenGL backend, or component 
>> to a backend, then the place to start is still probably pcolormesh or 
>> pcolorfast, not pcolor.
>> 
> This is the approach I'm considering. I've been poking around, and 
> managed to create something that rendered, but not too well. However 
> this was basically modifying the Gtk backend, and I'm sure there are 
> some Gtk things that could be replaced. I noticed there are some other 
> draw_* methods in other backends that aren't in the gtk, like 
> draw_quad_mesh and draw_rectangle. Is there a definitive list 
> somewhere? I tried RendererBase in backend_bases, but it did not have 
> draw_rectangle.
The pure Gtk backend has no optimizations for draw_quad_mesh. You may 
find that the Agg (e.g. GtkAgg) backend is significantly faster with 
quad meshes because it uses optimized C++ code to draw the mesh. The 
Gtk version must make (as you discovered) a Python function call for 
each quadrilateral. 
The definitive list of methods on rendering backends is in 
backend_bases.py. There are "required" methods, and methods that may be 
provided for optimization reasons (the latter are the ones that mention 
having a "fallback" implementation in RendererBase).
Hope that helps,
Mike

That seems like a reasonable fix. Fixed in SVN r5003.
Cheers,
Mike
Michael Fitzgerald wrote:
> Hi all,
>
> I found a small bug in LineCollection, which gives an exception when 
> setting alpha. This is manifested in e.g. hlines and vlines:
>
>> In [1]: hlines((0,),(-1,),(1,),color='b',alpha=0.1)
>> ---------------------------------------------------------------------------
>> IndexError Traceback (most recent call 
>> last)
>>
>> XXX/<ipython console> in <module>()
>>
>> XXX/lib/python/matplotlib/pyplot.py in hlines(*args, **kwargs)
>> 1700 hold(h)
>> 1701 try:
>> -> 1702 ret = gca().hlines(*args, **kwargs)
>> 1703 draw_if_interactive()
>> 1704 except:
>>
>> XXX/lib/python/matplotlib/axes.py in hlines(self, y, xmin, xmax, 
>> colors, linestyles, label, **kwargs)
>> 2609 linestyles=linestyles, 
>> label=label)
>> 2610 self.add_collection(coll)
>> -> 2611 coll.update(kwargs)
>> 2612
>> 2613 minx = min(xmin.min(), xmax.min())
>>
>> XXX/lib/python/matplotlib/artist.py in update(self, props)
>> 438 if func is None or not callable(func):
>> 439 raise AttributeError('Unknown property %s'%k)
>> --> 440 func(v)
>> 441 changed = True
>> 442 self.eventson = store
>>
>> XXX/lib/python/matplotlib/collections.py in set_alpha(self, alpha)
>> 306 else:
>> 307 artist.Artist.set_alpha(self, alpha)
>> --> 308 self._facecolors[:, 3] = alpha
>> 309 self._edgecolors[:, 3] = alpha
>> 310
>>
>> IndexError: invalid index
>
>
> This appears to be because LineCollection.__init__() only uses 
> Collection._edgecolors, and sets _facecolors to an empty array. I 
> don't know if it's the proper solution, but I did this to get it to work:
>
> Index: lib/matplotlib/collections.py
> ===================================================================
> --- lib/matplotlib/collections.py (revision 5000)
> +++ lib/matplotlib/collections.py (working copy)
> @@ -305,7 +305,8 @@
> except TypeError: raise TypeError('alpha must be a float')
> else:
> artist.Artist.set_alpha(self, alpha)
> - self._facecolors[:, 3] = alpha
> + if len(self._facecolors):
> + self._facecolors[:, 3] = alpha
> self._edgecolors[:, 3] = alpha
>
> def get_linewidths(self):
>
>
> Best,
> Mike
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Darren Dale wrote:
> I discovered another blitting bug in backend_qt4agg.py. Qt expects a pixmap 
> stringBuffer formatted in ARGB, but mpl formats in RGBA. The qt4 backend 
> usually uses the _renderer.tostring_bgra method to return a properly 
> formatted buffer:
>
> if QtCore.QSysInfo.ByteOrder == QtCore.QSysInfo.LittleEndian:
> stringBuffer = self.renderer._renderer.tostring_bgra()
> else:
> stringBuffer = self.renderer._renderer.tostring_argb()
>
> The problem I am seeing is when we are blitting, and the tostring_bgra is not 
> available.
> The blitting code in backend_qt4agg.py, starting around line 112, 
> gets a buffer from a region copied from a bbox:
>
> reg = self.copy_from_bbox(bbox)
> stringBuffer = reg.to_string()
> qImage = QtGui.QImage(stringBuffer, w, h, QtGui.QImage.Format_ARGB32)
>
> reg does not have a method to swap the byte order, and Qt does not have a 
> Format_RGBA32. Could anyone suggest how to swap the byte order?
> 
There might be some numpy "trick" to massage the data. However, it 
looks to me like BufferRegion (in _backend_agg.cpp) needs to grow a 
byte-swapped version of to_string()... but maybe someone with more 
experience with the Qt backend has a better idea whether this used to 
work and why it may have stopped working.
Cheers,
Mike
> Thanks,
> Darren
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Are you sure it's in the repository and not on a local copy? I looked 
in both the maintenance branch and the trunk and didn't see this.
Mike
Manuel Metz wrote:
> Hi,
> the doc-string of the axes scatter method is buggy. Somehow the 
> svn-conflict messages got committed to the repository:
> I mean this
>
> <<<<<<< .working
> [...]
> =======
> [...]
> >>>>>>> .merge-right.r4987
>
> ... stuff)
>
> Manuel
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

I am trying this problem on the developer's list.
Whenever I type a greek symbol in mathtext and save the figure as eps, the
greek symbols don't show up in the eps file.
Confirmed on several windows machines. Python 2.4. mpl 0.91.2. (but it
worked fine under 0.90.1).
Does anybody else have this problem?
It worked for mpl 0.90.1.
Has something changed in mathtext that causes this?
Mark Bakker

Paul Novak wrote:
> A few weeks ago there was a discussion about putting scatter symbols in 
> the legend (see 
> http://www.nabble.com/Show-shapes-on-scatterplot-legend--to15744380.html).
> 
> I would like to implement scatter symbols in the legend, but I am having 
> some problems doing so. In the function _get_handles in legend.py, the 
> symbol can be placed in the legend by doing something like:
> 
> for path in handle._paths:
> xy = path.vertices
> p = Polygon(xy)
> 
> The problem is that the polygon that gets drawn is the wrong size and 
> aspect ratio. It would seem that this would call for some sort of 
> scaling or transform to make the symbol the proper size, but I need some 
> assistance or a pointer to documentation on how to do this.
> 
> Thanks,
> 
> Paul Novak
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Hi,
since I'm also very interested in this functionality I tried it myself. 
What I found out is the following:
 It appears that one transform is missing when just using the 
path.vertices. This is the transform that places the polygon at the 
correct position within the legend and scales it. Here is the 
code-fragment (from legend.py) that I currently use:
 elif isinstance(handle, RegularPolyCollection):
 if self.numpoints == 1:
 xdata = npy.array([left])
 for path in handle.get_paths():
 xy = path.vertices
 p = Polygon(xy)
 x = min(xdata)
 y = y-0.5*HEIGHT
 bbox = Bbox.from_bounds(x, y, HEIGHT/4., HEIGHT/4.)
 if 0:
 p = Rectangle(xy=(min(xdata), y-3/4*HEIGHT),
 width = self.handlelen, height=HEIGHT/2,
 )
 p.set_facecolor(handle._facecolors[0])
 if handle._edgecolors != 'None':
 p.set_edgecolor(handle._edgecolors[0])
 self._set_artist_props(p)
# HERE IS THE ADDITIONAL TRANSFORM FOR THE POLY
 p.set_transform( BboxTransformTo(bbox) + 
p.get_transform() )
 p.set_clip_box(None)
 p.set_clip_path(None)
# FOR DEBUGGING
 print p.get_transform()
 ret.append(p)
This seems to works more or less, BUT NOT when rescaling the Figure 
Window. Then again the polygons get streched...
Manuel

On Mon, Mar 10, 2008 at 11:22:26PM -0400, Jae-Joon Lee wrote:
> I mostly work in an interactive shell (ipython), and if I simply call
> a blocking function (like raw_input)
> from the prompt, it also blocks the event loop of the matplotlib gui backend
> (it happens for GtkAgg, but not for TKAgg. I'm not sure with other
> backends, but I thought
> TKAgg is a special case.)
> So I wanted to call a raw_input (or other blocking function) in an
> interactive shell
> without freezing the figure.
> Hmm, maybe I'm missing something and there has been an very easy way to do it.
> My understading was that the gui event loop waits (without processing
> gui events)
> until the commands entered in the prompt finish.
Sorry, I got lost in dealing with urgent problems again.
I can't spend too much time looking at this issue, but I would like to
confirm that you do seem to have a use-case here that I cannot solve with
something simpler. If other people agree, I think we should move forward
with your solution.
Sorry for the slow response time,
Gaël 

Eric Firing wrote:
> Ryan,
> 
> The pcolor implementation is fundamentally unsuited to large arrays. 
> Therefore I made the pcolorfast axes method, which tries to use the 
> fastest available Agg extension code, depending on the characteristics 
> of the spatial grid. If the grid is rectangular and regular in both 
> directions it uses a slight modification of the image code; if it is 
> rectangular but with irregular spacing, it uses the nonuniform image 
> code; and if it is not rectangular it uses the quadmesh code. It sounds 
> like what you need is the quadmesh version, which you can access either 
> via pcolormesh or pcolorfast. Neither is exposed via the pylab or 
> pyplot API at present; both are axes methods. The pcolorfast API also 
> may change slightly in the future; it probably needs a little more work.
Yeah, I think for purposes of plotting radar data, quadmesh is what i need.
> The quadmesh code has problems with masked arrays in the released 
> version of mpl, but not in the svn version. It is *much* faster than 
> pcolor, but may not be fast enough for your needs.
My latest testing with the trunk with both pcolorfast and pcolormesh 
would seem to indicate that it's still a bit too slow for me.
> If you are looking into what sounds like an OpenGL backend, or component 
> to a backend, then the place to start is still probably pcolormesh or 
> pcolorfast, not pcolor.
This is the approach I'm considering. I've been poking around, and 
managed to create something that rendered, but not too well. However 
this was basically modifying the Gtk backend, and I'm sure there are 
some Gtk things that could be replaced. I noticed there are some other 
draw_* methods in other backends that aren't in the gtk, like 
draw_quad_mesh and draw_rectangle. Is there a definitive list 
somewhere? I tried RendererBase in backend_bases, but it did not have 
draw_rectangle.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

A few weeks ago there was a discussion about putting scatter symbols in 
the legend (see 
http://www.nabble.com/Show-shapes-on-scatterplot-legend--to15744380.html).
I would like to implement scatter symbols in the legend, but I am having 
some problems doing so. In the function _get_handles in legend.py, the 
symbol can be placed in the legend by doing something like:
for path in handle._paths:
 xy = path.vertices
p = Polygon(xy)
The problem is that the polygon that gets drawn is the wrong size and 
aspect ratio. It would seem that this would call for some sort of 
scaling or transform to make the symbol the proper size, but I need some 
assistance or a pointer to documentation on how to do this.
Thanks,
Paul Novak

Happend with your commit from version 4979 -> 4989. Who's going to fix 
that ? Whom can I directly contact ?
-------- Original Message --------
Subject: [matplotlib-devel] axes.py scatter doc-bug
Date: 2008年3月12日 12:30:12 +0100
From: Manuel Metz <mm...@as...>
To: mat...@li...
CC: John Hunter <jd...@gm...>
Hi,
the doc-string of the axes scatter method is buggy. Somehow the
svn-conflict messages got committed to the repository:
I mean this
<<<<<<< .working
[...]
=======
[...]
 >>>>>>> .merge-right.r4987
... stuff)
Manuel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thursday 13 March 2008 05:02:36 pm Ted Drain wrote:
> I'm working on improving the plotting speed of one of our applications. As
> part of that, I was looking at how quickly the QtAgg backend is drawing. I
> added some print out's to the backend and noticed that it seems to be
> drawing everything twice. In the code:
>
> backend_qtagg.py: FigureCanvasQTAgg class:
>
> def draw( self ):
> """
> Draw the figure when xwindows is ready for the update
> """
>
> if DEBUG: print "FigureCanvasQtAgg.draw", self
> self.replot = True
> FigureCanvasAgg.draw(self)
> self.repaint( False )
>
>
>
> FigureCanvasAgg.draw() will cause a draw the repaint call will cause a
> draw. If I comment out the FCAgg.draw() call, my application (QtAgg
> embedded in a PyQt program) works fine. I've also run several of the
> various example scripts and they seem to work fine as well. Panning,
> zooming, redraws, resize, and file saving seem to be unaffected.
>
> Does anyone know why the extra draw call might be necessary?
Thank you for pointing this out, Ted. It actually solves a problem I was 
seeing with the qt4agg backend, where the widgets.Cursor crosshairs were not 
being drawn when blitting was disabled.
I removed the lines from qtagg and qt4agg, and saw no problems in the examples 
or my own application, so I checked in the changes - svn 5002.
Darren

Hi all,
I am trying to compile matplotlib under MacOSX 10.5, and I get the
following error message:
src/_image.cpp:842: error: insn does not satisfy its constraints:
(insn 2573 1070 2574 126 agg24/include/agg_color_rgba.h:268 (set
(mem:QI (plus:SI (reg/f:SI 6 bp)
 (const_int -280 [0xfffffffffffffee8])) [0 SR.2990+0 S1 A8])
 (reg:QI 5 di)) 56 {*movqi_1} (nil)
 (nil))
src/_image.cpp:842: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Has anyone seen this before? I have found the following link, but no
solution is indicated:
http://www.nabble.com/internal-compiler-error-on-os-x-with--arch-i386-td14716109.html
Is this a compiler bug, or are there flags I can use to fix the
problem? I'd appreciate any advice.
Thanks,
Stéfan

I'm working on improving the plotting speed of one of our applications. As
part of that, I was looking at how quickly the QtAgg backend is drawing. I
added some print out's to the backend and noticed that it seems to be
drawing everything twice. In the code:
backend_qtagg.py: FigureCanvasQTAgg class:
 def draw( self ):
 """
 Draw the figure when xwindows is ready for the update
 """
 if DEBUG: print "FigureCanvasQtAgg.draw", self
 self.replot = True
 FigureCanvasAgg.draw(self)
 self.repaint( False )
FigureCanvasAgg.draw() will cause a draw the repaint call will cause a draw.
If I comment out the FCAgg.draw() call, my application (QtAgg embedded in a
PyQt program) works fine. I've also run several of the various example
scripts and they seem to work fine as well. Panning, zooming, redraws,
resize, and file saving seem to be unaffected.
Does anyone know why the extra draw call might be necessary?
Ted

I'm getting the traceback shown below in _get_configdir. I've attached a 
patch for cutils.py
[sierra@sierra-trac ~]$
/data0/sierra/trac/trac-0.11stable/bin/trac-admin /data0/www/trac/sierra
resync
Failed to open environment. not enough arguments for format string
Traceback (most recent call last):
...
"/data0/sierra/lib/python2.5/site-packages/matplotlib/__init__.py", line
400, in _get_configdir
 raise RuntimeError("'%s' is not a writable dir; you must set
%s/.matplotlib to be a writable dir. You can also set environment
variable MPLCONFIGDIR to any writable directory where you want
matplotlib data stored "%h)
TypeError: not enough arguments for format string
-- 
----------------
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
505-844-7666

Shannon Jaeger wrote:
> Hi Ryan and Eric,
> 
> I work on software that plots bits and pieces of radio astronomy
> data. We've run into similar issues and will be running into
> even more related to performance.
> 
> We have datasets that have millions of points, potentially into
> the billions in the not so distant future. Sometimes the way
> the users have choosen what bits and pieces to plot we need to
> break up the data into chunks and plot each chunk separately.
> To further complicate we allow them to overplot other large plots
> on top.
> 
> Anyway I'm very interested in learning more about how to use the
> quadmesh code and using it as well. Although I haven't played
> much with the source code at all, any advice on how to expose this
> at the API level would be appreciated. If modifying the backend
> is all that's needed we've already done a bit of this to tailor
> things to our needs.
Shannon,
I'm not sure what you mean by "expose this at the API level"; quadmesh 
is already exposed via the pcolormesh and pcolorfast axes methods. Do 
you mean via a pyplot/pylab wrapper? This can be done easily, but my 
intention was to work out the kinks in the pcolorfast method API before 
 wrapping it in pyplot, and possibly deprecate pcolormesh on the 
grounds that its functionality are included in pcolorfast. Instead of a 
proliferation of variations on this type of plot, I was hoping to 
consolidate everything into no more than two alternatives: the original 
pcolor, which can draw outlines around the boxes and draws only unmasked 
boxes; and pcolorfast, which omits those pesky outlines, and uses the 
fastest available algorithm for the type of data that are provided.
Eric
> 
> Thanks for any suggestions in advance.
> 
> Shannon
> ------------
> Shannon Jaeger
> Atacama Large Millimetre Array
> Dept. of Physics & Astronomy
> University of Calgary,
> Calgary, AB, Canada
> email: sdj...@uc...
> ph: +1 403 210 8495
> 
> 
> 
> On Thu, March 13, 2008 11:37 am, Eric Firing said:
>> Ryan,
>>
>> The pcolor implementation is fundamentally unsuited to large arrays.
>> Therefore I made the pcolorfast axes method, which tries to use the
>> fastest available Agg extension code, depending on the characteristics
>> of the spatial grid. If the grid is rectangular and regular in both
>> directions it uses a slight modification of the image code; if it is
>> rectangular but with irregular spacing, it uses the nonuniform image
>> code; and if it is not rectangular it uses the quadmesh code. It sounds
>> like what you need is the quadmesh version, which you can access either
>> via pcolormesh or pcolorfast. Neither is exposed via the pylab or
>> pyplot API at present; both are axes methods. The pcolorfast API also
>> may change slightly in the future; it probably needs a little more work.
>>
>> The quadmesh code has problems with masked arrays in the released
>> version of mpl, but not in the svn version. It is *much* faster than
>> pcolor, but may not be fast enough for your needs.
>>
>> If you are looking into what sounds like an OpenGL backend, or component
>> to a backend, then the place to start is still probably pcolormesh or
>> pcolorfast, not pcolor.
>>
>> Eric
>>
>> Ryan May wrote:
>>> Hi,
>>>
>>> I've been poking around with pcolor, trying to see what makes it tick,
>>> since its performance is biggest thing that drives me nuts about
>>> matplotlib. I do pcolor plots of weather radar data with ~100000
>>> polygons in them. Unfortunately, these polygons are at best trapezoids,
>>> so I can't treat it as image data. With this data, pcolor takes ages to
>>> zoom and pan, even on my new workstaion. My end goal is to be able to
>>> use OpenGL to do some 2D rendering, since in my experience, this simply
>>> flies at rendering such data for interactive analysis.
>>>
>>> I noticed that when I run the pcolor_demo.py (using current SVN trunk),
>>> 29396 separate calls are registered to RendererGDK->draw_path to simply
>>> draw the image the first time. Is there any reason why these can't be
>>> batched up and passed in one block to the renderer? This would make
>>> life easier in setting up OpenGL to render in one pass.
>>>
>>> Thanks
>>>
>>> Ryan
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
> 
> 

Ryan,
The pcolor implementation is fundamentally unsuited to large arrays. 
Therefore I made the pcolorfast axes method, which tries to use the 
fastest available Agg extension code, depending on the characteristics 
of the spatial grid. If the grid is rectangular and regular in both 
directions it uses a slight modification of the image code; if it is 
rectangular but with irregular spacing, it uses the nonuniform image 
code; and if it is not rectangular it uses the quadmesh code. It sounds 
like what you need is the quadmesh version, which you can access either 
via pcolormesh or pcolorfast. Neither is exposed via the pylab or 
pyplot API at present; both are axes methods. The pcolorfast API also 
may change slightly in the future; it probably needs a little more work.
The quadmesh code has problems with masked arrays in the released 
version of mpl, but not in the svn version. It is *much* faster than 
pcolor, but may not be fast enough for your needs.
If you are looking into what sounds like an OpenGL backend, or component 
to a backend, then the place to start is still probably pcolormesh or 
pcolorfast, not pcolor.
Eric
Ryan May wrote:
> Hi,
> 
> I've been poking around with pcolor, trying to see what makes it tick, 
> since its performance is biggest thing that drives me nuts about 
> matplotlib. I do pcolor plots of weather radar data with ~100000 
> polygons in them. Unfortunately, these polygons are at best trapezoids, 
> so I can't treat it as image data. With this data, pcolor takes ages to 
> zoom and pan, even on my new workstaion. My end goal is to be able to 
> use OpenGL to do some 2D rendering, since in my experience, this simply 
> flies at rendering such data for interactive analysis.
> 
> I noticed that when I run the pcolor_demo.py (using current SVN trunk), 
> 29396 separate calls are registered to RendererGDK->draw_path to simply 
> draw the image the first time. Is there any reason why these can't be 
> batched up and passed in one block to the renderer? This would make 
> life easier in setting up OpenGL to render in one pass.
> 
> Thanks
> 
> Ryan
> 

Hi,
I've been poking around with pcolor, trying to see what makes it tick, 
since its performance is biggest thing that drives me nuts about 
matplotlib. I do pcolor plots of weather radar data with ~100000 
polygons in them. Unfortunately, these polygons are at best trapezoids, 
so I can't treat it as image data. With this data, pcolor takes ages to 
zoom and pan, even on my new workstaion. My end goal is to be able to 
use OpenGL to do some 2D rendering, since in my experience, this simply 
flies at rendering such data for interactive analysis.
I noticed that when I run the pcolor_demo.py (using current SVN trunk), 
29396 separate calls are registered to RendererGDK->draw_path to simply 
draw the image the first time. Is there any reason why these can't be 
batched up and passed in one block to the renderer? This would make 
life easier in setting up OpenGL to render in one pass.
Thanks
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric Firing wrote:
> Jeff,
>
> When putting a legend on a basemap plot, I find that the legend command 
> picks up the coastline line collection and gives it an uninformative 
> label. I suspect this is rarely what one wants. Two suggestions:
>
> 1) In drawcoastlines, use "coastlines.set_label('_nolabel_') to suppress 
> inclusion in the legend, and similarly for drawcountries, etc.
> 
Eric:
Done for coastlines, rivers, countries and states.
> 2) Make drawcoastlines return the line collection that it creates. 
> Similarly, drawcountries could return the line collection, 
> fillcoastlines could return the list of patches, etc. 
All done.
> Drawparallels and 
> drawmeridians are a little more complicated because they make the labels 
> as well as the lines, so I am not sure what to do with them.
> 
drawmeridians and drawmeridians now return dictionaries, with the Line2D 
and Text instances associated with each latitude or longitude.
> Granted, one can grab the reference to the line collection from the end 
> of ax.collections, but it seems cheap, reasonable, and more convenient 
> to simply have it returned by the command that makes it.
>
> Eric
>
>
> 
Thanks for the suggestion.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Jeff,
When putting a legend on a basemap plot, I find that the legend command 
picks up the coastline line collection and gives it an uninformative 
label. I suspect this is rarely what one wants. Two suggestions:
1) In drawcoastlines, use "coastlines.set_label('_nolabel_') to suppress 
inclusion in the legend, and similarly for drawcountries, etc.
2) Make drawcoastlines return the line collection that it creates. 
Similarly, drawcountries could return the line collection, 
fillcoastlines could return the list of patches, etc. Drawparallels and 
drawmeridians are a little more complicated because they make the labels 
as well as the lines, so I am not sure what to do with them.
Granted, one can grab the reference to the line collection from the end 
of ax.collections, but it seems cheap, reasonable, and more convenient 
to simply have it returned by the command that makes it.
Eric

Hi all,
I found a small bug in LineCollection, which gives an exception when setting
alpha. This is manifested in e.g. hlines and vlines:
In [1]: hlines((0,),(-1,),(1,),color='b',alpha=0.1)
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
XXX/<ipython console> in <module>()
XXX/lib/python/matplotlib/pyplot.py in hlines(*args, **kwargs)
 1700 hold(h)
 1701 try:
-> 1702 ret = gca().hlines(*args, **kwargs)
 1703 draw_if_interactive()
 1704 except:
XXX/lib/python/matplotlib/axes.py in hlines(self, y, xmin, xmax, colors,
linestyles, label, **kwargs)
 2609 linestyles=linestyles,
label=label)
 2610 self.add_collection(coll)
-> 2611 coll.update(kwargs)
 2612
 2613 minx = min(xmin.min(), xmax.min())
XXX/lib/python/matplotlib/artist.py in update(self, props)
 438 if func is None or not callable(func):
 439 raise AttributeError('Unknown property %s'%k)
--> 440 func(v)
 441 changed = True
 442 self.eventson = store
XXX/lib/python/matplotlib/collections.py in set_alpha(self, alpha)
 306 else:
 307 artist.Artist.set_alpha(self, alpha)
--> 308 self._facecolors[:, 3] = alpha
 309 self._edgecolors[:, 3] = alpha
 310
IndexError: invalid index
This appears to be because LineCollection.__init__() only uses
Collection._edgecolors, and sets _facecolors to an empty array. I don't
know if it's the proper solution, but I did this to get it to work:
Index: lib/matplotlib/collections.py
===================================================================
--- lib/matplotlib/collections.py (revision 5000)
+++ lib/matplotlib/collections.py (working copy)
@@ -305,7 +305,8 @@
 except TypeError: raise TypeError('alpha must be a float')
 else:
 artist.Artist.set_alpha(self, alpha)
- self._facecolors[:, 3] = alpha
+ if len(self._facecolors):
+ self._facecolors[:, 3] = alpha
 self._edgecolors[:, 3] = alpha
 def get_linewidths(self):
Best,
Mike