matplotlib-users Mailing List for matplotlib (Page 9)

Hi all,
 
Is there a way to completely turn of anti-aliasing when saving to png?
 
I want to put graphs into a PowerPoint Presentation but there, anti-aliased
png-graphics look blurry.
I found how to turn anti-aliasing off for lines, but texts and axes are
still anti-aliased.
Is there a way to do that?
 
Thanks
 
 
Thomas

Hello there,
when I started with matplotlib I was really enthusiastic that I can throw
all those Excel, IDL, Matlab and whatever else I used until now overboard
and do everything from data processing to visualization in beloved Python.
Now, here at work I have to use a Windows PC and PowerPoint and graphics
just look best in PowerPoint if they are in EMF format.
Funny enough there seems to be no converter on the market to properly
convert any other vector format matplotlib can produce to EMF. Even the way
via Inkscape fails even with simple plots.
If I'm wrong about the converter, please tell me and bury EMF-support.
If not, what would you think would be the effort and the time needed to port
the emf-backend to the latest version of matplotlib? I might at least give
it a try.
Cheers,
Thomas
> -----Original Message-----
> From: Michael Droettboom [mailto:md...@st...]
> Sent: Friday, March 20, 2009 5:38 PM
> To: mat...@li...
> Subject: Re: [Matplotlib-users] EMF export doesn't work
> 
> Unfortunately, the EMF backend is no longer maintained. We had
> discussed removing it well over a year ago, and I actually thought it
> had been removed, but obviously it wasn't.
> 
> It needs someone to port it to the new backend API introduced in 0.98.x
> and to maintain that code. When quite some time ago, there really
> wasn't much interest in doing that. I would be happy to help someone
> with the details involved, but don't have the time myself at the moment.
> 
> Sorry for the confusion -- what do other developers think? Should we
> remove the backend and document the change, at least for the time being?
> 
> Mike
> 
> Torsten Bronger wrote:
> > Hallöchen!
> >
> > I use pyemf 2.0 and Matplotlib 0.98.5. If I try to save a trivial
> > plot into an EMF file, I get
> >
> > Traceback (most recent call last):
> > File "./make_plots.py", line 23, in <module>
> > figure.savefig(sample_name + "_pds.emf")
> > File "/usr/lib/python2.5/[...]/matplotlib/figure.py", line 990, in
> savefig
> > self.canvas.print_figure(*args, **kwargs)
> > File "/usr/lib/python2.5/[...]/matplotlib/backend_bases.py", line
1419,
> in print_figure
> > **kwargs)
> > File "/usr/lib/python2.5/[...]/matplotlib/backends/backend_emf.py",
> line 604, in print_emf
> > self.figure.draw(renderer)
> > File "/usr/lib/python2.5/[...]/matplotlib/figure.py", line 738, in
> draw
> > if self.frameon: self.patch.draw(renderer)
> > File "/usr/lib/python2.5/[...]/matplotlib/patches.py", line 301, in
> draw
> > renderer.draw_path(gc, tpath, affine, rgbFace)
> > File "/usr/lib/python2.5/[...]/matplotlib/backend_bases.py", line 74,
> in draw_path
> > raise NotImplementedError
> > NotImplementedError
> >
> > Is this a bug or a mal-configuration? The Python code was
> >
> > figure = pyplot.figure()
> > axes = figure.add_subplot(111)
> > x, y = numpy.loadtxt("data.dat", comments="#", usecols=(0,
> 1), unpack=True)
> > axes.semilogy(x, y)
> > figure.savefig("test.emf")
> >
> > Tschö,
> > Torsten.
> >
> >
> 
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> 

 Hello,
 i'm trying to use matplotlib to draw some rectangles on one screen. Every
rectangle has is own position (x,y) is own size, and each of them must have a
fill color in a colormap.
 Is there an example somewhere ?
 Thank you.
###################################################################### 
Jean-Christophe Penalva 

