matplotlib-users Mailing List for matplotlib

On Dec 12, 2007 1:29 PM, Mark Bakker <ma...@gm...> wrote:
> It seems that in the latest version (0.9.1) the location of the images, such
> as home.ppm, has moved to a new directory.
> It used to be in ...\mpl-data and now it is in ...\mpl-data\images
>
> This totally breaks my code, as I use my own toolbar that uses these images,
> with a hardcoded location of the ppm files. I know, I should from now on
> distribute these ppm files with the distribution of my own program, but
> there may be others that have this problem.
>
> Not sure what the best solution is. WIll it remain in this new images
> directory from now on?
Can't say for sure, but we have no plans to move it. You may want to
follow the API_CHANGES at http://matplotlib.sf.net/API_CHANGES, which
we update whenever we do something that breaks code. This move to the
images subdirectory in the install directory was noted with:
 Moved data files into lib/matplotlib so that setuptools' develop
 mode works. Re-organized the mpl-data layout so that this source
 structure is maintained in the installation. (I.e. the 'fonts' and
 'images' sub-directories are maintained in site-packages.).
 Suggest removing site-packages/matplotlib/mpl-data and
 ~/.matplotlib/ttffont.cache before installing
Admittedly a bit cryptic.
JDH
>
> Thanks,
>
> Mark
>
> ps. Cross-posted on the users and development list
> ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just
> needed to point out this backwards incompatibility, which may just be ugly
> coding on my part
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

You can set the position of the axes with "set_position" and give it a 
list of the form [l, b, w, h], where the values range from 0 to 1. e.g.:
 gca().set_position([0, 0, 1, 1])
