matplotlib-users Mailing List for matplotlib

Stephen Walton wrote:
> John asked what MATLAB does at present. The answer is: MATLAB's 
> image() displays arrays as does imshow(origin='upper'), with first 
> index increasing downward and second index increasing left to right, 
> but it has the y axis increasing from top to bottom.
I will add, in fairness to all concerned, that MATLAB has the same issue 
as matplotlib with respect to image position readout. If one uses 
MATLAB's ginput() to read pixel coordinates from a displayed image, they 
have to be reversed to address the corresponding data in the displayed 
array. Maybe the fairest thing is to tell me "this is how it works, get 
over it" :-) and move on.

I just upgraded to matplotlib 0.82 on a Win2K box running Python 2.3.5. I 
used the matplotlib-0.82.win32-py2.3.exe installer.
When I try to import matplotlib.pylab I get the following error:
E:\>python
Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import matplotlib.pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\pylab.py", line 198, in ?
 from axes import Axes, PolarAxes
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\axes.py", line 13, in ?
 from artist import Artist, setp
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\artist.py", line 4, in ?
 from transforms import identity_transform
 File "D:\ENTHOU~1\Lib\site-packages\matplotlib\transforms.py", line 190, 
in ?
 from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY
ImportError: cannot import name POLAR
There was a post to this effect on matplotlib-users by Cory Davis on 
10/25/04 but no response. Any help would be appreciated.
thanks,
Danny