Thanks! I'll just add that if you want to use the ticker example it needs
to be:
......
zmin, zmax = 160, 500
locator = ticker.MaxNLocator(10) # if you want no more than 10 contours
locator.create_dummy_axis()
locator.set_bounds(zmin, zmax)
levs = locator()
....
On Mon, May 18, 2009 at 7:29 PM, Eric Firing <ef...@ha...> wrote:
> william ratcliff wrote:
>
>> Thanks! I think that explains a lot. In the full range of my dataset, I
>> do have some rather high values. Instead of masking them out, I was hoping
>> that I could just set a minimum and maximum value using clim to only display
>> values within that range--it sounds like I need to mask these values out if
>> I want the contours to be generated automatically. What I'd really like to
>> be able to do is set zlow and zhigh and renormalize the colorbar based on
>> that range (for example, blue the lowest value and red the highest value)
>> for display purposes without touching the underlying data...It might
>> complicate the signature of contour even more, but would it be possible to
>> define a zlow, zhigh, such that the contour levels are determined based on
>> that zlow and zhigh instead of the actual ranges in the data? If they are
>> undefined, the behavior would default to the actual range in the data? That
>> way, one could further separate the display of the data from the actual
>> data...
>>
>>
> William,
>
> Yes, it would be possible to put in zlow and zhigh kwargs--but why? Why
> not just generate the contours you want over the range you want, as I
> originally suggested? You can use linspace, or arange, or a Ticker. You
> *don't* need to mask out values that are out of range. You can supply a
> colormap that uses a color you specify for over-range and under-range
> values, if you like; see
> http://matplotlib.sourceforge.net/examples/pylab_examples/image_masked.html
> for an example of this (although most of the rest of the example is much
> more complicated than what you need for contourf.)
>
> Ticker example (untested):
>
> import matplotlib.ticker as ticker
> zmin, zmax = 160, 500
> locator = ticker.MaxNLocator(10) # if you want no more than 10 contours
> locator.set_bounds(zmin, zmax)
> levs = locator()
> # ... set up x, y, z ...
> contourf(x, y, z, levs)
>
>
> There was an earlier proposal that mappables, like ContourSet, accept norm
> kwargs vmin and vmax to be passed on to the norm when the default norm is
> used. I should look at this idea again. I'm not sure offhand whether it is
> a good idea, or whether it would take care of what you are asking for.
>
> Eric
>
> Thanks,
>> William
>>
>>
>> On Mon, May 18, 2009 at 6:18 PM, Eric Firing <ef...@ha... <mailto:
>> ef...@ha...>> wrote:
>>
>> william ratcliff wrote:
>>
>> Here, I've changed the number of contours to 15 and 45
>> respectively--and the problem still remains. Do I need to
>> manually set the ranges of the segments on the colorbar or
>> something? It would seem to me that somehow the new limits are
>> not being used in determining the boundaries of which color is
>> used for which set of values. I should also mention that I am
>> using a masked array for z (which is what gives rise to the
>> white square in the bottom right corner).
>>
>>
>> I was not suggesting just changing the *number* of contours, I was
>> suggesting explicitly setting the boundaries. This is almost always
>> a better strategy; the signature in which a number of contours is
>> specified is intended only for quick and dirty exploration (and
>> Matlab compatibility, which led to the overly complex set of
>> possible signatures for contour in mpl). When contour is called as
>> you called it, it doesn't know or care anything about clim; it finds
>> the range of your input data and linearly spreads the requested
>> number of values over approximately that range. (Actually, it uses
>> a ticker to do this, so contour values will fall on reasonably nice
>> numbers.) I suspect there is an unmasked high value that is making
>> the auto-detected range too large. What do you get from
>>
>> print z.min(), z.max()
>>
>>
>> If you don't set the clim, it is set automatically based on the
>> contour levels; so if you set the levels, you don't need to set the
>> clim.
>>
>> Colorbar gets its information from the ContourSet object.
>>
>>
>> Eric
>>
>>
>> Thanks,
>> William
>>
>>
>> On Mon, May 18, 2009 at 5:16 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...> <mailto:ef...@ha...
>>
>> <mailto:ef...@ha...>>> wrote:
>>
>> william ratcliff wrote:
>>
>> Hi! I have a question about contours and clim within
>> matplotlib. I load in some files and do some processing and
>> generate a contour plot using:
>>
>>
>> cmap=pylab.cm.jet
>> mycontour=pylab.contourf(x,y,z,95)#,
>>
>>
>>
>>
>> You don't really want 95 contour levels, do you?
>> Instead of using set_clim, set the contour levels you want, and
>> I
>> suspect everything will come out OK. E.g.,
>>
>> pylab.contourf(x,y,z,pylab.linspace(160, 500, 18))
>>
>> Eric
>>
>> mycontour.set_clim(vmin=160, vmax=500)
>> mycbar=pylab.colorbar()
>> mycbar.set_clim(vmin=160, vmax=500)
>> pylab.xlim((17,19.6))
>> pylab.show()
>>
>>
>> However, the behavior is rather unexpected for me. I
>> find that
>> the colorbar has values rather stretched for values above
>> the
>> cutoff specified in clim. Also, are the values
>> normalized between
>> the limits set in clim, or am I loosing a lot of dynamic
>> range?
>>
>>
>> Thanks,
>> William
>>
>>
>>
>

william ratcliff wrote:
> Thanks! I think that explains a lot. In the full range of my dataset, 
> I do have some rather high values. Instead of masking them out, I was 
> hoping that I could just set a minimum and maximum value using clim to 
> only display values within that range--it sounds like I need to mask 
> these values out if I want the contours to be generated automatically. 
> What I'd really like to be able to do is set zlow and zhigh and 
> renormalize the colorbar based on that range (for example, blue the 
> lowest value and red the highest value) for display purposes without 
> touching the underlying data...It might complicate the signature of 
> contour even more, but would it be possible to define a zlow, zhigh, 
> such that the contour levels are determined based on that zlow and zhigh 
> instead of the actual ranges in the data? If they are undefined, the 
> behavior would default to the actual range in the data? That way, one 
> could further separate the display of the data from the actual data...
> 
William,
Yes, it would be possible to put in zlow and zhigh kwargs--but why? Why 
 not just generate the contours you want over the range you want, as I 
