matplotlib-users — Discussion related to using matplotlib

Re: [Matplotlib-users] alpha blending with embeded gtk.

[John H. <jdh...@ac...>]

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> Thanks very much indeed -- that has me sorted.  I'll give
    John> imshow a go as well when I get a chance.

    John> I've attached an image of the results to give you an idea
    John> what I'm up to.

Very nice..  what do the colors represent, pray tell?  Also, in case
you missed the announcement for 0.65, matplotlib now a number of new
colormaps, in addition to the trusty jet.

   autumn bone cool copper flag gray hot hsv jet pink prism spring
   summer winter

    John> I can't praise matplotlib highly enough, it has done 90% of
    John> the hard work in getting a very handy mapping tool together
    John> in a matter of days.

Great - thanks for the encouragement.

    John> Hope Santa brings you what you deserve.

With three kids, why do I get the feeling I won't be on the receiving
end of Christmas this year? :-)

JDH

Re: [Matplotlib-users] alpha blending with embeded gtk.

[John H. <jdh...@ac...>]

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> I'm having trouble getting the alpha keyword to do anything
    John> when I use the OO interface (as per gtk embeded example).

I'm not sure about the exact status of alpha vis-a-vis alpha - perhaps
Steve can clarify.  a gdk.Color does not have and alpha channel, nor
does a gdk.GC, but a gdk.Pixbuf does.  Basically, alpha is (mostly)
unsupported on the GTK backend (you can do alpha blending of images
because antigrain handles images across backends).  

But you should probably be using the gtkagg backend, which has alpha
support for all plot elements, and does a better job of anti-aliasing.
In some measurements, eg animation, it is a little slower than the
pure GTK backend, so you may want to do a little profiling.  It will
probably be faster than GTK for large collections, perhaps 2x or so,
since it does the collection drawing in extension code and the other
backends have a python implementation.

    John> Aside from this, I'd just like to say what a great package
    John> matplotlib is.  I've been using it a lot the last week to
    John> plot maps -- first I started using pcolor to plot hurricane
    John> footprints (I'll see if I can get the OK to release some of
    John> the plots, pcolor produced some wonderful pictures with a
    John> few lines of code).

if/when you have regularly spaced grids, imshow will likely be an
order of magnitude faster than pcolor for large data sets, so keep it
in mind....

    John> Inspired by this I've also been plotting simple maps by
    John> creating collections of polygons (eg one polygon for each
    John> country in the world) + associating a value with each
    John> polygon.  Again, great pictures in a few lines of code +
    John> using the collections the speed is pretty good, even with
    John> 3000+ polygons it was all pretty snappy.

    John> I'll see if I can get an example together -- to do this I'll
    John> need to get some un-restricted shape files, but I'll see
    John> what I can do.

That would be great - I'll keep my eyes peeled...

JDH

[Matplotlib-users] alpha blending with embeded gtk.

[John G. <jn...@eu...>]

I'm having trouble getting the alpha keyword to do anything when I use 
the OO interface (as per gtk embeded example).

The attached code demonstrates the problem.

With matlab_test() I get alpha blending as expected, with the 
gtk_embed_test() it seems to be ignored.

Aside from this, I'd just like to say what a great package matplotlib 
is.   I've been using it a lot the last week to plot maps -- first I 
started using pcolor to plot hurricane footprints (I'll see if I can get 
the OK to release some of the plots, pcolor produced some wonderful 
pictures with a few lines of code).

Inspired by this I've also been plotting simple maps by creating 
collections of polygons (eg one polygon for each country in the world) + 
associating a value with each polygon.  Again, great pictures in a few 
lines of code + using the collections the speed is pretty good, even 
with 3000+ polygons it was all pretty snappy.

I'll see if I can get an example together -- to do this I'll need to get 
some un-restricted shape files, but I'll see what I can do.

Many thanks for matplotlib.

John

[Matplotlib-users] ANN: matplotlib-0.65.1

[John H. <jdh...@ac...>]

This is primarily a bug-fix release from 0.65, though a couple of
little features managed to sneak in

 - 4x image speedups for large images

 - figimage bug fixed

 - fixed some bugs which caused the colorbar not to update properly
   when changing colormap interactively

 - refactored axes management to support delaxes, which deletes, as
   opposed to clears, a specified axes.  Default to current axes

 - tkagg's classic and new-fangled toolbars are now embeddable.

 - extended the new set/get introspection features to more classes

 - fixed some tkagg flakiness on win32 regarding unusual uses of show.

 - new cross backend animation idiom in examples/anim.py - use
   interactive mode rather than timers/idle handlers.

 - deferred some initializations in dates and colors modules for
   faster load times.


http://sourceforge.net/projects/matplotlib

Enjoy!

JDH 

