matplotlib-users Mailing List for matplotlib (Page 2)

>> Perhaps John can comment on whether he foresees adding
>> write-to-stream functionality with Agg.
> I'd like to add it - I'll put it on the TODO list.
Thanks! I'm happy with your suggestion of string methods + PIL now, but =
a direct method would be great..
Trevor

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:
 Gary> The hard drive grinds away for a couple of seconds, then I
 Gary> get an Invalid Page Fault dialog with Python in the title
 Gary> bar. When I close the dialog, the DOS prompt returns, so
 Gary> it's not crashing the DOS window. No other windows appear in
 Gary> this sequence.
The good news is I can replicate it on my windows 98 box (and a
windows ME box). I've had no troubles on XP. It is triggered by
importing matplotlib.backends._gtkagg. That's all I know so far, but
I should be able to figure it out from here.
Thanks for the alert.
JDH

>>>>> "Rodrigo" == Rodrigo Caballero <rc...@ge...> writes:
 Rodrigo> I'm trying out version 0.54 ; it compiles fine, but on
 Rodrigo> import I get the following
 Rodrigo> /home/rca/lib/libpng.so.3: undefined symbol: deflate
 Rodrigo> I had no such problem with 0.53, which was linked against
 Rodrigo> the same png libs. Any ideas? Thanks, Rodrigo
This is a problem with zlib, on which png depends. Apparently zlib
flag was not added to the libraries list in 0.54, though this has been
fixed in CVS. Edit setupext.py and find the function
'add_agg_flags'. Right below the line that adds the png lib, add the
z lib, ie, 
def add_agg_flags(module):
 'Add the module flags to build extensions which use agg'
 # before adding the freetype flags since -z comes later
 module.libraries.append('png')
 module.libraries.append('z')
 add_base_flags(module)
 module.include_dirs.extend(['src','agg2/include', '.'])
 # put these later for correct link order
 module.libraries.extend(['stdc++', 'm'])
 module.libraries.append('png')
 module.libraries.append('z')
Hope this helps,
JDH

I'm trying out version 0.54 ; it compiles fine, but on import I get the 
following
 File "./diagnostic.py", line 9, in ?
 from matplotlib.matlab import *
 File "/home/rca/lib/python2.3/site-packages/matplotlib/matlab.py", 
line 133, in ?
 from axes import Axes
 File "/home/rca/lib/python2.3/site-packages/matplotlib/axes.py", line 
20, in ?
 from image import Image
 File "/home/rca/lib/python2.3/site-packages/matplotlib/image.py", 
line 9, in ?
 import _image