originally suggested? You can use linspace, or arange, or a Ticker. 
You *don't* need to mask out values that are out of range. You can 
supply a colormap that uses a color you specify for over-range and 
under-range values, if you like; see 
http://matplotlib.sourceforge.net/examples/pylab_examples/image_masked.html
for an example of this (although most of the rest of the example is much 
more complicated than what you need for contourf.)
Ticker example (untested):
import matplotlib.ticker as ticker
zmin, zmax = 160, 500
locator = ticker.MaxNLocator(10) # if you want no more than 10 contours
locator.set_bounds(zmin, zmax)
levs = locator()
# ... set up x, y, z ...
contourf(x, y, z, levs)
There was an earlier proposal that mappables, like ContourSet, accept 
norm kwargs vmin and vmax to be passed on to the norm when the default 
norm is used. I should look at this idea again. I'm not sure offhand 
whether it is a good idea, or whether it would take care of what you are 
asking for.
Eric
> Thanks,
> William
> 
> On Mon, May 18, 2009 at 6:18 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> william ratcliff wrote:
> 
> Here, I've changed the number of contours to 15 and 45
> respectively--and the problem still remains. Do I need to
> manually set the ranges of the segments on the colorbar or
> something? It would seem to me that somehow the new limits are
> not being used in determining the boundaries of which color is
> used for which set of values. I should also mention that I am
> using a masked array for z (which is what gives rise to the
> white square in the bottom right corner).
> 
> 
> I was not suggesting just changing the *number* of contours, I was
> suggesting explicitly setting the boundaries. This is almost always
> a better strategy; the signature in which a number of contours is
> specified is intended only for quick and dirty exploration (and
> Matlab compatibility, which led to the overly complex set of
> possible signatures for contour in mpl). When contour is called as
> you called it, it doesn't know or care anything about clim; it finds
> the range of your input data and linearly spreads the requested
> number of values over approximately that range. (Actually, it uses
> a ticker to do this, so contour values will fall on reasonably nice
> numbers.) I suspect there is an unmasked high value that is making
> the auto-detected range too large. What do you get from
> 
> print z.min(), z.max()
> 
> 
> If you don't set the clim, it is set automatically based on the
> contour levels; so if you set the levels, you don't need to set the
> clim.
> 
> Colorbar gets its information from the ContourSet object.
> 
> 
> Eric
> 
> 
> Thanks,
> William
> 
> 
> On Mon, May 18, 2009 at 5:16 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...> <mailto:ef...@ha...
> <mailto:ef...@ha...>>> wrote:
> 
> william ratcliff wrote:
> 
> Hi! I have a question about contours and clim within
> matplotlib. I load in some files and do some processing and
> generate a contour plot using:
> 
> 
> cmap=pylab.cm.jet
> mycontour=pylab.contourf(x,y,z,95)#,
> 
> 
> 
> 
> 
> You don't really want 95 contour levels, do you?
> Instead of using set_clim, set the contour levels you want, and I
> suspect everything will come out OK. E.g.,
> 
> pylab.contourf(x,y,z,pylab.linspace(160, 500, 18))
> 
> Eric
> 
> mycontour.set_clim(vmin=160, vmax=500)
> mycbar=pylab.colorbar()
> mycbar.set_clim(vmin=160, vmax=500)
> pylab.xlim((17,19.6))
> pylab.show()
> 
> 
> However, the behavior is rather unexpected for me. I
> find that
> the colorbar has values rather stretched for values above the
> cutoff specified in clim. Also, are the values
> normalized between
> the limits set in clim, or am I loosing a lot of dynamic
> range?
> 
> 
> Thanks,
> William
> 
> 

Yeah... I'm not sure either. Eventually I just through in the towel, deleted everything and sudo apt-get install python-matplotlb
Thanks for the help though!
-Max
Date: 2009年5月18日 20:29:33 +0000
Subject: Re: Re: [Matplotlib-users] [matplotlib-devel] Error building from 	source - Ubuntu
From: jd...@gm...
To: uhl...@ho...
CC: mo...@de...; mat...@li...
On May 18, 2009 3:09pm, M Uhlenhuth <uhl...@ho...> wrote:
> 
> I discovered I actually did have python2.5-dev (just not a python-dev version 2.5!).
> 
> I compiled and ran the code, but I'm getting errors like:
> 
> In [2]: import matplotlib.pyplot as plt
> ---------------------------------------------------------------------------
> ImportError Traceback (most recent call last)
> 
> /home/maximus/ in ()
> 
> /usr/lib/python2.5/site-packages/matplotlib/pyplot.py in ()
> 2 
Normally when you compile and install from src, the default location is /usr/local rather than /usr. Did you override this with --prefix or --install-lib? If not, I wonder if you are not using the version you think you are. Also, check the FAQ
 http://matplotlib.sourceforge.net/faq/installing_faq.html