Re: [Matplotlib-users] don't understand pcolor output. any help greatly appreciated

[John H. <jdh...@ac...>]

>>>>> "seberino" == seberino  <seb...@sp...> writes:

    seberino> I'm trying to make a 2D color plot where the z-axis
    seberino> values show up as different colors for each (x,y) point.
    seberino> I tried to plot the list a+b+c+d using the code snipped
    seberino> below.  I don't understand why this regular grid of
    seberino> points is giving me the weird color plot attached.  Any
    seberino> help would be greatly appreciated.

    seberino> WHY DON't I SEE **SQUARES** OF COLORS IN ATTACHED
    seberino> PLOT???

Because you are not filling your arrays properly.  Print xarray and
yarray in your example and you'll see the problem.  In your example,
xarray is

[[ 1  2  3  4]
 [ 5  6  7  8]
 [ 9 10  1  2]
 [ 3  4  5  6]
 [ 7  8  9 10]
 [ 1  2  3  4]
 [ 5  6  7  8]
 [ 9 10  1  2]
 [ 3  4  5  6]
 [ 7  8  9 10]]

is which is causing the weird plots you observe.

In your script, the problem line is

  xarray.shape = yarray.shape = zarray.shape = xsize, ysize

replace this with  

  xarray.shape = yarray.shape = zarray.shape = ysize, xsize

and you'll get the pcolor you are looking for, I suspect.


JDH

[Matplotlib-users] don't understand pcolor output. any help greatly appreciated

[<seb...@sp...>]

I'm trying to make a 2D color plot where the z-axis values show
up as different colors for each (x,y) point.  I tried to
plot the list a+b+c+d using the code snipped below.
I don't understand why this regular grid of points is giving
me the weird color plot attached.  Any help would be greatly
appreciated.

WHY DON't I SEE **SQUARES** OF COLORS IN ATTACHED PLOT???

a = [(1, 10, 1), (2, 10, 2), (3, 10, 3), (4, 10, 4),  (5, 10, 5),
     (6, 10, 4), (7, 10, 3), (8, 10, 2), (9, 10, 1), (10, 10, 0)]
b = [(1, 20, 1), (2, 20, 2), (3, 20, 3), (4, 20, 4),  (5, 20, 5),
     (6, 20, 4), (7, 20, 3), (8, 20, 2), (9, 20, 1), (10, 20, 0)]
c = [(1, 30, 1), (2, 30, 2), (3, 30, 3), (4, 30, 4),  (5, 30, 5),
     (6, 30, 4), (7, 30, 3), (8, 30, 2), (9, 30, 1), (10, 30, 0)]
d = [(1, 40, 1), (2, 40, 2), (3, 40, 3), (4, 40, 4),  (5, 40, 5),
     (6, 40, 4), (7, 40, 3), (8, 40, 2), (9, 40, 1), (10, 40, 0)]


        # Extracts arrays of values for each axis.

        xarray, yarray, zarray = zip(*plotdata)
        xarray = matplotlib.matlab.array(xarray)
        yarray = matplotlib.matlab.array(yarray)
        zarray = matplotlib.matlab.array(zarray)

        # Finds and sets shapes of arrays.

        ysize = len(sets.Set(yarray))
        xsize = len(yarray) / ysize
        xarray.shape = yarray.shape = zarray.shape = xsize, ysize

        # Create plot.

        matplotlib.matlab.pcolor(xarray, yarray, zarray)


Chris
--
_______________________________________

Christian Seberino, Ph.D.
SPAWAR Systems Center San Diego
Code 2872
49258 Mills Street, Room 158
San Diego, CA 92152-5385
U.S.A.

Phone: (619) 553-9973
Fax  : (619) 553-6521
Email: seb...@sp...
_______________________________________

Re: [Matplotlib-users] dynamic plots

[Arnd B. <arn...@we...>]

On Thu, 23 Dec 2004, Steve Chaplin wrote:

[...]

> > P.S: we just looked at backend_gtk.py.
> > Couldn't one safely replace
> >
> >     def draw_lines(self, gc, x, y):
> >         x = x.astype(nx.Int16)
> >         y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16)
> >         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> > by
> >
> >     def draw_lines(self, gc, x, y):
> >         x = x.astype(nx.Int16)
> >         y = self.height - y.astype(nx.Int16)
> >         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> >
> > ? It might give a small improvement.
> I hope so because I made this change to the code a few weeks ago and it
> is now in the file backend_gdk.py in matplotlib 0.65!
> It looks like you are running an old version of matplotlib.

Well, 0.64 ;-) Last week, before we started with this, there were
no debian packages for 0.65. But now they are,
  http://anakonda.altervista.org/debian/
Sorry for the duplication ...

Re: [Matplotlib-users] dynamic plots