Cheers,
Mike
Michael Hearne wrote:
> All: I have an issue I'm hoping someone here can help with. I've 
> created a encapsulated postscript figure from pylab (basemap, actually, 
> but it shouldn't make a difference), and I'd like to have the entire 
> saved image be the extent of the axes, with no border whatsoever. Is 
> there a way to set the extent of either the axes or the figure so that 
> this is so?
> 
> And before someone points this out to me - yes, I realize that there are 
> other tools (ImageMagick, for example) I could use to trim the 
> whitespace around the edge of the image, but this is part of an 
> automated system and I'd prefer not to have to bomb out to a shell for 
> something like that.
> 
> Thanks,
> 
> Mike
> 
> 
> 
> 
> ------------------------------------------------------
> Michael Hearne
> mh...@us... <mailto:mh...@us...>
> (303) 273-8620
> USGS National Earthquake Information Center
> 1711 Illinois St. Golden CO 80401
> Senior Software Engineer
> Synergetics, Inc.
> ------------------------------------------------------
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

All: I have an issue I'm hoping someone here can help with. I've 
created a encapsulated postscript figure from pylab (basemap, 
actually, but it shouldn't make a difference), and I'd like to have 
the entire saved image be the extent of the axes, with no border 
whatsoever. Is there a way to set the extent of either the axes or 
the figure so that this is so?
And before someone points this out to me - yes, I realize that there 
are other tools (ImageMagick, for example) I could use to trim the 
whitespace around the edge of the image, but this is part of an 
automated system and I'd prefer not to have to bomb out to a shell 
for something like that.
Thanks,
Mike
------------------------------------------------------
Michael Hearne
mh...@us...
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------

Barry Wark wrote:
> We're just hoping to integrate the
> plot output with the Quartz rendeirng system more completely -- a very
> platform specific goal.
Fair enough, and MPL as a whole could learn from your work too. Do 
please report your progress.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Ok, I've just read the thread "Repeated calls to set_text using TeX
formatting results in RuntimeError" which looked very similar to our problem
and after applying the fix which is suggested there by Michael Droettboom
(see below), the problem seems to disappear. Let's hope this gets fixed in
0.91.2.
Open the file "font_manager.py", which should live in
"%PYTHONPATH%/Lib/site-packages/matplotlib". Around line 681, you'll
find the function:
 def __hash__(self):
 return hash(repr(self.__props))
Change it to:
 def __hash__(self):
 return hash(repr(self.__props.__dict__))
(Obviously, back up the file first...)
On Dec 12, 2007 8:32 PM, Armando Serrano Lombillo <ars...@gm...>
wrote:
> I'm running into the very same problem. I'm using matplotlib from a
> wxPython application, the same versions as you (Yongtao Cui), and I get the
> same error (see below) after repainting a figure many times. In my case I
> plot several figures (16 figures) and I get the error with very few
> repaintings. This didn't happen with matplotlib 0.90.1.
>
> Any fix besides going back to matplotlib 0.90.1?
>
>
> Traceback (most recent call last):
> Traceback (most recent call last):
> File "C:\Tesis\Programa\visualizador.py", line 93, in on_intervalos
> File "C:\Tesis\Programa\visualizador.py", line 126, in pinta
> File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wxagg.py", line
> 61, in draw
> File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> line 380, in draw
> File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line 612, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 1344, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 596, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 170, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 775, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 317, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 195, in
> _get_layout
> File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> line 234, in get_text_width_height_descent
> File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> line 301, in _get_agg_font
> RuntimeError: Could not open facefile C:\WINDOWS\Fonts\verdana.ttf;
> Cannot_Open_Resource
>
> File "C:\Tesis\Programa\visualizador.py", line 93, in on_intervalos
> File "C:\Tesis\Programa\visualizador.py", line 126, in pinta
> File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wxagg.py", line
> 61, in draw
> File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> line 380, in draw
> File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line 612, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 1344, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 596, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 170, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 775, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 317, in
> draw
> File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 195, in
> _get_layout
> File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> line 234, in get_text_width_height_descent
> File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> line 301, in _get_agg_font
> RuntimeError: Could not open facefile C:\WINDOWS\Fonts\verdana.ttf;
> Cannot_Open_Resource
>
>
>
>
> On Dec 5, 2007 3:15 AM, Yongtao Cui <cui...@gm...> wrote:
>
> > I don't know why those spaces always don't show up on the mailing list
> > webpage. They looked fine on my gmail page.
> >
> > The 'test' function only has one 'for' loop. The four lines below the
> > 'for' line are all in the loop.
> >
> >
> >
> > On Dec 4, 2007 8:52 PM, Yongtao Cui <cui...@gm...> wrote:
> > > >>> import pylab
> > > >>> def test(n):
> > > >>> for i in range(n):
> > > >>> f=pylab.figure(1)
> > > >>> f.clf()
> > > >>> a=f.add_axes([0.2, 0.2, 0.6 , 0.6])
> > > >>> a.plot([1,2,3,4,5], 'ro')
> > > >>>
> > >
> > > I tracked down the svn tree. The above script works ok in revision
> > > 3737 and before, but crashes from revision 3738 and after.
> > >
> > > Yongtao
> > >
> > >
> > > On Dec 2, 2007 4:15 PM, Yongtao Cui <cui...@gm...> wrote:
> > > > Below is the minimum code with the right indent
> > > >
> > > > import pylab
> > > > def test(n):
> > > > for i in range(n):
> > > > f=pylab.figure(1)
> > > > f.clf()
> > > > a=f.add_axes([0.2, 0.2, 0.6 , 0.6])
> > > > a.plot([1,2,3,4,5], 'ro')
> > > >
> > > >
> > > > On Dec 2, 2007 4:07 PM, Yongtao Cui <cui...@gm...> wrote:
> > > > > Hi,
> > > > >
> > > > > I got the following error when clearing and plotting on the same
> > > > > figure for many times. I found the following minimum code to
> > reproduce
> > > > > this error. I am using matplotlib-0.91.1 and wxpython2.8 on
> > windows
> > > > > xp. In the matplotlibrc file, I changed the backend to WXAgg and
> > > > > interactive to True.
> > > > >
> > > > > import pylab
> > > > > def test(n):
> > > > > for i in range(n):
> > > > > f=pylab.figure(1)
> > > > > f.clf()
> > > > > a=f.add_axes([0.2, 0.2, 0.6, 0.6])
> > > > > a.plot([1,2,3,4,5], 'ro')
> > > > >
> > > > >
> > > > > The error only happens for a large n. For example, test(10) works
> > > > > fine, but test(50) will cause the error. Also runing test(10) for
> > a
> > > > > few times will also cause the error.
> > > > >
> > > > > Could anyone give me some help?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > The following is the error message:
> > > > >
> > > > > Traceback (most recent call last):
> > > > > File "<input>", line 1, in <module>
> > > > > File "<input>", line 3, in test
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\pyplot.py", line
> > 191, in figure
> > > > > File
> > "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wx.py",
> > > > > line 1227, in draw_if_interactive
> > > > > File
> > "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wxagg.py",
> > > > > line 61, in draw
> > > > > File
> > "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> > > > > line 380, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line
> > 612, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line
> > 1344, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line
> > 596, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line
> > 170, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\text.py", line
> > 775, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\text.py", line
> > 317, in draw
> > > > > File "C:\Python25\Lib\site-packages\matplotlib\text.py", line
> > 195,
> > > > > in _get_layout
> > > > > File
> > "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> > > > > line 234, in get_text_width_height_descent
> > > > > File
> > "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> > > > > line 301, in _get_agg_font
> > > > > RuntimeError: Could not open facefile
> > > > >
> > C:\Python25\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf;
> > > > > Cannot_Open_Resource
> > > > >
> > > >
> > >
> >
> >
> > -------------------------------------------------------------------------
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > from Novell. From the desktop to the data center, Linux is going
> > mainstream. Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>
>

I'm running into the very same problem. I'm using matplotlib from a wxPython
application, the same versions as you (Yongtao Cui), and I get the same
error (see below) after repainting a figure many times. In my case I plot
several figures (16 figures) and I get the error with very few repaintings.
This didn't happen with matplotlib 0.90.1.
Any fix besides going back to matplotlib 0.90.1?
Traceback (most recent call last):
Traceback (most recent call last):
 File "C:\Tesis\Programa\visualizador.py", line 93, in on_intervalos
 File "C:\Tesis\Programa\visualizador.py", line 126, in pinta
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wxagg.py",
line 61, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 380, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line 612, in
draw
 File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 1344, in
draw
 File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 596, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 170, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 775, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 317, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 195, in
_get_layout
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 234, in get_text_width_height_descent
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 301, in _get_agg_font
RuntimeError: Could not open facefile C:\WINDOWS\Fonts\verdana.ttf;
Cannot_Open_Resource
 File "C:\Tesis\Programa\visualizador.py", line 93, in on_intervalos
 File "C:\Tesis\Programa\visualizador.py", line 126, in pinta
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wxagg.py",
line 61, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 380, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line 612, in
draw
 File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 1344, in
draw
 File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 596, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 170, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 775, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 317, in draw
 File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 195, in
_get_layout
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 234, in get_text_width_height_descent
 File "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 301, in _get_agg_font
RuntimeError: Could not open facefile C:\WINDOWS\Fonts\verdana.ttf;
Cannot_Open_Resource
On Dec 5, 2007 3:15 AM, Yongtao Cui <cui...@gm...> wrote:
> I don't know why those spaces always don't show up on the mailing list
> webpage. They looked fine on my gmail page.
>
> The 'test' function only has one 'for' loop. The four lines below the
> 'for' line are all in the loop.
>
>
>
> On Dec 4, 2007 8:52 PM, Yongtao Cui <cui...@gm...> wrote:
> > >>> import pylab
> > >>> def test(n):
> > >>> for i in range(n):
> > >>> f=pylab.figure(1)
> > >>> f.clf()
> > >>> a=f.add_axes([0.2, 0.2, 0.6, 0.6])
> > >>> a.plot([1,2,3,4,5], 'ro')
> > >>>
> >
> > I tracked down the svn tree. The above script works ok in revision
> > 3737 and before, but crashes from revision 3738 and after.
> >
> > Yongtao
> >
> >
> > On Dec 2, 2007 4:15 PM, Yongtao Cui <cui...@gm...> wrote:
> > > Below is the minimum code with the right indent
> > >
> > > import pylab
> > > def test(n):
> > > for i in range(n):
> > > f=pylab.figure(1)
> > > f.clf()
> > > a=f.add_axes([0.2, 0.2, 0.6, 0.6])
> > > a.plot([1,2,3,4,5], 'ro')
> > >
> > >
> > > On Dec 2, 2007 4:07 PM, Yongtao Cui <cui...@gm...> wrote:
> > > > Hi,
> > > >
> > > > I got the following error when clearing and plotting on the same
> > > > figure for many times. I found the following minimum code to
> reproduce
> > > > this error. I am using matplotlib-0.91.1 and wxpython2.8 on windows
> > > > xp. In the matplotlibrc file, I changed the backend to WXAgg and
> > > > interactive to True.
> > > >
> > > > import pylab
> > > > def test(n):
> > > > for i in range(n):
> > > > f=pylab.figure(1)
> > > > f.clf()
> > > > a=f.add_axes([0.2, 0.2, 0.6, 0.6])
> > > > a.plot([1,2,3,4,5], 'ro')
> > > >
> > > >
> > > > The error only happens for a large n. For example, test(10) works
> > > > fine, but test(50) will cause the error. Also runing test(10) for a
> > > > few times will also cause the error.
> > > >
> > > > Could anyone give me some help?
> > > >
> > > > Thanks.
> > > >
> > > > The following is the error message:
> > > >
> > > > Traceback (most recent call last):
> > > > File "<input>", line 1, in <module>
> > > > File "<input>", line 3, in test
> > > > File "C:\Python25\Lib\site-packages\matplotlib\pyplot.py", line
> 191, in figure
> > > > File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wx.py",
> > > > line 1227, in draw_if_interactive
> > > > File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_wxagg.py",
> > > > line 61, in draw
> > > > File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> > > > line 380, in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\figure.py", line
> 612, in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\axes.py", line 1344,
> in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 596,
> in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\axis.py", line 170,
> in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 775,
> in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 317,
> in draw
> > > > File "C:\Python25\Lib\site-packages\matplotlib\text.py", line 195,
> > > > in _get_layout
> > > > File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> > > > line 234, in get_text_width_height_descent
> > > > File
> "C:\Python25\Lib\site-packages\matplotlib\backends\backend_agg.py",
> > > > line 301, in _get_agg_font
> > > > RuntimeError: Could not open facefile
> > > >
> C:\Python25\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf;
> > > > Cannot_Open_Resource
> > > >
> > >
> >
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hello -
It seems that in the latest version (0.9.1) the location of the images, such
as home.ppm, has moved to a new directory.
It used to be in ...\mpl-data and now it is in ...\mpl-data\images
This totally breaks my code, as I use my own toolbar that uses these images,
with a hardcoded location of the ppm files. I know, I should from now on
distribute these ppm files with the distribution of my own program, but
there may be others that have this problem.
Not sure what the best solution is. WIll it remain in this new images
directory from now on?
Thanks,
Mark
ps. Cross-posted on the users and development list
ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just
needed to point out this backwards incompatibility, which may just be ugly
coding on my part

sorry to be a wet blanket, but...
Barry Wark wrote:
> going "native" for rendering would allow mpl
> to integrate more smoothly with the rest of the 2D and 3D 
MPL is really only a 2D system -- there's been talk of the next 
generation version building 3D in, but we're really not there yet.
 > ability to offload rendering and/or coordinate
> transformation to the graphics card, 
With the multi-backend paradigm, it's really hard to truly take 
advantage of this kind of thing -- optimum performance on any given 
platform is just not going to happen.
> ability to easily produce output
> in any of the CoreImage supported formats,
That's nice, but again, a bit out of sync with the cross platform nature 
of MPL.
 ability to incorporate
> transparency and alpha blending within the view hierarchy, ability to
> combine media (QuickTime, OpenGL, and Quartz) in layers (the real
> purpose of the CoreAnimation engine), 
again -- very platform specific.
In short, CoreGraphics is the obvious choice for a Mac-only tools, but 
the advantages are greatly reduced for a platform and back-end 
independent tool like MPL. Which isn't to say that the Cocoa back-end 
isn't a good idea -- but the primary reason for it that I see is to be 
able to integrate with PyObjC apps.
Really, Agg (or Cairo, if we didn't have those pesky licensing issues) 
is a great way to go for a tool like MPL. It rally keeps things platform 
independent.
If MPL does go 3D in the future, then OpenGL is probably the way to go 
too -- it's more or less the same everywhere.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

mbauer wrote:
> Thanks Jeff,
>
> To clarify, I'm sampling a numpy array (regular lon/lat grid) and 
> extracting a series of same size frames (say 60 longitude grids and 30 
> latitude grids) around a feature of interest, which can be centered 
> somewhere on the map. What I want to do is accumulate statistics with 
> these frames such that the relative size/distances are persevered, 
> which of course means that I can't just add a frame centered on 30N 
> with one centered on 80N. Ideally, I'd like to interpolate each frame 
> to a common point (lon/lat) and display the results either in the 
> common grid space or as radial distances from the common point.
>
> Since you're a meteorologist I can simply say I'm creating an ensemble 
> average of extra tropical cyclones from a dozen or so computer models 
> (each with very different resolutions). I want to see how cloud and 
> precipitation features in each model's cyclones compare to a similar 
> product I'm producing from satellite data using weather model output 
> to locate the cyclones. Much the same thing as the link I provided.
>
> Thanks for your suggests as transform_scalar sounds like a good place 
> to begin.
>
> Mike
Mike: Thanks for the explanation, I get it now - and I think I have 
just the thing for you. First, define a Basemap instance for a Lambert 
Conformal projection centered on each of you frames that is 5000 km wide 
and 5000 km tall.
# for frame centered on lon_0, lat_0.
# resolution=None skips processing of boundary datasets to save time.
m = Basemap(lon_0=lon_0, lat_0=lat_0, projection='lcc', \
 width=5000000, height=5000000, resolution=None) 
Now interpolate your data to a nx by ny grid that is regular in the map 
projection region.
# data is the lat/lon gridded data, lons and lats are 1D arrays in degrees.
data2 = m.transform_scalar(data, lons, lats, nx, ny) 
The data2 grids will be approximately equally spaced on the surface of 
the earth, regardless on lat_0 and lon_0. Therefore, you should be able 
to just ensemble average all the data2 grids and preserve the relative 
shapes and sizes of the features (this is helped by the fact that the 
projection is conformal, or shape-preserving).
HTH,
-Jeff
>
> On Dec 11, 2007, at 4:57 PM, Jeff Whitaker wrote:
>
>> mbauer wrote:
>>> Matplotlib users, I looking to tap your wealth of ideas and 
>>> experience to help solve a problem I'm working on.
>>>
>>> The problem: I have a series of 2d scalar arrays representing a 
>>> fixed width/height lon/lat box centered on an arbitrary lon/lat. I 
>>> need to average these composites on a common basis that 
>>> accommodates the scale changes due to latitude, preferably by 
>>> shifting everything to a common central lon/lat (a polar/radial 
>>> distance basis would work too). I want a plot of the end result too 
>>> and I'm like to do everything with matplotlib and python so that it 
>>> folds into the rest of my program.
>>>
>>> Something similar can be seen at 
>>> http://www.atmos.washington.edu/~robwood/topic_cyclones.htm
>>>
>>> I've been looking at transform_scalar from basemap but I'm not 
>>> quite sure this is what I should use.
>>>
>> Mike:
>>
>> transform_scalar does simple bilinear interpolation from a lat/lon 
>> grid to a regular grid in map projection coordinates. If your map 
>> projection is just a lat/lon projection, then this amounts to 
>> interpolating from one lat/lon grid to another.
>>> If anyone can offer a solution, a point in the right direction, or 
>>> just wave me off this path I'd be most appreciative.
>>>
>> I'm sure numpy/matplotlib can do what you need to do. Matplotlib 
>> can certainly make a plot similar to the one given in your link. I 
>> think you question relates more to the processing of your arrays 
>> though, and not specifically the plotting. Are all your 2d arrays 
>> the same shape (the same number of lats and lons)? Are they just 
>> centered on different regions? If so, I think you can just multiply 
>> each grid point by the cosine of latitude to get the proper area 
>> weighting before summing them together. But perhaps I'm missing the 
>> essence of your question ....
>>
>> -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
>>
>>
>
-- 
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

Thanks Jeff,
To clarify, I'm sampling a numpy array (regular lon/lat grid) and 
extracting a series of same size frames (say 60 longitude grids and 30 
latitude grids) around a feature of interest, which can be centered 
somewhere on the map. What I want to do is accumulate statistics with 
these frames such that the relative size/distances are persevered, 
which of course means that I can't just add a frame centered on 30N 
with one centered on 80N. Ideally, I'd like to interpolate each frame 
to a common point (lon/lat) and display the results either in the 
common grid space or as radial distances from the common point.
Since you're a meteorologist I can simply say I'm creating an ensemble 
average of extra tropical cyclones from a dozen or so computer models 
(each with very different resolutions). I want to see how cloud and 
precipitation features in each model's cyclones compare to a similar 
product I'm producing from satellite data using weather model output 
to locate the cyclones. Much the same thing as the link I provided.
Thanks for your suggests as transform_scalar sounds like a good place 
to begin.
Mike
On Dec 11, 2007, at 4:57 PM, Jeff Whitaker wrote:
> mbauer wrote:
>> Matplotlib users, I looking to tap your wealth of ideas and 
>> experience to help solve a problem I'm working on.
>>
>> The problem: I have a series of 2d scalar arrays representing a 
>> fixed width/height lon/lat box centered on an arbitrary lon/lat. I 
>> need to average these composites on a common basis that 
>> accommodates the scale changes due to latitude, preferably by 
>> shifting everything to a common central lon/lat (a polar/radial 
>> distance basis would work too). I want a plot of the end result 
>> too and I'm like to do everything with matplotlib and python so 
>> that it folds into the rest of my program.
>>
>> Something similar can be seen at http://www.atmos.washington.edu/~robwood/topic_cyclones.htm
>>
>> I've been looking at transform_scalar from basemap but I'm not 
>> quite sure this is what I should use.
>>
> Mike:
>
> transform_scalar does simple bilinear interpolation from a lat/lon 
> grid to a regular grid in map projection coordinates. If your map 
> projection is just a lat/lon projection, then this amounts to 
> interpolating from one lat/lon grid to another.
>> If anyone can offer a solution, a point in the right direction, or 
>> just wave me off this path I'd be most appreciative.
>>
> I'm sure numpy/matplotlib can do what you need to do. Matplotlib 
> can certainly make a plot similar to the one given in your link. I 
> think you question relates more to the processing of your arrays 
> though, and not specifically the plotting. Are all your 2d arrays 
> the same shape (the same number of lats and lons)? Are they just 
> centered on different regions? If so, I think you can just multiply 
> each grid point by the cosine of latitude to get the proper area 
> weighting before summing them together. But perhaps I'm missing the 
> essence of your question ....
>
> -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
>
>

I'm curious about the term 'threading backend'.
Recently I posted a question about how to handle slow plots, suggesting
that the backend canvas have an isabort() method so that the renderer
can stop what it is doing and post the current bitmap as it stands.
This is to support interactive operations such as panning and resizing
on large data collections.
Do you mean something similar when you say 'threading backend', and is
it already supported in IPython?
 - Paul
On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote:
> Hi all,
> 
> This was posted to the ipython-dev list, but since it's specifically
> for MPL, I figured the cross-list spam would be forgiven.
> 
> In IPython SVN, I just added the ability to manually control the pylab
> threading backend choice directly from the command line. So for
> example if by default you have:
> 
> tlon[~]> ipython -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'TkAgg'
> 
> You can now do this as well:
> 
> tlon[~]> ipython -wthread -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'WXAgg'
> 
> In [2]:
> Closing threads... Done.
> tlon[~]> ipython -gthread -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'GTKAgg'
> 
> The feature is fairly simplistic: the -Xthread flags map automatically
> to the XAgg backends in MPL, with no more fine-grained choice than
> that. We can later look into allowing explicit backend selection if
> you really scream for it, but I'd rather keep this simple. This means
> that if you don't have the *Agg builds of the GUI backends, you'll
> still need to do the backend selection by hand as before (i.e. by
> modifying your mpl config file).
> 
> This has often been requested and I'd needed it myself on multiple
> occasions, so it's finally in.
> 
> Cheers,
> 
> f
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

All this sounds great. There has been some (off-list) discussion 
recently about making it easier to support third-party backends (i.e. 
backends that are maintained separately from the rest of the matplotlib 
tree). This Quartz backend may be a good test candidate for that 
(though I wouldn't worry about the details of that until some progress 
is made on making that possible). It seems like a natural fit for 
something that lives "a bit outside" since it is platform-specific.
Your list of advantages sound interesting. It will be great to see such 
things in action.
One minor comment --->
 > ability to offload rendering and/or coordinate
 > transformation to the graphics card
One of the desired goals of the transforms branch was to offload 
coordinate transformations to external renderers, for example, for PDF 
to offload it to Acrobat Reader via the PDF file. As it turns out, most 
of these systems (at least PDF, PS, SVG) all want to transform the 
stroke width using the same transform as the vertices of the object 
itself. So if you zoom in on the data, the line width becomes enormous. 
 As it turned out, we weren't really able to take advantage of that, 
and end up transforming most things within matplotlib itself anyway (in 
a C extension).
But coordinate transformation is not a significant part of the runtime 
of the current software-only approaches anyway.
 > ability to easily produce output
 > in any of the CoreImage supported formats,
As an alternative, you may want to look at how the GtkAgg backend 
outputs to any of GtkPixbuf's supported formats, while using Agg as the 
renderer. Something analogous is likely possible with Quartz.
Personally, I'm curious to see how Quartz backend performs at producing 
PDF output, particularly with respect to fonts. That was a difficult 
thing to get right (and it still has room for improvement) in mpl's own 
PDF backend.
Cheers,
Mike
Barry Wark wrote:
> Michael,
> 
> I'm sorry. I just realized I hadn't replied to you yet; sorry for the
> delay. John also pointed us to the transforms branch and that's where
> we'll start. Thanks! There's no real advantage to CoreAnimation per se
> (except eye candy), but going "native" for rendering would allow mpl
> to integrate more smoothly with the rest of the 2D and 3D (much of
> Quartz, and CoreImage the 2D rendering and filtering systems in OS X
> are actually rendered on the graphics card as OpenGL) rendering system
> in OS X. Some advantages, off the top of my head are resolution
> independence, ability to offload rendering and/or coordinate
> transformation to the graphics card, ability to easily produce output
> in any of the CoreImage supported formats, ability to incorporate
> transparency and alpha blending within the view hierarchy, ability to
> combine media (QuickTime, OpenGL, and Quartz) in layers (the real
> purpose of the CoreAnimation engine), ability to piggy back on
> improvements in Apple's rendering engine (things like anti-aliasing
> etc.), ColorSync support, and _maybe_ some speed improvements by
> taking a layer or two out of the rendering process. All of these are
> just speculation, at this time... we're just getting started but will
> share our results as soon as they're ready.
> 
> barry
> 
> 
> On 12/5/07, Michael Droettboom <md...@st...> wrote:
>> Barry Wark wrote:
>>> We (at my work) are just starting to think about writing a more direct
>>> Quartz backend for mpl. A native backend would let a matplotlib view
>>> participate in newer Cocoa technologies, such as resolution
>>> independence and CoreAnimation (it's possible with the current backend
>>> method, but not quite as flexible).
>> I'm curious what Cocoa and CoreAnimation might enable...
>>
>> If you are looking into writing a Quartz rendering backend, you may want
>> to start with the matplotlib transforms branch (which should become the
>> trunk shortly, once the 0.91 release bugs get shaken out.) The number
>> of methods that a backend writer must provide has been greatly reduced
>> on that branch.
>>
>> Cheers,
>> Mike
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote:
> You can now do this as well:
> tlon[~]> ipython -wthread -pylab --nobanner
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'WXAgg'
Hurray, mayavi and pylab can now easily live together. Thanks heaps
Fernando.
Gaël

Hi all,
This was posted to the ipython-dev list, but since it's specifically
for MPL, I figured the cross-list spam would be forgiven.
In IPython SVN, I just added the ability to manually control the pylab
threading backend choice directly from the command line. So for
example if by default you have:
tlon[~]> ipython -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'TkAgg'
You can now do this as well:
tlon[~]> ipython -wthread -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'WXAgg'
In [2]:
Closing threads... Done.
tlon[~]> ipython -gthread -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'GTKAgg'
The feature is fairly simplistic: the -Xthread flags map automatically
to the XAgg backends in MPL, with no more fine-grained choice than
that. We can later look into allowing explicit backend selection if
you really scream for it, but I'd rather keep this simple. This means
that if you don't have the *Agg builds of the GUI backends, you'll
still need to do the backend selection by hand as before (i.e. by
modifying your mpl config file).
This has often been requested and I'd needed it myself on multiple
occasions, so it's finally in.
Cheers,
f

I am trying to run scipy in XP on VMWare Workstation. The host OS is 
Ubuntu. When I attempt to launch scipy I get the error:
____________________________________________________________________________ 
C:\Documents and Settings\Administrator>C:\Python25\python.exe 
C:\Python25\scrip
ts\ipython -pylab -p scipy
Traceback (most recent call last):
File "C:\Python25\scripts\ipython", line 27, in <module>
IPython.Shell.start().mainloop()
File "C:\Python25\Lib\site-packages\IPython\Shell.py", line 1111, in start
return shell(user_ns = user_ns)
File "C:\Python25\Lib\site-packages\IPython\Shell.py", line 1008, in 
__init__
shell_class=MatplotlibShell)
File "C:\Python25\Lib\site-packages\IPython\Shell.py", line 74, in __init__
debug=debug,shell_class=shell_class)
File "C:\Python25\Lib\site-packages\IPython\ipmaker.py", line 95, in 
make_IPyt
hon
embedded=embedded,**kw)
File "C:\Python25\Lib\site-packages\IPython\Shell.py", line 562, in 
__init__
user_ns,b2 = self._matplotlib_config(name,user_ns)
File "C:\Python25\Lib\site-packages\IPython\Shell.py", line 463, in 
_matplotli
b_config
from matplotlib import backends
File "C:\Python25\Lib\site-packages\matplotlib\backends\__init__.py", 
line 55,
in <module>
new_figure_manager, draw_if_interactive, show = pylab_setup()
File "C:\Python25\Lib\site-packages\matplotlib\backends\__init__.py", 
line 24,
in pylab_setup
globals(),locals(),[backend_name])
File 
"C:\Python25\Lib\site-packages\matplotlib\backends\backend_tkagg.py", lin
e 8, in <module>
import tkagg # Paint image to Tk photo blitter extension
File "C:\Python25\Lib\site-packages\matplotlib\backends\tkagg.py", line 
1, in
<module>
import _tkagg
ImportError: DLL load failed: The specified module could not be found.
_____________________________________________________________________________________ 
I changed the back end to WxAgg with no luck.
_____________________________________
import wx
ImportError: no module named wx
_______________________________________
Any thoughts?
Thanks,
Bill