For suggestions on how to get a clean build and install.
JDH

Hi,
I run mpl from the svn trunk, but I ran into a problem today after 
pulling the newest version (my last update was probably a week ago). 
The full build output is copied below.
I build from trunk using the following commands:
$ python setup.py build_ext --inplace
$ python setupegg.py develop
and my build failed on setupegg.py. To be honest, I'm not sure what 
the second line even does, but in the past, I've run into problems 
without it.
Any help would be greatly appreciated.
-Tony
= 
= 
= 
= 
========================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.6svn
 python: 2.5.1 (r251:54863, Feb 6 2009, 19:02:12) [GCC
 4.0.1 (Apple Inc. build 5465)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.3.0
 freetype2: 9.16.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.29
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.4.0
 * WxAgg extension not required for wxPython 
 >= 2.8
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must 
be able
 * to "import gtk" in your build/install 
environment
 Mac OS X native: yes
 Qt: no
 Qt4: Qt: 4.4.0, PyQt4: 4.4.2
 Cairo: 1.4.12
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: 2008c
OPTIONAL USETEX DEPENDENCIES
 dvipng: 1.9
 ghostscript: 8.57
 latex: 3.141592
[Edit setup.cfg to suppress the above messages]
= 
= 
= 
= 
========================================================================
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends', 
'matplotlib.projections', 'mpl_toolkits', 'mpl_toolkits.mplot3d', 
'mpl_toolkits.axes_grid', 'matplotlib.sphinxext', 
'matplotlib.numerix', 'matplotlib.numerix.mlab', 
'matplotlib.numerix.ma', 'matplotlib.numerix.linear_algebra', 
'matplotlib.numerix.random_array', 'matplotlib.numerix.fft', 
'matplotlib.delaunay', 'dateutil', 'dateutil/zoneinfo']
running develop
running egg_info
writing lib/matplotlib.egg-info/PKG-INFO
writing namespace_packages to lib/matplotlib.egg-info/ 
namespace_packages.txt
writing top-level names to lib/matplotlib.egg-info/top_level.txt
writing dependency_links to lib/matplotlib.egg-info/dependency_links.txt
reading manifest template 'MANIFEST.in'
warning: no files found matching 'MANIFEST'
warning: no files found matching 'lib/mpl_toolkits'
writing manifest file 'lib/matplotlib.egg-info/SOURCES.txt'
running build_ext
building 'matplotlib.ft2font' extension
Traceback (most recent call last):
 File "setupegg.py", line 8, in <module>
 {'namespace_packages' : ['mpl_toolkits']}})
 File "setup.py", line 267, in <module>
 **additional_params
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/core.py", line 151, in setup
 dist.run_commands()
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 974, in run_commands
 self.run_command(cmd)
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 994, in run_command
 cmd_obj.run()
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/develop.py", line 27, in run
 self.install_for_development()
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/develop.py", line 88, in 
install_for_development
 self.run_command('build_ext')
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/cmd.py", line 333, in run_command
 self.distribution.run_command(command)
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 994, in run_command
 cmd_obj.run()
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/build_ext.py", line 46, in run
 _build_ext.run(self)
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/command/build_ext.py", line 290, in run
 self.build_extensions()
 File "/Library/Python/2.5/site-packages/Pyrex-0.9.8.5-py2.5.egg/ 
Pyrex/Distutils/build_ext.py", line 82, in build_extensions
 self.build_extension(ext)
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/build_ext.py", line 175, in 
build_extension
 _build_ext.build_extension(self,ext)
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/command/build_ext.py", line 453, in build_extension
 sources = self.swig_sources(sources, ext)
 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/build_ext.py", line 77, in 
swig_sources
 sources = _build_ext.swig_sources(self, sources) or sources
TypeError: swig_sources() takes exactly 3 arguments (2 given)

On Mon, May 18, 2009 at 07:56, John Hunter <jd...@gm...> wrote:
> I have uploaded the source and OSX binaries for the bugfix release of
> matplotlib-0.98.5.3 to
>
> http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
The homepage is saying that the latest release is 0.98.6svn, can this
be corrected?
Cheers
Adam

On 5/18/2009 6:25 PM Yannick Copin apparently wrote:
> rowspan=2, colspan=3) should actually do. What would be the syntax for 
> the following layouts?
> 
> +-----+-----+
> | | ax2 |
> | ax1 +-----+
> | | ax3 |
> +-----+-----+
subplot2grid(shape=(2,2), loc=(0,0), rowspan=2)
subplot2grid(shape=(2,2), loc=(0,1))
subplot2grid(shape=(2,2), loc=(1,1))
> +-------+---+
> | | |
> | ax1 |ax3|
> | | |
> +-------+---+
> | ax2 |
> +-----------+
subplot2grid(shape=(3,3), loc=(0,0), rowspan=2, colspan=2)
subplot2grid(shape=(3,3), loc=(0,2), rowspan=2)
subplot2grid(shape=(3,3), loc=(2,0), colspan=3)
Again, consider the tkinter grid manager.
hth,
Alan Isaac