[Steve C. <ste...@ya...>]

On Wed, 2004-12-22 at 15:43 +0100, Arnd Baecker wrote:
>From this we get for all **Agg backends that
>   - new_gc
>   - _draw_solid
>   - draw_text
> eat up a major part of the time.
> Another important part is spread in the draw chain
> (for example from 74.3% in  to 47.0 %+10.3 % in GTKAgg).

I've noticed that that new_gc() is called many times (60 times when running 
simple_plot.py) with each call creates a new GraphicsContext instance. I think
it would be more efficient to create just one GC instance and reuse it. It 
would suit the way that the Cairo, PS and possibly SVG and Agg backends 
do their drawing but that might mean completely changing the way the 
matplotlib frontend does its drawing.

> P.S: we just looked at backend_gtk.py.
> Couldn't one safely replace
> 
>     def draw_lines(self, gc, x, y):
>         x = x.astype(nx.Int16)
>         y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16)
>         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> 
> 
> by
> 
>     def draw_lines(self, gc, x, y):
>         x = x.astype(nx.Int16)
>         y = self.height - y.astype(nx.Int16)
>         self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))
> 
> ? It might give a small improvement.
I hope so because I made this change to the code a few weeks ago and it
is now in the file backend_gdk.py in matplotlib 0.65!
It looks like you are running an old version of matplotlib.

Steve

Re: [Matplotlib-users] dynamic plots

[John H. <jdh...@ac...>]

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

    Chris> This trick here is that the binary format of a wxBitmap is
    Chris> both platform and instance dependent. The idea, as I
    Chris> understand it, is that a wxBitmap has the same binary
    Chris> format as is needed for the current display, so each
    Chris> platform is different, and it can also be different
    Chris> depending on the depth of the display. Given all this, I
    Chris> doubt you're going to be able to improve on the wx supplied
    Chris> methods for converting from a wxImage to a wxBitmap. (and
    Chris> if you do, contribute it to wx!)