Michael,
I'm sorry. I just realized I hadn't replied to you yet; sorry for the
delay. John also pointed us to the transforms branch and that's where
we'll start. Thanks! There's no real advantage to CoreAnimation per se
(except eye candy), but going "native" for rendering would allow mpl
to integrate more smoothly with the rest of the 2D and 3D (much of
Quartz, and CoreImage the 2D rendering and filtering systems in OS X
are actually rendered on the graphics card as OpenGL) rendering system
in OS X. Some advantages, off the top of my head are resolution
independence, ability to offload rendering and/or coordinate
transformation to the graphics card, ability to easily produce output
in any of the CoreImage supported formats, ability to incorporate
transparency and alpha blending within the view hierarchy, ability to
combine media (QuickTime, OpenGL, and Quartz) in layers (the real
purpose of the CoreAnimation engine), ability to piggy back on
improvements in Apple's rendering engine (things like anti-aliasing
etc.), ColorSync support, and _maybe_ some speed improvements by
taking a layer or two out of the rendering process. All of these are
just speculation, at this time... we're just getting started but will
share our results as soon as they're ready.
barry
On 12/5/07, Michael Droettboom <md...@st...> wrote:
> Barry Wark wrote:
> > We (at my work) are just starting to think about writing a more direct
> > Quartz backend for mpl. A native backend would let a matplotlib view
> > participate in newer Cocoa technologies, such as resolution
> > independence and CoreAnimation (it's possible with the current backend
> > method, but not quite as flexible).
>
> I'm curious what Cocoa and CoreAnimation might enable...
>
> If you are looking into writing a Quartz rendering backend, you may want
> to start with the matplotlib transforms branch (which should become the
> trunk shortly, once the 0.91 release bugs get shaken out.) The number
> of methods that a backend writer must provide has been greatly reduced
> on that branch.
>
> Cheers,
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>