Alan G Isaac <alan.isaac@...> writes:
> On 5/18/2009 4:27 PM Yannick Copin apparently wrote:
> > super-mongo WINDOW command (e.g.
> > http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83)
> 
> The functionality is good,
> but the syntax is awful.
It might not be crystal clear indeed at 1st glance, but once you get used 
to it (as I got used to sm-WINDOW command), it is fairly trivial to 
pre-visualize. And IMHO it would have the advantage of conciseness while 
an easy extension to subplot.
> subplot2grid(loc=(0,0), rowspan=2, colspan=3)
> 
> would confuse nobody (or so I claim).
Most probably... but me: I did not catch what subplot2grid(loc=(0,0), 
rowspan=2, colspan=3) should actually do. What would be the syntax for 
the following layouts?
+-----+-----+
| | ax2 |
| ax1 +-----+
| | ax3 |
+-----+-----+
+-------+---+
| | |
| ax1 |ax3|
| | |
+-------+---+
| ax2 |
+-----------+
Cheers.

On 5/18/2009 5:17 PM Alan G Isaac apparently wrote:
> subplot2grid(loc=(0,0), rowspan=2, colspan=3)
> would confuse nobody (or so I claim).
That should have been:
subplot2grid(shape=(3,3), loc=(0,0), rowspan=2, colspan=3)
Alan Isaac

william ratcliff wrote:
> Here, I've changed the number of contours to 15 and 45 respectively--and 
> the problem still remains. Do I need to manually set the ranges of the 
> segments on the colorbar or something? It would seem to me that somehow 
> the new limits are not being used in determining the boundaries of which 
> color is used for which set of values. I should also mention that I am 
> using a masked array for z (which is what gives rise to the white square 
> in the bottom right corner).
I was not suggesting just changing the *number* of contours, I was 
suggesting explicitly setting the boundaries. This is almost always a 
better strategy; the signature in which a number of contours is 
specified is intended only for quick and dirty exploration (and Matlab 
compatibility, which led to the overly complex set of possible 
signatures for contour in mpl). When contour is called as you called it, 
it doesn't know or care anything about clim; it finds the range of your 
input data and linearly spreads the requested number of values over 
approximately that range. (Actually, it uses a ticker to do this, so 
contour values will fall on reasonably nice numbers.) I suspect there is 
an unmasked high value that is making the auto-detected range too large. 
What do you get from
print z.min(), z.max()
If you don't set the clim, it is set automatically based on the contour 
levels; so if you set the levels, you don't need to set the clim.
Colorbar gets its information from the ContourSet object.
Eric
> 
> Thanks,
> William
> 
> On Mon, May 18, 2009 at 5:16 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> william ratcliff wrote:
> 
> Hi! I have a question about contours and clim within
> matplotlib. I load in some files and do some processing and
> generate a contour plot using:
> 
> 
> cmap=pylab.cm.jet
> mycontour=pylab.contourf(x,y,z,95)#,
> 
> 
> 
> 
> 
> 
> You don't really want 95 contour levels, do you?
> Instead of using set_clim, set the contour levels you want, and I
> suspect everything will come out OK. E.g.,
> 
> pylab.contourf(x,y,z,pylab.linspace(160, 500, 18))
> 
> Eric
> 
> mycontour.set_clim(vmin=160, vmax=500)
> mycbar=pylab.colorbar()
> mycbar.set_clim(vmin=160, vmax=500)
> pylab.xlim((17,19.6))
> pylab.show()
> 
> 
> However, the behavior is rather unexpected for me. I find that
> the colorbar has values rather stretched for values above the
> cutoff specified in clim. Also, are the values normalized between
> the limits set in clim, or am I loosing a lot of dynamic range?
> 
> 
> Thanks,
> William

Hi guys,
+1 for rowspan and colspan. Much cleaner I would say.
Chaitanya
On Mon, May 18, 2009 at 11:17 PM, Alan G Isaac <ala...@gm...> wrote:
> On 5/18/2009 4:27 PM Yannick Copin apparently wrote:
>> super-mongo WINDOW command (e.g.
>> http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83)
>
>
> The functionality is good,
> but the syntax is awful.
>
> Using a location along with
> a rowspan and colspan is a
> very established convention.
> (E.g., consider the tkinter
> grid manager.) It is
> completely explicit and
> simple, even when changing
> the extent in only a single
> direction.
>
> subplot2grid(loc=(0,0), rowspan=2, colspan=3)
>
> would confuse nobody (or so I claim).
>
> Alan
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 5/18/2009 4:27 PM Yannick Copin apparently wrote:
> super-mongo WINDOW command (e.g.
> http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83)
The functionality is good,
but the syntax is awful.
Using a location along with
a rowspan and colspan is a
very established convention.
(E.g., consider the tkinter
grid manager.) It is
completely explicit and
simple, even when changing
the extent in only a single
direction.
subplot2grid(loc=(0,0), rowspan=2, colspan=3)
would confuse nobody (or so I claim).
Alan