ImportError: /home/rca/lib/libpng.so.3: undefined symbol: deflate
I had no such problem with 0.53, which was linked against the same png 
libs.
Any ideas? Thanks,
Rodrigo
---
Rodrigo Caballero Augi (http://geosci.uchicago.edu/~rca)
Research Associate
Department of the Geophysical Sciences, University of Chicago
5734 South Ellis Avenue, Chicago, IL 60637, USA.

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
 Peter> Perhaps John can comment on whether he foresees adding
 Peter> write-to-stream functionality with Agg.
I'd like to add it - I'll put it on the TODO list. Shouldn't be too
hard...
In the meantime, you have the option of using string methods. Eg, if
you are using the agg backend
 plot(blah, blah)
 canvas = get_current_fig_manager().canvas
 canvas.draw()
 s = canvas.tostring_rgb() 
Use this in place of savefig / show. You can then print this string
to any stream you like.
See examples/to_numeric.py for an example of getting the agg canvas as
a string and then resizing it into a Numeric array or displaying it
with PIL.
JDH

>>>>> "Mathieu" == Mathieu Drapeau <mat...@mc...> writes:
 Mathieu> _transforms import Value, Point, Bbox, Affine
 Mathieu> ImportError: No module named _transforms
Most likely you are trying to run matplotlib in the dir you installed
it in. Switch to a different directory and try again. If you run
from the same dir that matplotlib is installed in, you can only see
the python files and not the extension code (eg _transforms)
 Mathieu> It is weird because it is working the second time I try
 Mathieu> the same import but as you can see, it seems that "plot"
 Mathieu> is not recognized after all.
This is normal. When you try and import a package a second time after
it has already failed, nothing happens (no error the second time).
This doesn't tell you anything useful though.
Your best bet is to cd into the matplotlib examples dir and try
 > python simple_plot.py
and see if this works.
Good luck!
JDH

Hi,
I installed matlibplot without any problems but when I tried to try it I 
got that error with the import:
 >>> from matplotlib.matlab import *
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "matplotlib/matlab.py", line 133, in ?
 from axes import Axes
 File "matplotlib/axes.py", line 9, in ?
 from artist import Artist
 File "matplotlib/artist.py", line 4, in ?
 from transforms import identity_transform
 File "matplotlib/transforms.py", line 180, in ?
 from _transforms import Value, Point, Bbox, Affine
ImportError: No module named _transforms
 >>> from matplotlib.matlab import *
 >>> plot([1,2,3,4])
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
NameError: name 'plot' is not defined
It is weird because it is working the second time I try the same import 
but as you can see, it seems that "plot" is not recognized after all.
Thanks,
Mathieu

>
>
>
>I'm trying to generate dynamic images, using CGI, with matplotlib. I'd like to have a CGI script return the images directly, instead of having to use savefig() first to write them to a file.
>
>Is there a way to do this?
>
> 
>
Technically yes.
When you are using the GD backend you can simply savefig to a stdout 
stream (ie. via savefig(sys.stdout)).
As of version 0.53 you could not do this (meaning write to a stream) 
directly with the Agg backend. matplotlib wants a file name, but you 
can't simply give it /dev/stdout (at least on a *nix) because it appends 
an extension.
So the bottom line is that if you're using GD then you're good to go. 
With Agg, you can either write to file and then read that in your CGI 
script, or modify the code that handles the writing - at one point 
(~v0.50) I did that for GD before it became part of the distro.
Perhaps John can comment on whether he foresees adding write-to-stream 
functionality with Agg.
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

On Wed, 2004年05月26日 at 13:09, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
> Todd> This turned out to be really easy so now canvas.draw
> Todd> triggers a blit and functions more like the other backends.
> Todd> It's in CVS. I also found an extraneous draw() so
> Todd> performance should be better, perhaps 2x.
> 
> Yep, I'm getting about 20fps on my system now. Much improved.
> 
> Gary, I'm uploading a zip file which has the new matplotlib python
> code. AFAIK, all the changes were made at the python level (right
> Todd?) 
Yes, the changes were pure Python and limited to backend_tkagg.py.
Todd
> so you should just be able to unzip this in your site-packages
> dir to try the new code. Let me know if it works, and what kind of
> performance you are getting now.
> 
> http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.zip
> 
> JDH
> 
-- 
Todd Miller <jm...@st...>

Hi,
I'm trying to generate dynamic images, using CGI, with matplotlib. I'd =
like to have a CGI script return the images directly, instead of having =
to use savefig() first to write them to a file.
Is there a way to do this?
Trevor

Hi,
I'm trying to generate dynamic images, using CGI, with matplotlib. I'd =
like to have a CGI script return the images directly, instead of having =
to use savefig() first to write them to a file.
Is there a way to do this?
Trevor

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> This turned out to be really easy so now canvas.draw
 Todd> triggers a blit and functions more like the other backends.
 Todd> It's in CVS. I also found an extraneous draw() so
 Todd> performance should be better, perhaps 2x.
Yep, I'm getting about 20fps on my system now. Much improved.
Gary, I'm uploading a zip file which has the new matplotlib python
code. AFAIK, all the changes were made at the python level (right
Todd?) so you should just be able to unzip this in your site-packages
dir to try the new code. Let me know if it works, and what kind of
performance you are getting now.
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.zip
JDH

Matt Newville wrote:
>Perry Greenfield wrote:
>
> 
>
>>We are trying to have setup.py handle X11-based Tkinter on Mac OS X
>>(to date that is the only Tkinter we use). Does anyone out there
>>use Tkagg with the Aqua-based Tkinter on Mac OS X? We are unclear
>>as to whether the Aqua version is really useful yet.
>> 
>>
It's been a little while since I've gotten down-and-dirty on OS X, but 
as of a year or so ago, I was continually frustrated with Tkinter on OS 
X because of apparent weird little bugs, but I never felt sufficiently 
on top of Tkinter to really believe they were bugs with Tkinter or with 
me. Anyhow, I switched to wx, and have never been happier. It looks 
great on Aqua, is totally cross-platform, and XRCed rocks!
>TkAgg with Aqua-based Tkinter works for me on Mac OS X. (That's
>with matplotlib 0.54 -- I haven't tried the latest CVS with fixes
>for dynamic updates, but am happy to hear it will be faster!). 
>
>The Aqua-based Tkinter is not great, and I would be perfectly happy
>using X11-based Tkinter. I simply installed the Tkinter with the
>MacPython and its PackageManager. Is X11-based Tkinter available in
>such a package, or does it require a source build?? A source build
>would be OK with me, but might make it difficult to distribute apps.
> 
>
Fink sticks to the X environment, so I'm 99% sure that if you install 
their Tkinter it'll run on X11. I think this probably means installing 
Python from fink, too. So you'd have 2 Pythons: Apple's and fink's (in 
/sw/bin/python, I guess). If you want to distribute apps as a packaged 
.dmg that someone can just download and run on an OS X system, the fink 
route seems a little, uh, challenging.
Good luck!
Andrew