Fernando was right on. Here is his response to me:
Laptop - Ok
Windows XP Professional, Service Pack 2
AMD Athlon 64 3400+ (ClawHammer)
1.67 GHz, 768 MB of RAM
Chipset: SiS 755/755FX
Southbridge: SiS LPC Bridge
Instructions: MMX (+), 3DNow! (+), SSE, SSE2, x86-64
Machine 1 - Crashes
Windows XP Professional, Service Pack 2
AMD Athlon XP 2000+ (Thoroughbred)
1.67 GHz, 768 MB of RAM
ASUS A7V8X-X motherboard
Chipset: VIA KT400 (VT8377)
Southbridge: VIA VT8235
Instructions: MMX (+), 3DNow! (+), SSE
Machine 2 - Crashes
Windows XP Professional, Service Pack 2
AMD Athlon XP 2600+ (Barton)
1.92 GHz, 2.0 GB of RAM
ASUS A7V880 motherboard
Chipset: VIA KT880
Southbridge: VIA VT8237
Instructions: MMX (+), 3DNow! (+), SSE
I ran the following statements on both machines which caused it to crash:
import numpy
numpy.test()
Here is the output:
 Numpy is installed in C:\Python25\lib\site-packages\numpy
 Numpy version 1.0.4
 Python version 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