william ratcliff wrote:
> Hi! I have a question about contours and clim within matplotlib. I 
> load in some files and do some processing and generate a contour plot using:
> 
> 
> cmap=pylab.cm.jet
> mycontour=pylab.contourf(x,y,z,95)#,
You don't really want 95 contour levels, do you?
Instead of using set_clim, set the contour levels you want, and I 
suspect everything will come out OK. E.g.,
pylab.contourf(x,y,z,pylab.linspace(160, 500, 18))
Eric
> mycontour.set_clim(vmin=160, vmax=500)
> mycbar=pylab.colorbar()
> mycbar.set_clim(vmin=160, vmax=500)
> pylab.xlim((17,19.6))
> pylab.show()
> 
> 
> However, the behavior is rather unexpected for me. I find that the 
> colorbar has values rather stretched for values above the cutoff 
> specified in clim. Also, are the values normalized between
> the limits set in clim, or am I loosing a lot of dynamic range?
> 
> 
> Thanks,
> William
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,
Jae-Joon Lee <lee.j.joon@...> writes:
> I had a few off-list conversation with Alan, and I'm also quite agree
> with him for this issue.
[...]
> issue 2) It is not easy (actually impossible) to make an axes
> spanning multiple cells.
Regarding this 2nd issue, I appreciated long ago the flexibility and ease-of-use
offered by super-mongo WINDOW command (e.g.
http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83). Basically, this would be
the same as accepting a tuple as plotNum argument in matplotlib subplot(numRows,
numCols, plotNum) to specify the extent of the composed subplot in terms of
atomic subplots, e.g.
ax1 = subplot(2,2,(1,3))
ax2 = subplot(2,2,2)
ax3 = subplot(2,2,4)
would produce the following layout:
+-------+-------+
| | ax2 |
| | |
| ax1 +-------+
| | ax3 |
| | |
+-------+-------+
or 
ax1 = subplot(3,3,(1,5))
ax2 = subplot(3,3,(7,9))
ax3 = subplot(3,3,(3,6))
for 
+-------+---+
| | |
| ax1 |ax3|
| | |
+-------+---+
| ax2 |
+-----------+
My current naive implementation is the following:
def add_axes(fig, nrow, ncol, extent, **kwargs):
 pars = fig.subplotpars
 figW = pars.right-pars.left # Fig size
 figH = pars.top-pars.bottom
 subW = figW / (ncol + pars.wspace*(ncol-1)) # Sub-axes size
 subH = figH / (nrow + pars.hspace*(nrow-1))
 sepW = pars.wspace*subW # Separations
 sepH = pars.hspace*subH
 axL,axR,axB,axT = 1,0,1,0
 for num in extent:
 assert 0<num<=nrow*ncol
 irow, icol = divmod(num-1, ncol)
 subL = pars.left + icol*(subW + sepW)
 subB = pars.top - (irow+1)*subH - irow*sepH
 axL = min(axL,subL)
 axR = max(axR,subL+subW)
 axB = min(axB,subB)
 axT = max(axT,subB+subH)
 axW = axR-axL
 axH = axT-axB
 return fig.add_axes([axL,axB,axW,axH], **kwargs)
fig = figure()
ax1 = add_axes(fig,3,3,(1,5))
ax2 = add_axes(fig,3,3,(7,9))
ax3 = add_axes(fig,3,3,(3,6))
ax1.plot(randn(10),'b.')
ax2.plot(randn(10),'r.')
ax3.plot(randn(10),'g.')
draw()
Cheers.

On May 18, 2009 3:09pm, M Uhlenhuth <uhl...@ho...> wrote:
> I discovered I actually did have python2.5-dev (just not a python-dev 
> version 2.5!).
> I compiled and ran the code, but I'm getting errors like:
> In [2]: import matplotlib.pyplot as plt
> ---------------------------------------------------------------------------
> ImportError Traceback (most recent call last)
> /home/maximus/ in ()
> /usr/lib/python2.5/site-packages/matplotlib/pyplot.py in ()
> 2
Normally when you compile and install from src, the default location is 
/usr/local rather than /usr. Did you override this with --prefix or 
--install-lib? If not, I wonder if you are not using the version you think 
you are. Also, check the FAQ
http://matplotlib.sourceforge.net/faq/installing_faq.html
For suggestions on how to get a clean build and install.
JDH

I discovered I actually did have python2.5-dev (just not a python-dev version 2.5!).
I compiled and ran the code, but I'm getting errors like:
In [2]: import matplotlib.pyplot as plt
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/home/maximus/<ipython console> in <module>()
/usr/lib/python2.5/site-packages/matplotlib/pyplot.py in <module>()
 2 
 3 import matplotlib