But this might helpful - if we can detect what kind of binary format
wx is using, we can ask agg to convert itself to this format in a
python buffer object and pass this on directly to the wxBitmap.  Agg
has efficient conversion routines from just about any pixel format to
any other.  This would avoid one copy, because we could do (making up
the syntax for copying a buffer into the bitmap

        FigureCanvasAgg.draw(self)
        if display_format=='ZZZ': # made up pixel format
           buffer = self.to_zzz()
           self.bitmap.UpdateFromBuffer(buffer) # made up method
        else:   # fall back on old method
            s = self.tostring_rgb()  
            w = int(self.renderer.width)
            h = int(self.renderer.height)
            image = wxEmptyImage(w,h)
            image.SetData(s)
            self.bitmap = image.ConvertToBitmap()
            self.gui_repaint()

If we could handle the most common cases, it would be a win for most
users.  Any idea how to query the pixel format of the wx display?

    Chris> Does the Agg backend use a binary format compatible with
    Chris> wxImage? If not, that means there are two conversions
    Chris> required, which might be the source of the slowdown.

agg uses an array of unsigned chars r0, b0, g0, a0, r1, b1, g1, a1,
...

What does wxImage use?

JDH

Re: [Matplotlib-users] dynamic plots

[Chris B. <Chr...@no...>]

Matt Newville wrote:
> I also agree that the best
> solution is likely to mean converting the Agg image (pixBuffer??)
> into the wx.bitmap in c++. 

This trick here is that the binary format of a wxBitmap is both platform
and instance dependent. The idea, as I understand it, is that a wxBitmap
has the same binary format as is needed for the current display, so each
platform is different, and it can also be different depending on the
depth of the display. Given all this, I doubt you're going to be able to
  improve on the wx supplied methods for converting from a wxImage to a
wxBitmap. (and if you do, contribute it to wx!)

Does the Agg backend use a binary format compatible with wxImage? If
not, that means there are two conversions required, which might be the
source of the slowdown.

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

Re: [Matplotlib-users] Arrow class, take 2

[John H. <jdh...@ac...>]

>>>>> "Dominique" == Dominique Orban <Dom...@po...> writes:

    Dominique> Aha. I just managed to have the stem drawn. My silly
    Dominique> mistake; i thought that to instantiate a Line2D i
    Dominique> needed to pass it (x0, y0) and (x1, y1), but it rather
    Dominique> expects (x0, x1) and (y0, y1). The arrow looks cool
    Dominique> now.

Rather than a line and a polygon, it might be more flexible and
attractive to design the arrow simply as a polygon (you could then
have control of the linewidth, facecolor, and edgewidth, something
like
         
                p0
              /   \
             /     \
            /       \
         p6--p5   p2--p1
             |    |
             |    |
             |    |
             |    |
             |    |    
             p4--p3


    Dominique> My remaining problem is the coordinates. It seems that
    Dominique> matplotlib is positioning the arrow using pixels as
    Dominique> coordinates, from the bottom left corner of the figure
    Dominique> window.

    Dominique> Is my problem a 'transformation' issue?

Yes.  If you derive your class from Artist and add it to the axes with
ax.add_artist (or Patch if you use the polygon approach above and add
it with ax.add_artist), the axes will set the default data
transformation for you, iff and only if you haven't already set the
transform.  There are three default transforms you can choose from 

  fig.transFigure   # 0,0 is lower left of fig and 1,1 is upper right
  ax.transAxes      # 0,0 is lower left of axes and 1,1 is upper right
  ax.transData      # same coordinates as the data in the axes

You have a additional choices with custom transforms.  One approach
would be to set the coordinates of the polygon in points such that the
arrow tip is 0,0 and the width and height are both 1.  You could then
use a scaling and rotation affine where sx, sy are the x and y scales,
and theta is the angle.  If you apply this affine to the arrow, the
width of the arrow would be sx points, the height sy points, and the
angle would be theta and the sucker would still be pointing at 0,0.
One nice feature of transformations is that the let you combine two
coordinate systems by applying a an offset transformation.  In this
case you'd want to apply and offset in data coords and then the arrow
would be pointing at some data location x,y but would still have a
width and height specified in points.  

This is basically how the ticks work.  An x tick is located at an x
location in data coords, a y location in axes coords (eg 0 for bottom
ticks and 1 for top ticks) and a length in points.


Here's an example.  I'm not sure this is the best design.  It might be
more useful to specify a point for the base and a point for the arrowhead,
and draw the arrow between them.  But I am not sure what the best way
to specify the arrow width if you use that design.  In any case, this
will serve as an example you can study to get an idea of how the
transforms work, and you can go from there. It would also be nice to
have some intelligent labeling built it, eg at the arrow base

from pylab import *
from matplotlib.patches import Polygon
from matplotlib.transforms import Affine, Value, zero
import math

class Arrow(Polygon):
    zorder = 4 # these should generally above the things they mark
    def __init__(self, x, y, xytrans, width, height, theta,
                 tipx=2, tipy=0.2):
        """
        Create an arrow pointing at x,y with a base width and total
        height in points

        theta is the arrow rotation - 0 degrees is point up, 90 is
          pointing to the right, 180 is pointing down, 270 is pointing
          left.

        tipx is the tip width and is expressed as fraction of the base width.

        tipy is the tip height expressed as a fraction of the total
          height

        xytrans is the transformation of the x,y coordinate, eg
          ax.transData for data coords and ax.transAxes for axes coords

        """
         
        #        p0
        #      /   \
        #     /     \
        #    /       \
        # p6--p5   p2--p1
        #     |    |
        #     |    |
        #     |    |
        #     |    |
        #     |    |    
        #     p4--p3

        p0 = 0,0
        p1 = tipx*0.5, -tipy
        p2 = 0.5, -tipy
        p3 = 0.5, -1        
        p4 = -0.5, -1
        p5 = -0.5, -tipy
        p6 = -tipx*0.5, -tipy        
        
        verts = p0, p1, p2, p3, p4, p5, p6
        Polygon.__init__(self, verts)


        theta = math.pi*theta/180.
        a = width*math.cos(theta)
        b = -width*math.sin(theta)
        c = height*math.sin(theta)
        d = height*math.cos(theta)
        a,b,c,d = [Value(val) for val in (a,b,c,d)]
        trans  = Affine(a, b, c, d, zero(), zero())
        trans.set_offset((x,y), xytrans)
        self.set_transform(trans)
        


plot([0,1,2], [1,2,3], 'bo', ms=15)
axis([0,3, 0, 4])

ax = gca()
arrow = Arrow(1,2, ax.transData, 10, 100, 135)
set(arrow, fc='g', ec='r', lw=1)
ax.add_patch(arrow)


show()

Re: [Matplotlib-users] Arrow class

[Alan G I. <ai...@am...>]

On Wed, 22 Dec 2004, Dominique Orban apparently wrote:
> Based on John's advice in a previous post about designing an Arrow class
> (http://sourceforge.net/mailarchive/message.php?msg_id=9962785), i have
> restarted from scratch, defining the stem as a Line2D instance and the
> head as a RegularPolygon instance (for now, a triangle).

This will be great.
I hope you will make sure the arrow head is
filled but not stroked, so that the tip ends
up precisely where desired.

Thank you,
Alan Isaac

Re: [Matplotlib-users] dynamic plots

[Arnd B. <arn...@we...>]

Hi Matt,

On Tue, 21 Dec 2004, Matt Newville wrote:

[...]

> I agree that the Agg rendering itself does not seem like the
> bottleneck for WXAgg.  Partly because of that, I'm assuming that
> the WXAgg will be good enough for my needs (as opposed to
> completely rewriting backend_wx) and that getting to GTKAgg level
> of performance would be the goal.  I also agree that the best
> solution is likely to mean converting the Agg image (pixBuffer??)
> into the wx.bitmap in c++.  I'm not sure I have a firm grasp on
> how exactly to do that, but it's worth trying.

We did some more profiling (see the other mail) which
confirms that the calls to ConvertTotBitmap and wxEmptyImage
are the main difference to GTKAgg.
The best would be to directly blit the Agg image
onto the wxFrame (however this assumes that these are
of the same type, which we don't know.
If not, the C++ route should be the fastest.
Unfortunately we both don't speak C++ and cannot
help further here).

Best,

Nikolai and Arnd

Re: [Matplotlib-users] dynamic plots

[Arnd B. <arn...@we...>]

Hi John,

On Tue, 21 Dec 2004, John Hunter wrote:

> >>>>> "imaginee1" == imaginee1  <ima...@gm...> writes:
>
>     imaginee1> Hi, after spending a nice afternoon profiling the
>     imaginee1> dynamic examples and looking a bit through the code, we
>     imaginee1> can make a few comments on the performace of the wx
>     imaginee1> backends.  We have used kcachegrind to display the
>     imaginee1> results of hotshot - all files can be found under
>     imaginee1> http://www.physik.tu-dresden.de/~baecker/tmp/profiling/
>
> Hi Arnd, thanks for your profiling information - I very much like the
> hotshot graphs!

Nikolai and I were also quite impressed, in particular
because there is another window in which one
can see the corresponding lines of code, including timings
(even down to the wxpython level!).

However, we don't understand the output completely.
One reason certainly is that we don't know the matplotlib
code well enough. Another reason is that there might
be some glitches (either kcachegrind or the
conversion script).

We just did some more profiling,
for TkAgg, GTK, GTKAgg, WX and WXAgg, see:
  http://www.physik.tu-dresden.de/~baecker/tmp/profiling2/

From this we get for all **Agg backends that
  - new_gc
  - _draw_solid
  - draw_text
eat up a major part of the time.
Another important part is spread in the draw chain
(for example from 74.3% in  to 47.0 %+10.3 % in GTKAgg).

Best,

Nikolai and Arnd


P.S: we just looked at backend_gtk.py.
Couldn't one safely replace

    def draw_lines(self, gc, x, y):
        x = x.astype(nx.Int16)
        y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16)
        self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))