v.1310 32 bit (Int
 el)]
 Found 10/10 tests for numpy.core.defmatrix
 Found 36/36 tests for numpy.core.ma
 Found 223/223 tests for numpy.core.multiarray
 Found 65/65 tests for numpy.core.numeric
 Found 31/31 tests for numpy.core.numerictypes
 Found 12/12 tests for numpy.core.records
 Found 6/6 tests for numpy.core.scalarmath
 Found 14/14 tests for numpy.core.umath
 Found 4/4 tests for numpy.ctypeslib
 Found 5/5 tests for numpy.distutils.misc_util
 Found 1/1 tests for numpy.fft.fftpack
 Found 3/3 tests for numpy.fft.helper
 Found 9/9 tests for numpy.lib.arraysetops
 Found 46/46 tests for numpy.lib.function_base
 Found 5/5 tests for numpy.lib.getlimits
 Found 4/4 tests for numpy.lib.index_tricks
 Found 3/3 tests for numpy.lib.polynomial
 Found 49/49 tests for numpy.lib.shape_base
 Found 15/15 tests for numpy.lib.twodim_base
 Found 43/43 tests for numpy.lib.type_check
 Found 1/1 tests for numpy.lib.ufunclike
 Found 40/40 tests for numpy.linalg
 Found 2/2 tests for numpy.random
 Found 0/0 tests for __main__
 ................................................................................
 ................................................................................
 ................................................................................
 ................................................................................
 .....................................