Perry Greenfield wrote:
> We are trying to have setup.py handle X11-based Tkinter on Mac OS X
> (to date that is the only Tkinter we use). Does anyone out there
> use Tkagg with the Aqua-based Tkinter on Mac OS X? We are unclear
> as to whether the Aqua version is really useful yet.
TkAgg with Aqua-based Tkinter works for me on Mac OS X. (That's
with matplotlib 0.54 -- I haven't tried the latest CVS with fixes
for dynamic updates, but am happy to hear it will be faster!). 
The Aqua-based Tkinter is not great, and I would be perfectly happy
using X11-based Tkinter. I simply installed the Tkinter with the
MacPython and its PackageManager. Is X11-based Tkinter available in
such a package, or does it require a source build?? A source build
would be OK with me, but might make it difficult to distribute apps.
--Matt Newville <newville @ cars.uchicago.edu>

We are trying to have setup.py handle X11-based Tkinter on Mac OS X
(to date that is the only Tkinter we use). Does anyone out there
use Tkagg with the Aqua-based Tkinter on Mac OS X? We are unclear
as to whether the Aqua version is really useful yet.
Thanks, Perry Greenfield

>>>>> "matthew" == matthew arnison <ma...@ca...> writes:
 matthew> The call to tick_right() seems to produce different
 matthew> behaviour in 0.54. Instead of moving the tick labels to
 matthew> the right of the plot, it instead now moves the labels to
 matthew> just inside the left side of the plot. This it to the
 matthew> right of where they were, but not nearly as useful as the
 matthew> original behaviour. :)
 matthew> See the attached screenshot generated from two_scales.py
Hi Matthew, these are my favorite bug fixes - just a single character
change! In matplotlib.axis.YAxis._get_text2 (on or around line 311),
change
 t = Text(x=0, y=loc,
to
 t = Text(x=1, y=loc,
Should cure what ails you.
 matthew> Otherwise, congratulations on another excellent
 matthew> matplotlib release!
Thanks! Not without a few roadbumps along the way....
JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
 Peter> Hi: The following script:
 Peter> #!/usr/bin/env python from matplotlib.matlab import *
 Peter> figure(1) plot([0],[0]) show()
Thanks, Peter, for alerting me to this problem. I'm now adding this
script and several other instances of plotting constants in a variety
of guises to the unit testing scripts. I think the following fix will
work for you. Replace matplotlib.axes.Axes.add_line with
 def add_line(self, l):
 "Add a line to the list of plot lines"
 self._set_artist_props(l)
 
 xdata = l.get_xdata()
 ydata = l.get_ydata()
 if l.get_transform() != self.transData:
 xys = self._get_verts_in_data_coords(
 l.get_transform(), zip(xdata, ydata))
 self.update_datalim(xys)
 else:
 # the data are already using the data coord system - no
 # transforms necessary
 minx, maxx = min(xdata), max(xdata)
 miny, maxy = min(ydata), max(ydata)
 if minx==maxx:
 minx -= 1
 maxx += 1
 if miny==maxy:
 miny -= 1
 maxy += 1
 
 corners = ( (minx, miny), (maxx, maxy) )
 self.update_datalim(corners)
 l.set_clip_box(self.bbox)
 self._lines.append(l)
Passes my tests...
JDH

The call to tick_right() seems to produce different behaviour in 0.54. 
Instead of moving the tick labels to the right of the plot, it instead 
now moves the labels to just inside the left side of the plot. This it to 
the right of where they were, but not nearly as useful as the original 
behaviour. :)
See the attached screenshot generated from two_scales.py
Otherwise, congratulations on another excellent matplotlib release!
Cheers,
Matthew.

Inline responses follow ...
----- Original Message -----
> If you open up a DOS command shell and run
> from matplotlib.matlab import *
> plot([1,2,3])
> show()
> with 
> c:> python myscript.py -dGTKAgg
> what happens?
The hard drive grinds away for a couple of seconds, then I get an Invalid Page Fault dialog with Python in the title bar. When I close the dialog, the DOS prompt returns, so it's not crashing the DOS window. No other windows appear in this sequence.
> When you run from windows explorer and get a traceback,
> you often lose the DOS window that provides the required information.
> So it's best to debug from a command shell, though admittedly most of
> the windows shells suck.
Agreed. I use cygwin when I need a shell usually, although for the above test I used a standard windows command shell.
> This is intentional. Since Tkinter doesn't have a mainloop, we switch
> python to interactive mode after TkAgg finishes it's business and the
> Tk window remains open until the python shell is closed.
Oh. Thanks for explaining.
> I would be surprised if it's win98 specific. I haven't seen any
> problems so far that were specific to just one windows OS. They're
> basically all the same as far as I can see, Microsoft just keeps
> shrinkwrapping them and recharging you for them :-) I have win98 at
> home so I'll try and test a version there.
It'll be interesting to see if it's specific to my system which is always a possibility.
Thanks John.
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Hi:
The following script:
#!/usr/bin/env python
from matplotlib.matlab import *
figure(1)
plot([0],[0])
show()
gives this traceback:
Traceback (most recent call last):
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in callback
 self.draw()
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 42, in draw
 agg.draw()
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 299, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/figure.py", line 
128, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axes.py", line 603, 
in draw
 self.xaxis.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 463, 