----> 4 from matplotlib import _pylab_helpers, interactive
 5 from matplotlib.cbook import dedent, silent_list, is_string_like, is_numlike
 6 from matplotlib.figure import Figure, figaspect
ImportError: cannot import name interactive
I get errors like this too:
>>> from pylab import *
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.5/site-packages/matplotlib/pylab.py", line 201, in <module>
 from cbook import flatten, is_string_like, exception_to_str, popd, \
 File "/usr/lib/python2.5/site-packages/matplotlib/cbook.py", line 6, in <module>
 import re, os, errno, sys, StringIO, traceback, locale, threading, types
 File "/usr/lib/python2.5/threading.py", line 13, in <module>
 from collections import deque
 File "/usr/lib/python2.5/site-packages/matplotlib/collections.py", line 15, in <module>
 import matplotlib.cbook as cbook
 File "/usr/lib/python2.5/site-packages/matplotlib/cbook.py", line 158, in <module>
 class Scheduler(threading.Thread):
AttributeError: 'module' object has no attribute 'Thread'
When I built, I got a bunch of warnings:
maximus@maximus-laptop:/usr/lib/python2.5/site-packages/matplotlib$ sudo python setup.py build > ~/matplotliberr.txt
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from CXX/cxx_extensions.cxx:37:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
lib/matplotlib/delaunay/VoronoiDiagramGenerator.cpp: In member function ‘bool VoronoiDiagramGenerator::voronoi(int)’:
lib/matplotlib/delaunay/VoronoiDiagramGenerator.cpp:923: warning: ‘newintstar.Point::y’ may be used uninitialized in this function
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from src/path.cpp:8:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
src/path.cpp: In function ‘void clip_to_rect(PathIterator&, double, double, double, double, bool, std::vector<std::vector<XY, std::allocator<XY> >, std::allocator<std::vector<XY, std::allocator<XY> > > >&)’:
src/path.cpp:824: warning: ‘y’ may be used uninitialized in this function
src/path.cpp:824: warning: ‘x’ may be used uninitialized in this function
agg24/include/agg_conv_curve.h: In member function ‘unsigned int agg::conv_curve<VertexSource, Curve3, Curve4>::vertex(double*, double*) [with VertexSource = PathIterator, Curve3 = agg::curve3, Curve4 = agg::curve4]’:
agg24/include/agg_conv_curve.h:160: warning: ‘end_y’ may be used uninitialized in this function
agg24/include/agg_conv_curve.h:159: warning: ‘end_x’ may be used uninitialized in this function
agg24/include/agg_conv_curve.h:158: warning: ‘ct2_y’ may be used uninitialized in this function
agg24/include/agg_conv_curve.h:157: warning: ‘ct2_x’ may be used uninitialized in this function
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from src/ft2font.h:4,
 from src/backend_agg.cpp:10:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
In file included from src/backend_agg.cpp:37:
src/swig_runtime.h: In function ‘void SWIG_Python_AddErrorMsg(const char*)’:
src/swig_runtime.h:859: warning: format not a string literal and no format arguments
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from src/_image.h:13,
 from src/image.cpp:33:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from src/_png.cpp:9:
/usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
src/_png.cpp: In member function ‘Py::Object _png_module::read_png(const Py::Tuple&)’:
src/_png.cpp:275: warning: comparison between signed and unsigned integer expressions
src/_png.cpp:279: warning: comparison between signed and unsigned integer expressions
Thanks!
-Max

The grid line will reappear if you set high enough resolution.
plt.subplot(111, polar=True, resolution=100)
This should be filed as a bug, though.
I guess the current default for resolution is 1. I think this was to
enable to draw a straight line in polar projection. However, my guess
is that it has a side-effect that a angular gridline became a 0-length
line connecting two identical points.
-JJ
On Sun, May 17, 2009 at 2:51 PM, Magnus Benjes
<mag...@go...> wrote:
>> Magnus Benjes wrote:
>>> Hello,
>>> in version 0.98.5.2 the polar plot still has a problem with negativ
>>> angles.
>>> The polarplot is drawing a circle when the angle changes from negativ to
>>> positiv (e.g. from -0.01 to +0.01).
>>
>> Your example works fine with svn. I don't recall whether the problem was
>> fixed before the last release. I think it was.
>>
> Thank you for the hint, in version 0.98.6 the polar plot has no problems
> with negativ angles any more.
> But now there are only gridlines in radial direction and the gridlines in
> angular direction are missing.
>
> Magnus
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

John Hunter wrote:
> I have uploaded the source and OSX binaries for the bugfix release of
> matplotlib-0.98.5.3 to
> 
> http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
great, thanks!
Note that the Mac binaries are kind of mis-named:
matplotlib-0.98.5.3-py2.5-macosx10.5.zip
That implies that they only work on 10.5, but AFAICT, it is built for 
the python.org python, which works on 10.3.9 and above. In any case, it 
seems to work for me on 10.4
something like:
matplotlib-0.98.5.3-python.org-2.5-macosx.mpkg.zip
might be better.
But it works, which is the bigger deal!
Thanks to all that contributed.
-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...