Sounds like the problem is the fact that my desktop computers do not
support SSE2 instructions which are in the latest numpy binaries.
This also explains why it works fine on the laptop which does support
SSE2.
I piggy-backed onto an existing thread on the numpy list (is that bad
listserve etiquette? - probably: I now have the same question on two
lists and I tried to high jack a thread.). Unless someone has a
better idea, I will try and build from source for him. But my windows
building skills are not what they should be.....
Ryan
On Dec 11, 2007 2:06 PM, Fernando Perez <fpe...@gm...> wrote:
>
> On Dec 11, 2007 12:01 PM, Ryan Krauss <rya...@gm...> wrote:
> > I am trying to help a student get started with
> > Python/Scipy/Numpy/Matplotlib in windows. On one of his machines,
> > everything seems to install correctly, we can call figure(1) without a
> > problem, and plotting is fine until we try the show() command. Then
> > python crashes without much in the way of useful information. His
> > laptop is completely fine.
> >
> > We have downloaded a current rc file and set the backend to TkAgg.
> >
> > Any thoughts?
> >
> > How do we get more info to track down the problem?
>
> Go to the windows information screens and fetch out some CPU details.
> If it's a Pentium III, chances are the SSE2 instructions in the latest
> numpy binary are the culprit. If it's a newer chip, we'll need to dig
> deeper.
>
> Cheers,
>
> f
>