in draw
 tick.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 130, 
in draw
 if self.label1On: self.label1.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/text.py", line 202, 
in draw
 ismath=self.is_math_text())
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 203, in draw_text
 self._renderer.draw_text(
OverflowError: float too large to convert
If I remember correctly, there was a similar issue when 0.53 came out.
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

On Tue, 2004年05月25日 at 17:11, Todd Miller wrote:
> On Tue, 2004年05月25日 at 11:13, John Hunter wrote:
> > >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> > 
> > Todd> I tried porting anim.py to TkAgg this morning and got it
> > Todd> basically working. There are two things that might account
> > Todd> for the trouble you've been having:
> > 
> > Todd> 1. With TkAgg, at least for now, you have to call the
> > Todd> figure manager show() method with each cycle rather than the
> > Todd> canvas draw() method.
> > 
> > Would it be possible to reorganize tkagg so that a call to canvas.draw
> > also triggers a blit so that the interface could be more consistent
> > across backends?
> 
> I've been on leave a lot today but I'll take a look at this either this
> evening or tomorrow morning.
> 
This turned out to be really easy so now canvas.draw triggers a blit and
functions more like the other backends. It's in CVS. I also found an
extraneous draw() so performance should be better, perhaps 2x.
Cheers,
Todd

On Tue, 2004年05月25日 at 11:13, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
> Todd> I tried porting anim.py to TkAgg this morning and got it
> Todd> basically working. There are two things that might account
> Todd> for the trouble you've been having:
> 
> Todd> 1. With TkAgg, at least for now, you have to call the
> Todd> figure manager show() method with each cycle rather than the
> Todd> canvas draw() method.
> 
> Would it be possible to reorganize tkagg so that a call to canvas.draw
> also triggers a blit so that the interface could be more consistent
> across backends?
I've been on leave a lot today but I'll take a look at this either this
evening or tomorrow morning.
Todd

> Gary: did Todd's example help you enough to speed you on your way?
>
> JDH
>
Well... I might say "yes", but you did put that word "speed" in there :)
If I run his code, it updates 1.5 frame per second. If I change the two
calls to
manager.canvas._tkcanvas.after(100, updatefig)
to
manager.canvas._tkcanvas.after(1, updatefig)
there is no difference in the speed.
FWIW, I'm on an 850MHz WinXP. IIRC, I get the same performance under linux
on the same machine.
You got five frames per second? When you say you improved performance
"without text" do you mean that you didn't label the axes?
Aside: I see that he calls show() in each iteration, yet John says show()
should only be called once per script. Todd seems
to be on top of this, so I'll take his word as good. Todd uses a figure
manager. I can copy that code, but I don't know what I'm doing with it. I
don't know what a figure manager does.
Finally, I'm not sure what he meant by "re-registering the handler with each
cycle". Does this mean call ....after() ?
Oh ... one last thing, and maybe this is somehow relevant ... Todd's
program crashes on exit with message:
>>> invalid command name "18438384callit"
 while executing
"18438384callit"
 ("after" script)