John Hunter wrote:
> <Chr...@no...> wrote:
> I updated the plot_dates docstring in svn to point to matplotlib.dates
great, thanks!
> Not all of the methods currently support direct date/unit plotting,
> but we do try to extend support when we have reported failures, so if
> you post a script which exposes the problem I'll try and fix it.
OK. Enclosed. If you uncomment the "date2num" call, it works fine, but 
it crashes as it is.
Thanks,
-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...

Eric Firing wrote:
> No, you hit a bug. Thanks for the report and test script. It is fixed 
> in r7103.
> 
> If you are not running from svn, a workaround may be to specify the 
> angles as an ndarray or masked array with the shape set to (N,1) where N 
> is the number of arrows.
Yes, that seems to work. Thanks!
-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...

John Hunter wrote:
> On Sun, May 17, 2009 at 11:07 PM, Jae-Joon Lee <lee...@gm...> wrote:
> 
>> I think one possible solution would be to simply deprecate the support
>> for PIL image in imshow, and let users explicitly use array-interface
>> via asarray function.
>>
>> Is there any other idea?
>> I'll make this change unless someone come up with something.
> 
> I'm not wild about removing the PIL functionality entirely just to
> remove an inconsistency. Andrew wrote the PIL support -- perhaps he
> can comment.
I wouldn't remove PIL support in imshow immediately, either, but I think
deprecation should be OK. Since Image->numpy conversion is now happening
through the array interface, I don't think there's much call to support
PIL directly anymore. We should make the deprecation warning give the
appropriate hint ("In the future, 'imshow(pil_image)' will not be
supported. Use 'imshow(np.array(pil_image))' instead. Note that you may
need an origin='upper' keyword argument for the latter case.")
-Andrew

On Sun, May 17, 2009 at 11:07 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I think one possible solution would be to simply deprecate the support
> for PIL image in imshow, and let users explicitly use array-interface
> via asarray function.
>
> Is there any other idea?
> I'll make this change unless someone come up with something.
I'm not wild about removing the PIL functionality entirely just to
remove an inconsistency. Andrew wrote the PIL support -- perhaps he
can comment.
JDH

guillaume ranquet wrote:
>> On Mon, May 18, 2009 at 10:23 AM, guillaume ranquet <gra...@wy...> wrote:
>>>> I'm trying to get approx 4k points plotted into 5 subplots which I would
>>>> like interactive (ie: ability to zoom/pan ...).
>>>> there's nothing special except that the subplots share axe x.
>>>>
>>>>
>>>> It gets some seconds (3 to 5) on a p4 dual core @ 3Ghz to pan/zoom. It
>>>> seems utterly slow to me: what do you think? normal "rate" or flawed code?
>>>> I tried using various backend, embedding it into qt4 ... nothing helped
>>>> much.
>>>>
>>>> the code is quite fat atm (500 lines or so). I'll try to cut through the
>>>> code to get an example in a few lines if it's said my code is flawed and
>>>> the plotting rate should be way faster!
>> Instead of starting with your cod,e start from scratch and see if you
>> can reproduce the problem. If not, figure out what is different and
>> work your way up. Here is some test code -- note that Eric Firing
>> made a contribution on the svn trunk that significantly speeds up this
>> use case:
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>> fig = plt.figure()
>> Nplots = 5
>> Npoints = 5000
>> for i in range(Nplots):
>> if i==0:
>> ax = ax1 = fig.add_subplot(Nplots,1,i+1)
>> else:
>> ax = fig.add_subplot(Nplots,1,i+1, sharex=ax1)
>>
>> ax.plot(np.random.rand(Npoints))
>>
>> ax.set_xlim(100, 200)
>> plt.show()
> 
> 
> I think I put a finger on what breaks the performance, thx to your
> snippet of code.
> I forgot to mention that I'm using some axvlines here and there (500 per
> subplot).
(That's quite a lot...)
> it goes from slow to _unacceptably_ slow with the axvlines.
> 
Yes, it is generating a lot of draw events.
> I'm using the axvlines to mark some events that I need to know about in
> order to have an explanation of the variations of the curves.
> any advice on what to use to replace those?
Possibilities include a LineCollection, or a single line with markers. 
I suspect a single line with masked points used to break it up into 
vertical segments would also work, although I don't know how fast it 
would be. The markers approach would be fastest, I suspect.
Eric
> ----
> This message contains confidential information and may contain information that is legally privileged. If you have received this message by mistake, please immediately notify us and delete the original message. Thank you. 
> 
> Ce message contient des informations confidentielles. S'il vous est parvenu par erreur, merci de bien vouloir nous en aviser par retour, de n'en faire aucun usage et de n'en garder aucune copie.
> ----
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users