by

    def draw_lines(self, gc, x, y):
        x = x.astype(nx.Int16)
        y = self.height - y.astype(nx.Int16)
        self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y))

? It might give a small improvement.

P.P.S: Thanks for mentioning good experiences with GTK under
Windows - we will give it a try.

[Matplotlib-users] Arrow class, take 2

[Dominique O. <Dom...@po...>]

Aha. I just managed to have the stem drawn. My silly mistake; i thought 
that to instantiate a Line2D i needed to pass it (x0, y0) and (x1, y1), 
but it rather expects (x0, x1) and (y0, y1). The arrow looks cool now.

My remaining problem is the coordinates. It seems that matplotlib is 
positioning the arrow using pixels as coordinates, from the bottom left 
corner of the figure window.

Is my problem a 'transformation' issue?

Thanks,
Dominique

Re: [Matplotlib-users] Error: This application has requested the Runtime to terminate it in an unusual way

[Axel K. <A.K...@gm...>]

Hello John,

>Axel, try replacing the FigureManagerTkAgg code in
>site-packages/matplotlib/backends/backend_tkagg.py with the following
>
>  
>
Perfect. Problem solved !

Best wishes and a merry Christmas,

                               Axel

[Matplotlib-users] Arrow class

[Dominique O. <Dom...@po...>]

Hi,