...after which I'm dumped into python (interactive prompt).
-gary

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> I tried porting anim.py to TkAgg this morning and got it
 Todd> basically working. There are two things that might account
 Todd> for the trouble you've been having:
 Todd> 1. With TkAgg, at least for now, you have to call the
 Todd> figure manager show() method with each cycle rather than the
 Todd> canvas draw() method.
Would it be possible to reorganize tkagg so that a call to canvas.draw
also triggers a blit so that the interface could be more consistent
across backends?
 Todd> 2. The Tk timed event system requires re-registering the
 Todd> handler with each cycle.
Or you can do something like this
 def updatefig(*args):
 updatefig.count += 1
 lines[0].set_ydata(X[:,updatefig.count%60])
 manager.show()
 return updatefig.count
 updatefig.count=-1
 while 1:
 cnt = updatefig()
 if cnt==100: break
 
 Todd> Performance was better than I thought it would be but still
 Todd> kinda slow.
I profiled this because it was slower than I expected. Turns out that
there is a huge performance hit in the changes I made to Text to
handle arbitrary rotations (a lot of time spent in Matrix getitem,
multiply, etc...). With text I could get only 5 frames per second;
w/o text I get 13 fps. The good news is that it will be easy to
optimize away most of the text based performance hit using more
efficient matrix operations and caching.
This can likely be improved further by using collections for drawing
markers in the line class.
Gary: did Todd's example help you enough to speed you on your way?
JDH

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:
 Gary> Hi John, I probably didn't make it clear, but TkAgg has
 Gary> problems too. Here's what I know: Under 0.53.1 TkAgg and
 Gary> GTKAgg both worked fine, both when running the script
 Gary> directly from Windows Explorer in which case file
 Gary> association cause python to fire up in a DOS shell, and when
 Gary> running it from within SciTE or IDLE things are fine
 Gary> too. 0.54 has changed something.
Well, it's changed a lot. The big dollar question is which of these
changes are causing these problems :-)
 Gary> I tried grabbing and
 Gary> running a few examples from CVS as well as my own previously
 Gary> working examples. They behave consistently - GTKAgg no
 Gary> longer works at all
I need clarification here. What does it mean "no longer works at
all". If you open up a DOS command shell and run
 from matplotlib.matlab import *
 plot([1,2,3])
 show()
with 
 c:> python myscript.py -dGTKAgg
what happens? When you run from windows explorer and get a traceback,
you often lose the DOS window that provides the required information.
So it's best to debug from a command shell, though admittedly most of
the windows shells suck.
 Gary> and TkAgg works but only if I run it from DOS with a
 Gary> -dTkAgg option. It may be a GUI conflict but it has only
 Gary> started to conflict with 0.54. removing show() or replacing
 Gary> it with show(mainloop=False) seem to make no difference to
 Gary> the behaviour running TkAgg from SciTE. 
show(mainloop=False) would only be expected to have any effect with
GTK*, but I understand that it's not helping in that case either.
 Gary> I do notice that
 Gary> the python >>> prompt comes up in any DOS windows when
 Gary> running with the -dTkAgg option after the Tk plot window
 Gary> displays. Closing the window then leaves the python prompt
 Gary> and I have to ^Z it to shut it down. It's like it thinks it
 Gary> should be running in interactive mode, although 'interactive
 Gary> : False' is set in my .matplotlibrc This seems abnormal to
 Gary> me.
This is intentional. Since Tkinter doesn't have a mainloop, we switch
python to interactive mode after TkAgg finishes it's business and the
Tk window remains open until the python shell is closed.
 Gary> In my original post I asked if anyone else had success or
 Gary> problems in Win98 and since noone replied, maybe we can
 Gary> assume that I'm one of the rare users who's still using
 Gary> it. Therefore, as much as I (and probably you) would like to
 Gary> get to the bottom of what's happening, it's probably Win98
 Gary> specific and therefore, can probably wait; at least until
 Gary> after my upcoming exams are over and I get a chance to
I would be surprised if it's win98 specific. I haven't seen any
problems so far that were specific to just one windows OS. They're
basically all the same as far as I can see, Microsoft just keeps
shrinkwrapping them and recharging you for them :-) I have win98 at
home so I'll try and test a version there.
 Gary> really look into it some more. So I might go quiet for a few
 Gary> weeks unless you want me to try anything quick and specific.
 Gary> Finally, I hope you didn't lose the ecolor changes I made to
 Gary> errorbars and they might make it into a future version :-)
No, I missed them the first time but when cleaning out my inbox found
them and made an entry on the TODO list, so they'll get merged soon
enough. Thanks.
If you could try the command shell test with GTKAgg that I asked for
above, that would be great.
JDH