matplotlib-users Mailing List for matplotlib (Page 1431)

>>>>> "James" == James Boyle <bo...@ll...> writes:

    James> Until contouring is implemented, the only way to display 2D
    James> data is by pcolor.  I have two observations:

    James> (1) While trying to figure out exactly what pcolor was
    James> doing ( I did not understand the grid registration) I
    James> looked into the matlab documentation. The matlab docs
    James> explained what was going on, so that I could get my values
    James> properly aligned on the grid.  This brings up a question -
    James> How close does matplotlib follow Matlab?  Will there always
    James> be such a close correspondence in the implementation of
    James> functions such as I found in pcolor?

The matlab interface tries to follow matlab pretty closely, but not
religiously.  For example, in matlab you can say

  plot(x,Y) 

where Y is MxN and it will plot all the data in the array.  matplotlib
doesn't handle this case, currently.  In the case of errorbar, it made
more sense to extend the features (eg to support x and y asymmetric
errorbars) than slavishly follow the matlab signature.  

All other things being equal I try and implement the matlab signature.
It's usually a good motivator because it encourages you to add
features at design time that you might be tempted to leave out.

Why do you ask?

    James> (2) To do quantitative representation using pcolor, a
    James> colorbar function is needed. This feature does not appear
    James> on the list of future goals, I would like it to be
    James> added. I'm not that competent, but I will give it a try
    James> myself. The first few easy things I tried did not work out.

Agreed.  I just implemented this.  Unzip the following in your
site-packages dir

  http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib.py-0.54.2a.zip

After you have created a pcolor, just do 

  colorbar()

This will resize your axes to make room for the colorbar and display a
vertical colorbar (I haven't yet supported horizontal colorbars, as
matlab does).  If you want to use non-default limits for the colormap,
call cmap.set_clim(cmin, cmax) before the pcolor and colorbar, as in
this example

  cmap = ColormapJet(256)
  cmap.set_clim(cmin, cmax)
  pcolor(Z, cmap=cmap)
  colorbar()

Let me know how it goes!

JDH

John Hunter writes

> One more comment here, mainly for Todd.  
> 
> Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
> anim_tk.py, where both scripts are doing the same thing.  The profiler
> reveals a good chunk of the time is in
> 
>       103    2.300    0.022    2.300    0.022 tkagg.py:4(blit)
> 
> This may be a tk limitation, but I just wanted to point it out to you
> in case there are any optimizations you can apply to that function.
> 
> I'll include the anim_tk.py I'm using for profiling below.
> 
> Cheers,
> JDH
 
I do believe it is a limitation of the tk api (which the
blitting code uses) that makes writing to pixels of the 
tk window comparatively slow. It is possible to come up
with a tk interface using tkinter3000( aka wck) and some
hairy code to write directly to the window buffer. Eric
Jones has done this for the chaco implementation. Porting
it to matplotlib would take some work (how much I'm not
quite sure). It is isn't important to us right now so
we aren't going to do it for some time. If someone else
is interested they are welcome to. It does mean writing
a C or C++ implementation for each platform (i.e., X, win32, 
aqua). I know that the blitting can be improved by more 
than an order of magnitude in this way.

Perry

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:

    Gary> I took out a wristwatch and timed it instead of guessing.  I
    Gary> get three frames per second.  It's about 4x from where we
    Gary> started, but still slow.  I guess I'm just underpowered,
    Gary> although a couple of years ago this was a powerhouse.  It
    Gary> seems that matplotlib may not be suited to this task.  I
    Gary> don't think it should take 2 GHz just to power a stripchart.

One more comment here, mainly for Todd.  

Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
anim_tk.py, where both scripts are doing the same thing.  The profiler
reveals a good chunk of the time is in

      103    2.300    0.022    2.300    0.022 tkagg.py:4(blit)

This may be a tk limitation, but I just wanted to point it out to you
in case there are any optimizations you can apply to that function.

I'll include the anim_tk.py I'm using for profiling below.

Cheers,
JDH

#!/usr/bin/env python2.3
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.matlab
import Tkinter as Tk
import matplotlib.numerix as numerix

fig = matplotlib.matlab.figure(1)
ind = numerix.arange(60)
x_tmp=[]
for i in range(100):
    x_tmp.append(numerix.sin((ind+i)*numerix.pi/15.0))

X=numerix.array(x_tmp)
lines = matplotlib.matlab.plot(X[:,0],'o')

manager = matplotlib.matlab.get_current_fig_manager()
def updatefig(*args):
    updatefig.count += 1
    lines[0].set_ydata(X[:,updatefig.count%60])
    manager.canvas.draw()
    return updatefig.count
updatefig.count=-1


manager.show()
import time
tstart = time.time()
while 1:
    cnt = updatefig()
    if cnt==100: break
    