Based on John's advice in a previous post about designing an Arrow class 
(http://sourceforge.net/mailarchive/message.php?msg_id=9962785), i have 
restarted from scratch, defining the stem as a Line2D instance and the 
head as a RegularPolygon instance (for now, a triangle).

I can correctly set the orientation of the arrow head, and from 
debugging information, the class seems to be basically working. The 
class is imported in axes.py and i have defined the new methods 
add_arrow() and arrow()  in Axes. Arrows are stored in a list called 
arrows (i know John advised to avoid the overhead of that---i am simply 
trying to get it to work first).

Now, i know i am missing something (and this must be at the heart of 
matplotlib): how are 'figure coordinates' transformed into 'axes 
corrdinates'? I guess it has to do with the 'transforms' module but.... 
For instance, if i say

    arrow( [0,1], [0,1] )

with the intent of drawing an arrow from (0,0) to (1,1), i can't see the 
graphical result. Now if i say

    arrow( [0,100], [0,100] )

I can see something (the arrow head). And this may or may not be the 
source of my 2nd problem: the arrow head is drawn, but not the stem (as 
in the thread linked to above). The draw() method of my Arrow class is 
very simple:

    self._stem.draw(renderer)
    self._head.draw(renderer)

Any help would be greatly appreciated. I'll be happy to add spiff to the 
Arrow class once i have a basic version of it working and contribute it 
to matplotlib.

I can post some code if you would like; i just thought it would be too 
long in a mailing list...

Thanks,
Dominique

ps: Thanks for the matplotlib manual!


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.3 - Release Date: 12/21/2004

Re: [Matplotlib-users] dynamic plots

[Matt N. <new...@ca...>]

Hi Arnd, John, all,

Thanks for the profiling information on WX and WXAgg backends, and
sorry I haven't been able to participate in this conversation
more.  I've been running experiments for several weeks, and am
definitely looking forward to a break!  Hopefully I'll be able to
devote some time to this in January.

I'm really not a wx or matplotlib expert, buit I am definitely
interested in getting WX or WXAgg to go faster.  Re-drawing line
scans at 15Hz would be plenty fast enough for my needs but I would
like that to include rescaling the axes as well as updating the
line (which is what most of the current benchmarks test).  
Refreshing relatively small images at 1Hz would be OK for me - I
think that's already good enough for me.  Also, I'll have to admit
my timeframe is probably going to be slower than many people on
this list!  So if you or someone else wants to jump in, that would
be fine with me.
  
I agree that the Agg rendering itself does not seem like the
bottleneck for WXAgg.  Partly because of that, I'm assuming that
the WXAgg will be good enough for my needs (as opposed to
completely rewriting backend_wx) and that getting to GTKAgg level
of performance would be the goal.  I also agree that the best
solution is likely to mean converting the Agg image (pixBuffer??)
into the wx.bitmap in c++.  I'm not sure I have a firm grasp on
how exactly to do that, but it's worth trying.

--Matt

Re: [Matplotlib-users] dynamic plots

[John H. <jdh...@ac...>]

>>>>> "imaginee1" == imaginee1  <ima...@gm...> writes:

    imaginee1> Hi, after spending a nice afternoon profiling the
    imaginee1> dynamic examples and looking a bit through the code, we
    imaginee1> can make a few comments on the performace of the wx
    imaginee1> backends.  We have used kcachegrind to display the
    imaginee1> results of hotshot - all files can be found under
    imaginee1> http://www.physik.tu-dresden.de/~baecker/tmp/profiling/

Hi Arnd, thanks for your profiling information - I very much like the
hotshot graphs!

I just have two comments.  

All of your suggestions are imminently reasonable.  The major problem
is that the wx backend has been mostly rudderless since Jeremy, the
author, stopped maintaining it, though I've filled in when I can.
Matthew Newville has recently signed on as the new maintainer and has
CVS commit privileges, but I don't know how much time he has to
address these issues right now.  I don't have any extra time to devote
to wx optimizations, currently.  If you would like to do some work
here, I would be happy to add you to the developers list.

The second point is that in your previous email you appeared to
indicate that GTK wasn't a good option for you because many of your
students use win32.  I use the gtk backend on win32 - you have to run
the GTK runtime installer and the pygtk installer, but it otherwise
works great, and the matplotlib gtk extension code is compiled into
the matplotlib win32 installer.  There are install instructions for
win32 at http://matplotlib.sourceforge.net/backends.html#GTK .

JDH

Re: [Matplotlib-users] clearing subplots

[John H. <jdh...@ac...>]

>>>>> "Michel" == Michel Sanner <sa...@sc...> writes:

    Michel> Hello, I finally got around to play with matplotlib and
    Michel> try to create node for using it within Vision (my visual
    Michel> programming environemnt).

Hi Michel,

It's excellent to hear that you are trying to incorporate matplotlib!
Only good things can come of stress testing matplotlib in such a
sophisticated environment.

    Michel> I was wondering if there is a way the clear the area used
    Michel> by a given subplot.  cla() seesm the clear the data, but
    Michel> the axis and background remain.  The reason I am asking is
    Michel> that I envisioned that in my networks I would like to be
    Michel> able to create a Figure using one node and then have say a
    Michel> Histogram node be placed in a subplot and a scatter plot
    Michel> in another subplot (in the same figure).  Now if the
    Michel> Histogram node has a subplot parameter which can be
    Michel> modified by the user to move this particular graph to
    Michel> another location in the picture I need to get ride of what
    Michel> I drew in the previous location, but since parts of the
    Michel> figure might be generated by other nodes in the network I
    Michel> would not want to clear the whole figure.

I see what you are trying to do and there is no support in the current
release for this.  However, it will be mostly trivial to add, and
definitely useful, so I can quickly put it in for the next release.

Before doing so, it would help for me to know if you are using the OO
interface (eg examples/embedding_in_tk.py) or the pylab (formerly
matplotlib.matlab).  The latter does a fair amount of magic under the
scenes managing the current figure and axes and so is not the best for
embedding in an application.  It thus requires more work to delete an
axes, since there is a separate figure/axes management layer.

Do you envision providing a scripting interface to your Vision users,
in which case the pylab interface probably makes sense, or will you
ultimately be maintaining control over the creation of figure windows
and axes and providing a GUI layer to your users, in which case the OO
embedded approach makes sense.

Note that if all you want to do is move the subplot in a figure, all
you need to do is call

  ax = subplot(211)
  ax.set_position((left,bottom,width,height))

where l,b,w,h are fractions of the figure width and height.  If you
want to drag and drop axes from one figure to another, which is
reasonable, then additional work will need to be done to remove the
axes from one and add to another.  Sharing a subplot in two figures
will probably remain unsupported, but with a little work you could
move one from one figure to another.  Note that
matplotlib.axes.Subplot is a special case of matplotlib.axes.Axes, and
each are placed with l,b,w,h.  The difference is that subplot does the
l,b,w,h computation for you -- see examples/axes_demo.py.

On an related note, the ticklabels in your screenshot appeared a
little crowded.  You may want to take a look at
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP .

    Michel> Another question was whether it is possible to find out
    Michel> the figure number from the figure handle ?  If I pass the
    Michel> Figure instance between nodes to tell drawing node in
    Michel> which figure to place their graphical output I need a way
    Michel> to active the figure that comes as an input.  Currently I
    Michel> add a number attribute to the figure when I create it in
    Michel> the figure node.

The Figure class doesn't have a concept of number, but the
FigureManager does.  In the pylab interface, calls to make a new
figure create a new FigureManager (abstract class in
backend_bases.FigureManager, concrete classes in the various
matplotlib/backends/backend_something.py).  The figure manager has a
few public attributes you can access

    manager = get_current_fig_manager()
    manager.num    # what you are after
    manager.canvas # a backend_bases.FigureCanvasBase concrete impl
    manager.window # the GUI window, eg tk.Window

As I alluded to above though, depending on your ultimate goals, once
you get past the playing stage you *may* want to forgo the pylab
interface (which the figure manager is designed for) in exchange for
the control of the OO interface.  Note that a new
examples/embedding_in_tk2.py was recently added to CVS which shows how
to use tk matplotlib with the default toolbar in a tk app.

There is an unreleased users guide in progress, and it has some more
details and schematics on how matplotlib is organized.

  http://cvs.sourceforge.net/viewcvs.py/*checkout*/matplotlib/users_guide/users_guide.pdf?rev=1.3

    Michel> Thanks for any input .. and congratualtion on the very
    Michel> nice package !

High praise coming from you!  Thanks.

JDH

[Matplotlib-users] clearing subplots

[Michel S. <sa...@sc...>]

Hello,

I finally got around to play with matplotlib and try to create node for 
using it within Vision (my visual programming environemnt).

I was wondering if there is a way the clear the area used by a given 
subplot.  cla() seesm the clear the data, but the axis and background 
remain.  The reason I am asking is that I envisioned that in my networks 
I would like to be able to create a Figure using one node and then have 
say a Histogram node be placed in a subplot and a scatter plot in 
another subplot (in the same figure).  Now if the Histogram node has a 
subplot parameter which can be modified by the user to move this 
particular graph to another location in the picture I need to get ride 
of what I drew in the previous location, but since parts of the figure 
might be generated by other nodes in the network I would not want to 
clear the whole figure.

Another question was whether it is possible to find out the figure 
number from the figure handle ?  If I pass the Figure instance between 
nodes to tell drawing node in which figure to place their graphical 
output I need a way to active the figure that comes as an input.  
Currently I add a number attribute to the figure when I create it in the 
figure node.

Thanks for any input .. and congratualtion on the very nice package !

-- 

-----------------------------------------------------------------------
   o
  /    Michel F. Sanner Ph.D.            The Scripps Research Institute
o      Associate Professor               Department of Molecular Biology
  \                                      10550 North Torrey Pines Road
   o   Tel. (858) 784-2341               La Jolla, CA 92037
  /    Fax. (858) 784-2860
o     sa...@sc...                 http://www.scripps.edu/~sanner
-----------------------------------------------------------------------

Re: [Matplotlib-users] Is really matplotlib this slooow for displaying images ? (sorry again)

[John H. <jdh...@ac...>]

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

    John> I made some small changes which helped here - eg, deferring
    John> the initialization of the LUTs until they are actually
    John> requested.  This shaved 0.3 s off startup time on my system.
    John> With Todd's help, I also made some changes in the core
    John> "fromarray" in extension code which delivered some speedups,
    John> and removed some extra checks in the colormapping code which
    John> are not needed for data that are properly normalized.  I
    John> also think I found and fixed redundant calls to draw in some
    John> backends due to improper event handling and hold handling
    John> that crept into 0.65.

Well, Xavier Gnata just pointed out to me off list that almost half
the cost of the default image handling was in the normalization calls
to min and max.  After a little poking around, I discovered we were
using python's min and max here, which means sequence API.  Ouch!

So we get another 2x speedup on top of the numbers I just posted using
default normalization and colormapping.

# GTKAgg default normalization and colormapping

   # 0.65
   matplotlib 0.65 figimage : 9.97s    
   matplotlib 0.65 imshow   : 9.91s    

   # optimization numbers in my last post
   matplotlib figimage  : 5.23s    
   matplotlib imshow    : 5.18s    

   # as above but using nxmin and nxmax
   matplotlib figimage  : 2.21s    
   matplotlib imshow    : 2.24s    

So out of the box the next matplotlib will be more than 4x faster than
the last release for images.  A long way from MIDAS and IRAF, but
still satisfying for a day's work.

JDH

Re: [Matplotlib-users] Is really matplotlib this slooow for displaying images ? (sorry again)

[Perry G. <pe...@st...>]

On Dec 21, 2004, at 1:02 PM, Xavier Gnata wrote:

>
> Hi,
>
> Please consider this code in colors.py  (from 546) :
>    if vmin is None or vmax is None:
>           rval = ravel(val)
>           if vmin is None:
>               vmin = min(rval)
>           if vmax is None:
>               vmax = max(rval)
>
> On my computer  to be much faster without using rval :
>
>       if vmin is None or vmax is None:
>           #rval = ravel(val)
>           if vmin is None:
>               vmin = val.min()
>           if vmax is None:
>               vmax = val.max()
>
But note that .min and .max are only supported under numarray (I 
believe). There are a number of things we would like to take advantage 
of (especially with regard to array indexing) that we can't in 
matplotlib since the code must work with both Numeric and numarray.

Perry

Re: [Matplotlib-users] Is really matplotlib this slooow for displaying images ? (sorry again)

[John H. <jdh...@ac...>]

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
  
    Perry> As John later alluded to, the time for the window to come
    Perry> up is a one time cost if you are running from an
    Perry> interactive prompt. It shouldn't be paid for subsequent
    Perry> display updates.

I made some small changes which helped here - eg, deferring the
initialization of the LUTs until they are actually requested.  This
shaved 0.3 s off startup time on my system.  With Todd's help, I also
made some changes in the core "fromarray" in extension code which
delivered some speedups, and removed some extra checks in the
colormapping code which are not needed for data that are properly
normalized.  I also think I found and fixed redundant calls to draw in
some backends due to improper event handling and hold handling that
crept into 0.65.

Here are my current numbers for a 1600x1600 image

# GTKAgg default normalization and colormapping
   matplotlib 0.65 figimage : 9.97s    
   matplotlib 0.65 imshow   : 9.91s    
   matplotlib CVS figimage  : 5.23s    
   matplotlib CVS imshow    : 5.18s    

# GTKAgg prenormalized data and default ("hot") colormapping
   matplotlib 0.65 figimage : 3.46s  
   matplotlib 0.65 imshow   : 3.37s
   matplotlib CVS figimage  : 1.95s
   matplotlib CVS imshow    : 2.01s

# GTKAgg prenormalized data and custom grayscale colormapping
   matplotlib 0.65 figimage : 2.05s    
   matplotlib 0.65 imshow   : 1.95s    
   matplotlib CVS figimage  : 1.15s
   matplotlib CVS imshow    : 1.21s

So the situation is improving.  As I noted before, interaction with
plots via the toolbar should also be notably faster.

This would make a good FAQ....

JDH

Re: [Matplotlib-users] Is really matplotlib this slooow for displaying images ? (sorry again)

[Xavier G. <gn...@ob...>]

Hi,

Please consider this code in colors.py  (from 546) :
 
    if vmin is None or vmax is None:
           rval = ravel(val)
           if vmin is None:
               vmin = min(rval)
           if vmax is None:
               vmax = max(rval)

On my computer  to be much faster without using rval :

       if vmin is None or vmax is None:
           #rval = ravel(val)
           if vmin is None:
               vmin = val.min()
           if vmax is None:
               vmax = val.max()

I am now able to do a "A=rand(2000,2000) figimage(A)" in a almost 
acceptable duration.

Hope this helps

Xavier.
ps : may be in double. sorry.