matplotlib-devel Mailing List for matplotlib (Page 4)

>>>>> "Helge" == Helge Avlesen <av...@ii...> writes:

    Helge> http://www.ii.uib.no/~avle/mpl/c1.png

    Helge> the first points of the segments are given by the vectors
    Helge> (x1,y1) the second (x2,y2). you can get pretty lines in
    Helge> matplotlib as well, but only by using the scattered line
    Helge> drawing methods of gtk. (something like
    Helge> self.area.window.draw_segments(self.gc, zip( x1,y1,x2,y2)?)

OK, I see.  I didn't fully understand that x1,x2,y1,y2 were the verts
of unordered line segments.  Then one can easily use a LineCollection
to draw these efficiently in matplotlib - script below and screenshot
http://nitace.bsd.uchicago.edu:8080/files/share/kontour.png.  Jeez, I
feel bad for sitting on this since February!

    Helge> if you want do do it "right" in matplotlib, you should
    Helge> implement a contour following algorithm (in C) - with this
    Helge> I mean an routine that returns the linesegments defining
    Helge> each countour in bundles. the current alg. is sort of
    Helge> marching cubes in 2D, a simplified version of CONREC
    Helge> http://astronomy.swin.edu.au/~pbourke/projection/conrec/
    Helge> but only using 2 triangles per square.

Do you have any thoughts on how we might do labels with your code?

    Helge> doing contour following alg. it is also much easier to
    Helge> implement automatic contour labelling. I suspect python
    Helge> loops are too slow for such algorithms - it may perhaps be
    Helge> possible to do them in Numeric, but it will still be much
    Helge> slower than my simple library. I think you may use the
    Helge> GPL'ed PLPLOT (C) for an example of contour following alg.

We have a problem in that we cannot use GPL'd code in matplotlib
because the GPL does not allow redistribution of closed code, which
the matplotlib (and python license) do.

If we decide to go with your routines, at least for the time being
until we can "do it right", would you be willing to contribute your
code to matplotlib under the matplotlib license (PSF inspired, free
for commercial and noncommercial reuse)?

Thanks!
JDH

from matplotlib.matlab import *
from matplotlib.collections import LineCollection
import hutil

delta = 0.05
x = y = arange(-3.0, 3.0, delta)
X, Y = meshgrid(x, y)
Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
Z = Z2-Z1

print Z.shape
fsm = ones(Z.shape, Z.typecode())


zmax, zmin = hutil.maxmin(Z)
depths=linspace(zmin, zmax, 10)

x1,y1,x2,y2 = hutil.contour2(Z, fsm, depths )

imshow(Z, origin='lower', interpolation='nearest')

segments = [ ( (thisy1, thisx1), (thisy2, thisx2) ) 
             for thisx1, thisy1, thisx2, thisy2 in zip( x1,y1,x2,y2)]

coll = LineCollection(segments)
gca().add_collection(coll)
savefig('kontour')

show()

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

| I was concerned by the fact that the lines were not smooth - if you
| plot a connected line they line jumps from side to side.  But it
| does get the contour right, and is implemented in pure numeric, and
| so it occurs to me that it might be easier to fix this problem than
| start from scratch.  Perhaps Helge or one of you has some insight
| into how to fix this.
| 
| I'm attaching a modified version of the tarfile Helge initially sent
| me.  I've included a script testkont_mpl.py that calls Helge's lib.
| Change the '.' linestyle to '-' to see the problem I discussed.

Hi,
not sure if I have matplotlib 100% correctly installed, but this is
what I see using your example script:

http://www.ii.uib.no/~avle/mpl/c0.png

(and with the current algorithm, more or less what I would expect...)
to get straight lines you must plot segments one by one since they are
not ordered. if I use gist for this(see the script at the end) I get

http://www.ii.uib.no/~avle/mpl/c1.png

the first points of the segments are given by the vectors (x1,y1) the
second (x2,y2). you can get pretty lines in matplotlib as well, but
only by using the scattered line drawing methods of gtk. (something
like self.area.window.draw_segments(self.gc, zip( x1,y1,x2,y2)?)

if you want do do it "right" in matplotlib, you should implement a
contour following algorithm (in C) - with this I mean an routine that
returns the linesegments defining each countour in bundles. the
current alg. is sort of marching cubes in 2D, a simplified version of
CONREC 
http://astronomy.swin.edu.au/~pbourke/projection/conrec/
but only using 2 triangles per square. 

doing contour following alg. it is also much easier to implement
automatic contour labelling. I suspect python loops are too slow for
such algorithms - it may perhaps be possible to do them in Numeric,
but it will still be much slower than my simple library. I think you
may use the GPL'ed PLPLOT (C) for an example of contour following alg.

Helge





from matplotlib.matlab import *
import hutil

delta = 0.05
x = y = arange(-3.0, 3.0, delta)
X, Y = meshgrid(x, y)
Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
Z = Z2-Z1

print Z.shape
#fsm = ones(Z.shape, Z.typecode())
fsm = ones(Z.shape, 'l')

zmax, zmin = hutil.maxmin(Z)
depths=linspace(zmin, zmax, 10)

x1,y1,x2,y2 = hutil.contour2(Z, fsm, depths )

#imshow(Z, origin='lower', interpolation='nearest')
#plot(y2,x2,'-')
#show()

import gist
gist.pldefault(dpi=100,style='framed.gs')
gist.palette('rainbow.gp')
gist.pli(transpose(Z))
gist.pldj(x1,y1,x2,y2)   # draw disjoint segments

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> I think we're doing pretty good, except that people can
    Fernando> always kill themselves by running true WX/GTK apps via
    Fernando> @run.  IPython is really not made for this, it can only
    Fernando> handle gracefully show() calls from pure matplotlib
    Fernando> scripts, not full-blown GUI apps.  But I think we have a
    Fernando> very reasonable environment at this point for most usage
    Fernando> cases.

It's looks like about 90% of your problems result from trying to cross
GUI backends within IPython.  Is this fair to say?

As far as I'm concerned I don't have a problem with these cases.
Caveat emptor -- the user should be forewarned and expect disaster if
they try and run GUI specific examples from ipython.  Perhaps you
should say pylab only supports pure matlab interface matplotlib at
this point.

From your end I see why it's a concern - you don't want any run
command to break or freeze ipython.  If you have any ideas on what we
should do I'll be happy to help on the matplotlib end, but I don't
have any off the top of my head.

I'll comment on some of the non cross-GUI problems below....

    Fernando> // These don't run with LANG==de_DE.UTF-8, but are OK
    Fernando> with en_US.UTF-8 run date_demo_convert.py run
    Fernando> date_demo1.py run date_demo2.py run date_demo_rrule.py
    Fernando> run finance_demo.py

Do they run from the shell with LANG==de_DE.UTF-8?  Any idea what is
going wrong?

    Fernando> run print_stdout.py

This is an example script to show how to print png to stdout from agg.
Perhaps this fails because ipython doesn't really expect a png coming
in from stdout?  The header of that file states

  # print png to standard out
  # usage: python print_stdout.py > somefile.png

    Fernando> ****run ftface_props.py
    ---> 71 font.jdh = 'hi'

I was testing to see if I could setattr on my extension class.  I'll
just remove this line from the example

    Fernando> ****run movie_demo.py: with WX backend it doesn't make
    Fernando> the .png frames at all with WXAgg, it runs fine but
    Fernando> fails to make the movie: ...  Saving frame _tmp049.png
    Fernando> Making movie animation.mpg - this make take a while sh:
    Fernando> line 1: mpeg2encode: command not found convert: Delegate
    Fernando> failed (mpeg2encode "%i" "%o").  convert: Delegate
    Fernando> failed (mpeg2encode "%i" "%o") [No such file or
    Fernando> directory].

    Fernando> Symlinking mpeg2encode to mpeg2enc (the real binary)
    Fernando> doesn't help, a different error comes back.

    Fernando> I got it to work by commenting out the convert call and
    Fernando> reverting to the mencoder one.  Great!

Yes, this fails on my system too.  This line works

  os.system("convert _tmp*.png animation.mpg")

but I wasn't able to get convert to make mpg.  I'll fixed this in the
examples dir and made the mencoder line the default.

    Fernando> ****run vertical_ticklabels.py

    Fernando> ---------------------------------------------------------------------------
    Fernando> NameError Traceback (most recent call last)

    Fernando> /home/fperez/code/python/pylab/examples/vertical_ticklabels.py
    Fernando> 3 4 plot([1,2,3,4], [1,4,9,16]) 5 xticks([1,2,3,4],
    Fernando> ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
    ----> 6 set(t, 'rotation', 'vertical')
    Fernando>        7 show()

    Fernando> NameError: name 't' is not defined WARNING: Failure
    Fernando> executing file: <vertical_ticklabels.py>

Fixed.  This also pointed me a bug in the new commands xticks and
yticks; they weren't returning the things they claimed in the doc
string.

Thanks for the detailed notes.

JDH

> Hi again,
>
> Yes, I had the thought that using C for the algorithm would be easier as
> well.  There are actually some very well-written marching squares
> contouring algorithms in C already out there.  I will try to find such an
> implementation and point you to it or send you the source code.
>
Thanks, that would be helpful. In my search I didn't come across many.
Keep in mind the license needs to be compatible with that of matplotlib.

> The second half is just the drawing, which should be implemented in
> matplotlib using the line collections class.  Since vector plotting is not

Yeah, that's what we have in mind.

> that hard, I will try to get that working first.  Then, someone can take
> my source code and adapt it easily to the contouring problem, once an
> effective and sufficiently high-performance algorithm implementation can
> be found.
>
> Cheers,
> Curtis
>
OK, Perry

> We are trying to adapt the C contour program that is used by gist
> (and can be found in the contour routine used by xplt in scipy).
> It would be best to look at the source for the precise description
> of the algorithm it uses (note though that gist apparently uses
> two different pieces of contour code for its contour tasks. The
> one we are looking to adapt, mainly because it appears much easier
> to isolate from the gist environment is the gcntr.c version).
> I would be amazed if one could find a pure Python algorithm to do
> contouring that was fast enough. Our current plan is to use these
> C routines to generate the contour segments, and do the plotting
> from within Python (as well as any contour labeling).
>
> If you have expertise in this area you may be able to do it better
> and faster than we can. Currently it is being worked on part time
> so we aren't able to do it as fast as we would like. I'm hoping that we
> will have at least a basic version (e.g., no labeling) in a couple
> weeks.
>
> If you want me to send or point you to the source code we are
> using as the basis, let me know.

Hi again,

Yes, I had the thought that using C for the algorithm would be easier as
well.  There are actually some very well-written marching squares
contouring algorithms in C already out there.  I will try to find such an
implementation and point you to it or send you the source code.

The second half is just the drawing, which should be implemented in
matplotlib using the line collections class.  Since vector plotting is not
that hard, I will try to get that working first.  Then, someone can take
my source code and adapt it easily to the contouring problem, once an
effective and sufficiently high-performance algorithm implementation can
be found.

Cheers,
Curtis

Curtis Cooper writes:

> My research is in computational fluid dynamics (specifically, the
> meteorologies of planetary atmospheres).  Working contour and vector plots
> in matplotlib would make it possible for me to make 2D meteorological maps
> of atmospheric layers, etc.
>
> I noticed for the first time in the goals page that contour plots are
> being worked on, apparently by STSci.  I have been considering
> implementing these two plot types as sets of line collections, but now
> that I know contour plots are being worked on, and vector plots are
> simpler to implement (in 2D), I will work on making vector plots.  The
> mathematics is fairly straightforward.  I just need to learn how to use
> the class library.
>
> About contour plots, however, I have a couple of questions.  How is it
> being implemented?  I was about to try to write a marching squares
> contouring routine, although it might have been painfully slow in Python.
> Does anyone have experience with this?
>
We are trying to adapt the C contour program that is used by gist
(and can be found in the contour routine used by xplt in scipy).
It would be best to look at the source for the precise description
of the algorithm it uses (note though that gist apparently uses
two different pieces of contour code for its contour tasks. The
one we are looking to adapt, mainly because it appears much easier
to isolate from the gist environment is the gcntr.c version).
I would be amazed if one could find a pure Python algorithm to do
contouring that was fast enough. Our current plan is to use these
C routines to generate the contour segments, and do the plotting
from within Python (as well as any contour labeling).

If you have expertise in this area you may be able to do it better
and faster than we can. Currently it is being worked on part time
so we aren't able to do it as fast as we would like. I'm hoping that we
will have at least a basic version (e.g., no labeling) in a couple
weeks.

If you want me to send or point you to the source code we are
using as the basis, let me know.

Perry Greenfield