print 'FPS', 100.0/(time.time() - tstart)

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:

    Gary> I took out a wristwatch and timed it instead of guessing.  I
    Gary> get three frames per second.  It's about 4x from where we
    Gary> started, but still slow.  I guess I'm just underpowered,
    Gary> although a couple of years ago this was a powerhouse.  It
    Gary> seems that matplotlib may not be suited to this task.  I
    Gary> don't think it should take 2 GHz just to power a stripchart.

I agree.  The current design of matplotlib doesn't really support this
kind of use because it redraws the entire figure every time and does
too much duplicate work at the python level.  It shouldn't be too hard
to add some specialized functions for agg that support strip charts.
I've been planning to do it because we have a need for it here, and
there is some general on c.l.python for this kind of plotting feature
in python.

So I can start mulling over the design, can you tell me what kinds of
real time updates you need - only solid lines or arbitrary symbols
like 'o' too?  Anything else besides line plots?

I'm envisioning some extension code that talks directly to the data
source and to the agg backend, updating only part of the canvas.  The
blitting functions for GTK/WX/Tk Agg would have to be extended to blit
only a region of the canvas.

JDH

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:

    Gary> It seems that I can't completely override my choice of
    Gary> backend.  E.g., I have set TkAgg as my default back end.
    Gary> Yet if I modify examples/anim.py to include
    Gary> matplotlib.use('GTKAgg') or matplotlib.use('GTK') it will
    Gary> not run.  A window appears, but it contains a static,
    Gary> non-changing graph.  To run anim.py, I have to modify
    Gary> matplotlibrc.  Same behavior the other way: with GTKAgg
    Gary> selected in matplotlibrc, I can't run Todd's anim_tk.py,
    Gary> even with TkAgg selected in the script.  Am I doing
    Gary> something stupid?

It works as expected for me, both ways.  I can put TkAgg in my rc and
then matplotlib.use('GTKAgg') in anim.py and it works.  Ditto the
other way around. Any chance you are working in an IDE?  These changes
occur at module load time, and in an IDE such as IDLE, matplotlib will
only be loaded once.

JDH

It seems that I can't completely override my choice of backend.

E.g.,  I have set TkAgg as my default back end.  Yet if I modify
examples/anim.py to include matplotlib.use('GTKAgg') or
matplotlib.use('GTK') it will not run.  A window appears, but it contains a
static, non-changing graph.  To run anim.py, I have to modify matplotlibrc.
Same behavior the other way:  with GTKAgg selected in matplotlibrc, I can't
run Todd's anim_tk.py, even with TkAgg selected in the script.   Am I doing
something stupid?

-gary

----- Original Message ----- 
From: "John Hunter" <jdh...@ac...>
> >>>>> "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

I took out a wristwatch and timed it instead of guessing.   I get three
frames per second.  It's about 4x from where we started, but still slow.  I
guess I'm just underpowered, although a couple of years ago this was a
powerhouse.  It seems that matplotlib may not be suited to this task.  I
don't think it should take 2 GHz just to power a stripchart.

I've got new hardware coming this summer.  I get whatever IT gives me (until
I can find funds to buy my own), so I don't know what I'll be getting.
We'll see what happens.

I have another question, but I'll start a new thread for that ...

-gary

John Hunter wrote:

>>>>>>"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...
>
>
Just a note that the version of the above method in 0.54.1 still gives me:

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 296, in draw
    self.figure.draw(self.renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/figure.py", line 
130, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.2/site-packages/matplotlib/axes.py", line 607, 
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 209, 
in draw
    ismath=self.is_math_text())
  File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 200, in draw_text
    self._renderer.draw_text(
OverflowError: float too large to convert

When doint plot([0],[0]).
The above substitute fixes the problem though...


-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

A quick thank you to John,
I just wanted to confirm that 0.54.1 is behaving well on my Win98 system now and I'm looking forward to playing with line styles and more use of mathtext. The speed improvements are very noticeable too.
Thanks!

Gary Ruben 

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

This is a bug fix release

 * rotated text with newlines at all angles should work correctly now

 * fixed errorbar autoscaling and capsize problem 

 * right tick labels now in correct position

 * Added Gary's errorbar color options 

 * fixed some problems relating to singleton plots and constant plots

 * Tweaked TkAgg backend so that canvas.draw() works more like the
   other backends.  Fixed a bug resulting in 2 draws per figure
   manager show().  

 * several small optimizations to improve framerates on animated
   plots.

 * fixed a gtkagg on win98/winME bug

 * added converter=None option to plot_date for dates already in epoch
   format

 * made the figure background transparent in agg so matplotlib output
   can overlay another canvas.

http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=241494

>
>
>It turns out that the difference in execution times between these two
>cases is explained by the fact that the default plot style for plot is
>'-' and the default plot style for date is 'o'. 
>  
>
Yes.. changing the style to '-' fixes the performance issue... great!

>There is a small change I can make which is to allow converter to be
>None for the case in which your dates are already epoch.  This will
>save some cycles, 
>
Yes..  I would certainly be for it!.. But I'm biased - all my data is 
already epoch.. ;)