Humufr wrote:
> I think that the problem is more that when you're using matshow to 
> draw a fits file read with pyfits you don't have the same image if you 
> open the fits file with ds9, the y axis is inverted.
Yes, but even that is an illusion as it were. See below.
> import pyfits
>
> scidata = pyfits.open('test.fits')[0].data
> matshow(scidata)
>
> ylim(0,scidata.shape[0])
It is easier to use imshow(scidata,origin='lower') here. But the fact 
that the image then looks the same when displayed in matplotlib and ds9 
is something of a fluke. ds9 displays the first FITS index increasing 
horizontally and the second increasing vertically (no reason not to, 
it's just a convention). PyFITS effectively transposes the array when 
it is read, but imshow() puts the first array index vertical. The 
result is that the image orientation looks the same when displayed in 
ds9 or matplotlib even though pixel (x,y) as displayed in ds9 is 
scidata[y-1,x-1] in Python. I was badly confused by this earlier in the 
week when checking some image coordinate computations in Python against 
the original Fortran IRAF code. Hence my first post.

Perry Greenfield wrote:
> On Jun 14, 2005, at 7:30 PM, Stephen Walton wrote:
>
>> 1. Is anyone else bothered by the fact that imshow(array) displays 
>> array[i,j] at Cartesian coordinates [j,shape(array)[0]-i] if origin 
>> is 'upper' and at [j,i] if origin is 'lower'?
>
> As with John, I'm not sure what the complaint is.
Perry is correct that it is likely my main problem is that the order of 
indices of astronomical FITS images is reversed when read in via 
PyFITS. He has commented on that issue extensively today over on the 
AstroPy mailing list, so I won't belabor the point here as it is not 
directly relevant to matplotlib anyway.
> Is it that the order is j,i or that lower and upper are defined the 
> way they are. If the latter, I'm not sure what was expected.
I do understand John's desire to have a displayed image appear in the 
same orientation as a list of pixels on the screen. But I want to be 
able to easily read image coordinates from a display and use them to 
address the underlying data. The Cartesian coordinates are displayed as 
(x,y) when one rolls the mouse pointer over the image, and so you have 
to reverse them, plus if origin='upper' you have to flip the y 
coordinate (image.shape[0]-y).
Specific suggestion: when an array is displayed with origin='upper', 
the y axis should increase downward, not upward. At least this way, 
pixel [i,j] always appears at Cartesian coordinates (j,i) and a program 
which, for example, overlays points plotted as (x,y) on an image won't 
break if a user changes image.origin in the .matplotlibrc file.
John asked what MATLAB does at present. The answer is: MATLAB's 
image() displays arrays as does imshow(origin='upper'), with first index 
increasing downward and second index increasing left to right, but it 
has the y axis increasing from top to bottom.

What's new in 0.82
Subplot configuration
 All of the parameters of the subplots are now exposed at the rc,
 pylab and API layout. These are left, right, bottom, top, wspace
 and hspace which control how the subplots are placed on the screen.
 See figure.SubplotParams, figure.Figure.subplots_adjust and the
 pylab method subplots_adjust and examples/subplots_adjust.py . Also
 added a GUI neutral widget for adjusting subplots, see
 examples/subplot_toolbar.py. There is a new toolbar button on GTK*,
 WX* and TkAgg to launch the subplot configuration tool (which uses
 the new matplotlib cross GUI classes discussed below). 
 This also makes it easier to make ganged plots -- see
 examples/ganged_plots.py
 Note this required a small change to how the toolbar on some GUIs
 are imported; if you are using the mpl API in WXAgg and GTKAgg, see
 API_CHANGES.
GUI neutral widgets
 Matplotlib now has cross-GUI widgets (buttons, check buttons, radio
 buttons and sliders). You have to manually create properly sized
 Axes for them to live in, but otherwise they are pretty easy to use.
 See examples/widgets/*.py and
 http://matplotlib.sf.net/screenshots.html#slider_demo. This makes
 it easier to create interactive figures that run across backends.
Cap and join style
 Exposes line cap and join style via new rc params and Line2D
 properties
 lines.dash_joinstyle : miter # miter|round|bevel
 lines.dash_capstyle : butt # butt|round|projecting
 lines.solid_joinstyle : miter # miter|round|bevel
 lines.solid_capstyle : projecting # butt|round|projecting
Axes kwargs
 All Axes properties are now exposed via kwargs, so you can do, for
 example
 subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
 xlim=(-1,1), ylim =(0,10) )
Small bugfixes and features:
 Fixed a upper/right tick bug (thanks Baptiste), fixed invalid rc
 docstring vis-a-vis aliases, fixed bug #1217637 in ticker.py and a
 cleanup bug in usetex (thanks Darren), added Sean Richards hist bin
 fix (see API_CHANGES)
http://matplotlib.sf.net
Enjoy!
JDH

 Hello,
I think that the problem is more that when you're using matshow to draw 
a fits file read with pyfits you don't have the same image if you open 
the fits file with ds9, the y axis is inverted.
To have the same view with matshow you must use something like:
ylim(0,scidata.shape[0])
ex:
import pyfits
scidata = pyfits.open('test.fits')[0].data
matshow(scidata)
ylim(0,scidata.shape[0])
I must admit that I'm a little agree with him, it very perturbating at 
the beginning and before to plot any fits data with matplotlib I prefer 
to test that the orientation is good.
Regards,
N.
Perry Greenfield wrote:
> Sorry for not responding until now, I've been tied up until today.
>
> On Jun 14, 2005, at 7:30 PM, Stephen Walton wrote:
>
>> This was originally a much longer message with a great deal of 
>> context, but I'm going to make it a lot shorter as a series of 
>> questions in the hopes of getting a Socratic dialog going?
>>
>> 1. Is anyone else bothered by the fact that imshow(array) displays 
>> array[i,j] at Cartesian coordinates [j,shape(array)[0]-i] if origin 
>> is 'upper' and at [j,i] if origin is 'lower'?
>>
> As with John, I'm not sure what the complaint is. Is it that the 
> order is j,i or that lower and upper are defined the way they are. If 
> the latter, I'm not sure what was expected.
>
>> 2. In light of the above, how do you handle overlaying contours on 
>> an image? I see by experiment that contour(array) also treats 
>> array[i,j] the same way as imshow.
>>
> Yes, they are supposed to be consistent. Is that a problem?
>
>> 3. Are the astronomers as confused by all of this in relation to the 
>> FITS WCS standard as I seem to be? How do I do the computation 
>> correctly so that x[i,j] is the first WCS coordinate of FITS pixel 
>> (i,j) (which is at array[j-1,i-1] after a PyFITS read)?
>>
>
> Are you asking if it is possible to redefine the order of indices for 
> an array (it is, but I'm not sure I'd recommend that)? Or is the 
> 0-based indexing of Python (and IDL as well) vs the 1-based indexing 
> of FITS and IRAF the issue? Or both?
>
> As to the order of indexing, I agree that it is probably (by far) the 
> single biggest annoyance for astronomers (I don't think there is any 
> painless solution though). I won't go on at length about this unless 
> I'm sure that this is the primary issue that is bugging you.
>
> Perry
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Michael Twomey wrote:
> I'd recommend trying Chris's binary package when he gets it done
> (Chris, do you need any help on that front?).
Well, not for what I intend to do, but I wasn't planning on building in 
PyGTK support. In a way, doing that is contrary to my goal, which is a 
package that can be installed on a stock OS-X (except Numerix, of 
course). i.e. fink-free.
However, it would probably work fine to have GTK compiled into the 
binary, and it shouldn't break any of the other back-ends...it just 
wouldn't work with PyGTK if PyGTK wasn't there, which is kind of obvious.
So, if someone want to build a package with PyGTK support, I'll send you 
what I have to docs, and you can go to it. I'd love for there to be only 
one "official" package, so if someone makes a superset of mine, I won't 
distribute mine.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Sorry for not responding until now, I've been tied up until today.
On Jun 14, 2005, at 7:30 PM, Stephen Walton wrote:
> This was originally a much longer message with a great deal of 
> context, but I'm going to make it a lot shorter as a series of 
> questions in the hopes of getting a Socratic dialog going?
>
> 1. Is anyone else bothered by the fact that imshow(array) displays 
> array[i,j] at Cartesian coordinates [j,shape(array)[0]-i] if origin is 
> 'upper' and at [j,i] if origin is 'lower'?
>
As with John, I'm not sure what the complaint is. Is it that the order 
is j,i or that lower and upper are defined the way they are. If the 
latter, I'm not sure what was expected.
> 2. In light of the above, how do you handle overlaying contours on an 
> image? I see by experiment that contour(array) also treats array[i,j] 
> the same way as imshow.
>
Yes, they are supposed to be consistent. Is that a problem?
> 3. Are the astronomers as confused by all of this in relation to the 
> FITS WCS standard as I seem to be? How do I do the computation 
> correctly so that x[i,j] is the first WCS coordinate of FITS pixel 
> (i,j) (which is at array[j-1,i-1] after a PyFITS read)?
>
Are you asking if it is possible to redefine the order of indices for 
an array (it is, but I'm not sure I'd recommend that)? Or is the 
0-based indexing of Python (and IDL as well) vs the 1-based indexing of 
FITS and IRAF the issue? Or both?
As to the order of indexing, I agree that it is probably (by far) the 
single biggest annoyance for astronomers (I don't think there is any 
painless solution though). I won't go on at length about this unless 
I'm sure that this is the primary issue that is bugging you.
Perry

>>>>> "Maria" == Maria Khomenko <mar...@ut...> writes:
 Maria> Hi, I am using pylab to plot several graphs. One graph
 Maria> appears in one class where I do the following:
 Maria> plot_date(date, y, 'g-o') savefig(path, dpi=75)
 Maria> Later on, in a different class, I do the a similar call:
 Maria> plot_date(d, z, 'b-') savefig(path, dpi=75)
 Maria> My problem is that the second call to plot_date simply
 Maria> appends the new line to the original graph and I am not
 Maria> sure why since the new graph also has new axis and a new
 Maria> label.
 Maria> It seems that the problem can be solved by calling
 Maria> hold(False) after plotting the first line. Yet, I would
 Maria> think that when I call the plot command in a separate class
 Maria> and set up the axis labels, etc. that it would
 Maria> automatically create a new set of axis, not append to the
 Maria> existing saved file.
 Maria> Is there something I should know? I would appreciate any
 Maria> feedback on this matter.
matplotlib has no idea whether you call functions from separate
classes or not. The concept of the current figure is a pylab
construct, and if you don't like it you can be more explicit about
figure and construction and management. Here is a snippet using pylab
class A:
 def __init__(self):
 self.fig = figure()
 self.ax = self.fig.add_subplot(111)
 def makeplot(self):
 self.ax.plot([1,2,3]) 
class B:
 def __init__(self):
 self.fig = figure()
 self.ax = self.fig.add_subplot(111)
 def makeplot(self):
 self.ax.imshow(rand(100,100))
Here you do not use the "current figure" or "current axes" of the
pylab interface because you explicitly make calls on the figure and
axes objects in their respective classes.
For even more fine grained control, you can avoid pylab altogether and
use the API as described at
http://matplotlib.sourceforge.net/faq.html#OO
Hope this helps,
JDH

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> This was originally a much longer message with a great
 Stephen> deal of context, but I'm going to make it a lot shorter
 Stephen> as a series of questions in the hopes of getting a
 Stephen> Socratic dialog going?
 Stephen> 1. Is anyone else bothered by the fact that
 Stephen> imshow(array) displays array[i,j] at Cartesian
 Stephen> coordinates [j,shape(array)[0]-i] if origin is 'upper'
 Stephen> and at [j,i] if origin is 'lower'?
Just to make sure I understand, does it bother you that rows and
columns are reversed, or is there a specific gripe with the upper and
lower handling. My motivation in doing is illustrated in this example
In [10]: x = arange(50.); x.shape=5,10
In [11]: imshow(x, interpolation='nearest', origin='upper')
Out[11]: <matplotlib.image.AxesImage instance at 0xb5f00e6c>
In [12]: x
Out[12]:
[[ 0., 1., 2., 3., 4., 5., 6., 7., 8., 9.,]
 [ 10., 11., 12., 13., 14., 15., 16., 17., 18., 19.,]
 [ 20., 21., 22., 23., 24., 25., 26., 27., 28., 29.,]
 [ 30., 31., 32., 33., 34., 35., 36., 37., 38., 39.,]
 [ 40., 41., 42., 43., 44., 45., 46., 47., 48., 49.,]]
The voxels on the screen and the array as printed have the same
layout: 5 rows and 10 columns. Basically the inversion happens
because event though it is tradtional to think of x as the first axis
and y as the second, visually if you move along the x axis you are
moving across columns and if you move along the y axis you are moving
along rows.
In any case, I am not sure exactly what your complaint is (and how you
want it to work) so I am just offering a bit of explanation of why it
is the way it is. I think matlab behaves differently, but I don't
have matlab installed right now. I am not sure that the way we are
doing it is the right way, so feel free to offer suggestions.
 Stephen> 2. In light of the above, how do you handle overlaying
 Stephen> contours on an image? I see by experiment that
 Stephen> contour(array) also treats array[i,j] the same way as
 Stephen> imshow.
Right; does that answer your question? If you want to flip the
indices, you can always transpose....
 Stephen> 3. Are the astronomers as confused by all of this in
 Stephen> relation to the FITS WCS standard as I seem to be? How
 Stephen> do I do the computation correctly so that x[i,j] is the
 Stephen> first WCS coordinate of FITS pixel (i,j) (which is at
 Stephen> array[j-1,i-1] after a PyFITS read)?
I'll leave this one to the astronomers... If desired, we can probably
add an option to handle images in the layout that is typical for
astronomers, but the image and contour code is already a bit hairy
trying to deal with upper and lower origin.
JDH

>>>>> "Philippe" == Philippe Collet <phi...@ho...> writes:
 Philippe> Hi list, I'm under windows XP SP2 using python 2.3.5,
 Philippe> matplotlib 0.80 and pygtk 2.6.0. I'm trying to program
 Philippe> a viewer of data using matplotlib. I want to be able to
 Philippe> save end reuse current graphic context (figure, title,
There is some tutorial information on using OO mpl at
http://matplotlib.sourceforge.net/faq.html#OO
 Philippe> axes, labels...). I decided to explore the matplotlib
 Philippe> code. But I'm not sure how i can get the current
 Philippe> figure.
Exploring the code is always a good way to start, as is reading the
class documentation for the classes you are working with, eg,
http://matplotlib.sourceforge.net/classdocs.html
Note that the concept of "the current figure" does not exist in the OO
API -- this is a pylab construct. You create a figure with 
 fig = Figure(args...)
and then it is your responsibility to save it and use it where you
want, eg in as a class variable
 self.fig = Figure(args...)
 Philippe> I want to be able to save the current graphic context,
 Philippe> draw a figure, then reload other data and add them to
 Philippe> the current figure already drawn.
 Philippe> Has anyone done that before? John, can you explain me
 Philippe> how to proceed?
This sounds eminently doable -- try writing some example code and if
you get stuck post the code and a description of what you are trying
to do and we can help out.
JDH

Rats, this looks like it should work.=20
I'd recommend trying Chris's binary package when he gets it done
(Chris, do you need any help on that front?).
You could try a completely fresh rebuild:
1. Completely remove
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
> packages/matplotlib/
2. Completely remove the build directory from your matplotlib-0.81 source t=
ree
3. try the setup.py build again
It's possible there is something which didn't cleanly relink itself.
Failing that it's probably going to be one of those annoying retry
step by step moments.
Michael
On 6/15/05, Brice Thurin <B.P...@ci...> wrote:
> Thank you for your response.
> I have been trying to follow your instruction, but still have the same
> error message. Matplotlib's ft2font.so links against
> /usr/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
> current version 10.8.0), which should be alright (I check with the
> install of freetype it has been installed in this folder).
>=20
> could you give anymore hints...
>=20
> Thanks
> Brice
>

Thank you for your response.
I have been trying to follow your instruction, but still have the same 
error message. Matplotlib's ft2font.so links against 
/usr/local/lib/libfreetype.6.dylib (compatibility version 10.0.0, 
current version 10.8.0), which should be alright (I check with the 
install of freetype it has been installed in this folder).
could you give anymore hints...
Thanks
Brice
On 14 Jun 2005, at 15:09, Michael Twomey wrote:
> Hi,
>
> (I am assuming you've built your own copy of matplotlib)
>
> This usually happens when matplotlib's ft2font.so links against OS X's
> copy of freetype, instead of a newer copy (which you have to install).
> The copy of freetype with OS X is too old to figure out some of the
> newer fonts (especially asian ones) installed on OS X.
>
> You can verify that it is linked against
> /usr/X11R6/lib/libfreetype.6.dylib using:
>
> $ otool -L 
> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- 
> packages/matplotlib/ft2font.so
> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- 
> packages/matplotlib/ft2font.so:
> /opt/local/lib/libfreetype.6.dylib (compatibility version
> 10.0.0, current version 10.7.0)
> ...
> (In my case I've linked against darwinports' freetype)
>
> AFAIK matplotlib will find fink's freetype automatically when
> building, if you install fink from http://fink.sourceforge.net/ and
> install freetype219 ("$ fink install freetype219"), then rebuild
> matplotlib all should be well.
>
> Michael
>
> On 6/14/05, Brice Thurin <B.P...@ci...> wrote:
>> I've just finished to install matplotlib on mac os X panther and when 
>> I
>> try to import pylab, i have got the following error:
>>
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in ?
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/pylab.py", line 1, in ?
>> from matplotlib.pylab import *
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/pylab.py", line 195, in ?
>> from axes import Axes, PolarAxes
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/axes.py", line 14, in ?
>> from axis import XAxis, YAxis
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/axis.py", line 21, in ?
>> from font_manager import FontProperties
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/font_manager.py", line 982, in ?
>> fontManager = FontManager()
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/font_manager.py", line 826, in __init__
>> rebuild()
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/font_manager.py", line 819, in rebuild
>> self.ttfdict = createFontDict(self.ttffiles)
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/font_manager.py", line 458, in createFontDict
>> prop = ttfFontProperty(font)
>> File
>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-
>> packages/matplotlib/font_manager.py", line 271, in ttfFontProperty
>> sfnt = font.get_sfnt()
>> RuntimeError: No SFNT name table
>>
>>
>> Could anyone help with this issue? Many thanks
>>
>> Brice
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you 
>> shotput
>> a projector? How fast can you ride your desk chair down the office 
>> luge track?
>> If you want to score the big prize, get to know the little guy.
>> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
Brice Thurin
Department of Optometry and Visual Science
City University, Northampton Square
London, EC1V 0HB, UK.
http://www.city.ac.uk/optometry/Luis/myresearch/Research/ 
scatteringproper.html
http://www.sharpeye.org/
Tel: +44 (0)20 7040 4157
Fax: +44(0)20 7040 8355
e-mail: B.P...@ci...

On 2005年6月13日, John Hunter wrote:
> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
>
> Arnd> If there is a simpler way to achieve this, I would of course
> Arnd> be interested. In general I think it would be nice to
> Arnd> change the joinstyle with a simple command, either globally
> Arnd> or even better on a line-by-line basis. Is this possible
> Arnd> already now in some way?
>
> There is no better way. I have been holding off on exposing this
> because I didn't see a clear way to handle it because dashed and solid
> lines have different default cap and join styles. It is now clear
> that c good solution is to expose dash_capstyle, dash_joinstyle,
> solid_capstyle, solid_joinstyle, as rc params and line properties.
>
> Any forseeable problems with this approach?
Sorry for the slow response (I was travelling) -
I think that what you propose sounds very good
(I can't see any problems, but this might be a lack of imagination ;-).
Best,
Arnd

On 2005年6月13日, John Hunter wrote:
> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
>
> Arnd> Well, difficult to estimate from my side, as I don't know
> Arnd> how much extra code it would be.
> >> From a (=my) user perspective I think it would be nice,
> Arnd> because I have a couple of situations where one plot should
> Arnd> stay with the same range in x and y whereas another plot
> Arnd> next to it should autoscale.
>
> Perhaps then the best solution is just to expose that property (and
> all other axes properties) in the subplot and axes functions. This
> seems like the cleanest, easiest implementation to me. I just checked
> this into CVS (axes.py revision 1.112).
[...]
> Thus you can do now do fun things like
>
> subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
> xlim=(-1,1), ylim =(0,10) )
>
> Very nice!
Indeed, I just updated from CVS, works absolutely fine!
*Many* thanks!!!
Best,
Arnd

On 2005年6月15日, Philippe Collet <phi...@ho...> wrote...
> Hi list,
> 
> I'm under windows XP SP2 using python 2.3.5, matplotlib 0.80 and pygtk 
> 2.6.0.
> I'm trying to program a viewer of data using matplotlib.
> I want to be able to save end reuse current graphic context (figure, title, 
> axes, labels...).
> I decided to explore the matplotlib code.
> But I'm not sure how i can get the current figure.
> 
> I want to be able to save the current graphic context, draw a figure, then 
> reload other data and add them to the current figure already drawn.
> 
> Has anyone done that before?
> John, can you explain me how to proceed?
A good place to start to get a feel for how to do this kind of thing is to
look in the examples directory of the source tree. In particular the
embedding_in_* ones may be of interest to you.
Feel free to get back to us if this doesn't give a good enough starting
point.
Cheers,
Tim
> 
> Thanks a lot,
> Philippe Collet
> 
> _________________________________________________________________
> MSN Messenger : discutez en direct avec vos amis ! 
> http://www.msn.fr/msger/default.asp
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
`-

Hi list,
I'm under windows XP SP2 using python 2.3.5, matplotlib 0.80 and pygtk 
2.6.0.
I'm trying to program a viewer of data using matplotlib.
I want to be able to save end reuse current graphic context (figure, title, 
axes, labels...).
I decided to explore the matplotlib code.
But I'm not sure how i can get the current figure.
I want to be able to save the current graphic context, draw a figure, then 
reload other data and add them to the current figure already drawn.
Has anyone done that before?
John, can you explain me how to proceed?
Thanks a lot,
Philippe Collet
_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis ! 
http://www.msn.fr/msger/default.asp

Is anyone using matplotlib with the GTK backend with versions 1.99.16 or 
1.99.17 of pygtk? If not I would like to change backend_gtk.py to require
pygtk 2.0.0 or higher.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com