-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

Until contouring is implemented, the only way to display 2D data is by 
pcolor.
I have two observations:

(1) While trying to figure out exactly what pcolor was doing ( I did 
not understand the
grid registration) I looked into the matlab documentation. The matlab 
docs explained
what was going on, so that I could get my values properly aligned  on 
the grid.
This brings up a question - How close does matplotlib follow Matlab? 
Will there always
be such a close correspondence in the implementation of functions such 
as I found in pcolor?

(2) To do quantitative representation using pcolor, a colorbar function 
  is needed. This feature does not
appear on the list of future goals, I would like it to be added. I'm 
not that competent, but I will
give it a try myself. The first few easy things I tried did not work 
out.

>>>>> "Philippe" == Philippe Strauss <phi...@pr...> writes:

    Philippe> Hello, I would like to use plot_date, with a 'fill'
    Philippe> style of drawing.  Is it possible to do that?

date_plot doesn't do too much - it converts your dates to seconds
since the epoch and sets a date ticker and formatter.  You can do the
same yourself, and then call whatever function you want.  To borrow
and adapt Peter's example above.  

    import time
    from matplotlib.dates import EpochConverter
    from matplotlib.matlab import *
    from matplotlib.ticker import  DateFormatter, DayLocator, HourLocator

    now=time.time()
    then=now-60*60*24*2

    dates=arange(then, now, 20)   #Say have a point every 20 secs..
    vals= sin(0.001*pi*dates/60.0)

    fmt   = DateFormatter('%D')
    days  = DayLocator(1)
    hours = HourLocator(12)

    ax = subplot(111)
    ax.xaxis.set_major_locator(days)
    ax.xaxis.set_major_formatter(fmt)
    ax.xaxis.set_minor_locator(hours)

    fill(dates, vals)
    ax.autoscale_view()
    show()


See http://matplotlib.sf.net/matplotlib.ticker.html for more
information of tick locators and formaters.  See
http://matplotlib.sf.net/matplotlib.dates.html for info on how to
convert your datetime instances to seconds since the epoch.

Cheers,
JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:

    Peter> Hi: I was wondering whether anyone else has noticed a
    Peter> performance difference between using plot_date() and
    Peter> plot().  Here is a dummy script:

It turns out that the difference in execution times between these two
cases is explained by the fact that the default plot style for plot is
'-' and the default plot style for date is 'o'. 

Drawing a long connected line is still much faster than drawing a
bunch of circles.  I think if I start using collections in Line2D to
draw markers we'll see a performance boost there, but until I do it
it's hard to estimate how much. 

There is a small change I can make which is to allow converter to be
None for the case in which your dates are already epoch.  This will
save some cycles, but is negligible compared to the arc drawing time
in your example; from the profiler:

    60480    7.470    0.000    7.470    0.000 backend_agg.py:117(draw_arc)
    60480    0.200    0.000    0.200    0.000 dates.py:410(epoch)

But if I can get the marker performance much better by using
collections, then the conversion step will be worth bypassing.

JDH

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:

    Gary> Hi John, I can confirm that 0.54.1a fixes the crashing
    Gary> problem - thanks!  However, I tested it with a few errorbar
    Gary> plots and I noticed a few things.  You've changed the
    Gary> errorbar bar-ends to use markers, but the scaling is now
    Gary> different and seems no longer to be settable via the capsize
    Gary> parameter.  The autoscaling no longer works either.

Doh!  There was one major problem in that I had commented out the
return in maplotlib.matlab.errorbar during debugging.  This explains
all your problems with working on the return lines.  The body of that
function should be

    try: ret =  gca().errorbar(x, y, yerr, xerr, fmt, ecolor, capsize)
    except ValueError, msg:
        msg = raise_msg_to_str(msg)
        error_msg(msg)
    else:
        draw_if_interactive()
        return ret

I don't see any problems with the capsize or autoscaling.  Perhaps
with this new code you can see if you are still having troubles and
post an example.

Sorry for the troubles,
JDH

Hello,

I would like to use plot_date, with a 'fill' style of drawing.
Is it possible to do that?

Thanks

--
Philippe Strauss, ingénieur ETS, associé
phi...@pr...

http://www.practeo.ch/

Hi:

I was wondering whether anyone else has noticed a performance difference 
between using plot_date() and plot().
Here is a dummy script:

#!/usr/bin/env python

import time
from matplotlib.dates import EpochConverter
from matplotlib.matlab import *
from matplotlib.ticker import  DateFormatter, DayLocator, HourLocator

useDates=0

now=time.time()
weekAgo=now-60*60*24*7

dates=arange(weekAgo, now, 10)   #Say have a point every 10 secs..
vals=dates

if useDates:
   #Date plot

   fmt=DateFormatter('%D')
   days=DayLocator(1)
   hours=HourLocator(12)

   converter = EpochConverter()

   ax = subplot(111)
   plot_date(dates, vals, converter)

   ax.xaxis.set_major_locator(days)
   ax.xaxis.set_major_formatter(fmt)
   ax.xaxis.set_minor_locator(hours)

   #What will this do??
   #ax.autoscale_view()

else:
   #Regular plot
   plot(dates, vals)

ylabel('Number of points: '+str(len(dates)))
xlabel('time')
grid(True)
show()



I use python2.2 running on a 3.2 PIV with 2GB or ram  and when I use 
regular plotting, this takes ~1sec. With plot_date() it takes ~8sec.

I really like the flexibility of the way dates are handled but this 
seems to be too much of a performance hit for me to use (I ofter have 
data sets of  500 000 points). So my question is whether I am perhaps 
missing something trivial and not setting things up right. I cannot run 
any of the date_demo scripts because don't have python2.3 so cannot test 
how fast they run.

I will need to setup the x-axis labeling as dates, but now it seems it 
would be faster to just update the xticslabels of a "regular" plot.

Any thoughts?
Thanks.

--
Peter Groszkowski         Gemini Observatory
Tel: +1 808 974-2509      670 N. A'ohoku Place
Fax: +1 808 935-9235      Hilo, Hawai'i 96720, USA

Hi John,
I can confirm that 0.54.1a fixes the crashing problem - thanks!
However, I tested it with a few errorbar plots and I noticed a few things.
You've changed the errorbar bar-ends to use markers, but the scaling is now different and seems no longer to be settable via the capsize parameter.
The autoscaling no longer works either.

If I use the example:
--
from matplotlib.matlab import *

t = arange(0.1, 4, 0.1)
s = exp(-t)
e = 0.1*randn(len(s))
f = 0.1*randn(len(s))

l1 = errorbar(t, s, e, f)
set(l1, 'color', 'g')
show()
--

a traceback is generated:
Traceback (most recent call last):
  File "errorbar_demo.pyw", line 10, in ?
    set(l1, 'color', 'g')
  File "C:\APPS\PYTHON23\Lib\site-packages\matplotlib\matlab.py", line 1275, in set
    func = getattr(o,funcName)        
AttributeError: 'NoneType' object has no attribute 'set_color'

I'm pretty sure this worked in 0.53

If you change 
l1 = errorbar(t, s, e, f)
to
l1,l2 = errorbar(t, s, e, f)

you get another traceback:
Traceback (most recent call last):
  File "errorbar_demo.pyw", line 8, in ?
    l1,l2 = errorbar(t, s, e, f)
TypeError: unpack non-sequence

This worked in 0.53

If you remove the set() call, the plot appears, but you'll see the autoscaling is wonky.

I discovered these because I was trying to reproduce the plots on my python page <http://users.bigpond.net.au/gazzar/python.html>
When I try to reproduce the first one, I get a traceback. If I remove the l1,e1 assignment part and the legend call, no traceback occurs. I don't understand why:
The traceback produced is:

Traceback (most recent call last):
  File "_mass_matplotlib.py", line 17, in ?
    l1,e1=errorbar(m, PrimeVals(t), [NegErrs(t), PosErrs(t)], fmt='r')
TypeError: unpack non-sequence


When I try to reproduce the second plot, the plot window appears.
The scaling shown on my webpage is the autoscaling produced with 0.53 (xaxis=2->4.5, yaxis=5.?->5.32), but the autoscaling in 0.54.1a has the axis ranges of (xaxis=1->5.5, yaxis=4->6.5). Also I have to squint to see the bar-ends ;-)  <- (smiley of my left eye squinting)

regards and thanks for sorting out the GTKAgg stuff,
Gary

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> The good news is I can replicate it on my windows 98 box
    John> (and a windows ME box).  I've had no troubles on XP.  It is
    John> triggered by importing matplotlib.backends._gtkagg.  That's
    John> all I know so far, but I should be able to figure it out
    John> from here.

I rewrote _gtkagg using cxx and this seems to have fixed the problem
(at least on my test systems).  Flush the old, and try:

http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.win32-py2.3.exe

FYI, this should have your errorbar fixes in as well.

Good luck!
JDH

>> 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