matplotlib-devel Mailing List for matplotlib

Yeah, now I remember installing those fonts a while ago so I could put
symbols in my diagrams in inkscape...

For embedding, we need SVG fonts.  Would it be kosher to just use this:

http://xml.apache.org/batik/ttf2svg.html

or its equivalent to convert the BaKoMa fonts to SVG, and then include
the resulting SVG fonts in the matplotlib package?

Jared

> Hmm, this is strange and intriguing.  I notice that you do not embed
> the fonts in your svg document, which is presumably why most viewers
> can't handle it.  I confirmed that librsvg, which gqview uses, can't
> render the fonts either.  The question is, why can Inkscape do it?  I
> downloaded Inkscape and did a recursive grep through their src as well
> as a find in the root of their src tree and found no references to
> 'computer modern' or cmex, etc....  Did you have to set some path in
> inkscape to see your cm fonts, or did you put them in some standard
> place?  Anyone have any ideas how inkscape manages to pull off this
> trick?

>     Jared> John, are there any more features still missing from the
>     Jared> SVG backend?
> 
> That almost does it.  I think we need an option to embed the fonts
> directly into the svg document like we do for PS, because I think
> viewers that have the cm* fonts built in will be the exception rather
> than the rule.  Fernando Perez has some colleagues who are interested
> in embedding clickable tags in svg, but I haven't heard much from
> them.
> 
> But overall SVG is in fine shape.

>>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:

    Jared> Hello, The attached patches implement mathtext for SVG. The
    Jared> output looks pretty good when viewed by Inkscape, but not
    Jared> the Adobe SVG viewer (it shows the wrong symbols and then
    Jared> moments later crashes Mozilla, at least on my system).  It
    Jared> hasn't been thoroughly tested for all of the possible
    Jared> symbols.

Hmm, this is strange and intriguing.  I notice that you do not embed
the fonts in your svg document, which is presumably why most viewers
can't handle it.  I confirmed that librsvg, which gqview uses, can't
render the fonts either.  The question is, why can Inkscape do it?  I
downloaded Inkscape and did a recursive grep through their src as well
as a find in the root of their src tree and found no references to
'computer modern' or cmex, etc....  Did you have to set some path in
inkscape to see your cm fonts, or did you put them in some standard
place?  Anyone have any ideas how inkscape manages to pull off this
trick?

    Jared> I had to add a math_parse_s_ft2font_svg() to mathtext.py,
    Jared> which basically does the same thing as
    Jared> math_parse_s_ft2font() but returns something different.  I
    Jared> tried to just modify the latter function to take a
    Jared> "usingSVG=True" argument and ran into all sorts of bizarre
    Jared> problems, probably associated with the caching, and gave
    Jared> up.  Perhaps someone can figure out how to do this more
    Jared> elegantly.

Probably the best way to do this is to subclass BakomaTrueTypeFonts
and override the just methods you need.

    Jared> John, are there any more features still missing from the
    Jared> SVG backend?

That almost does it.  I think we need an option to embed the fonts
directly into the svg document like we do for PS, because I think
viewers that have the cm* fonts built in will be the exception rather
than the rule.  Fernando Perez has some colleagues who are interested
in embedding clickable tags in svg, but I haven't heard much from
them.

But overall SVG is in fine shape.

Many thanks!
JDH

Hello,

The attached patches implement mathtext for SVG. The output looks pretty
good when viewed by Inkscape, but not the Adobe SVG viewer (it shows the
wrong symbols and then moments later crashes Mozilla, at least on my
system).  It hasn't been thoroughly tested for all of the possible
symbols.

I had to add a math_parse_s_ft2font_svg() to mathtext.py, which
basically does the same thing as math_parse_s_ft2font() but returns
something different.  I tried to just modify the latter function to take
a "usingSVG=True" argument and ran into all sorts of bizarre problems,
probably associated with the caching, and gave up.  Perhaps someone can
figure out how to do this more elegantly.

John, are there any more features still missing from the SVG backend?

Cheers,

Jared

My system is set up so that when I am logged into root (via su) the root user 
cannot access the X display. I like this behavior but it means that I cannot 
install matplotlib as the root user (I can use sudo) because setup.py wants 
to import pygtk and wxPython both of which try to connect to the X display.

It seems to me that it is unnecessary to connect to the display to compile the 
matplotlib extensions, rather the import gtk command exists to test to see if 
the pygtk package is installed. If I am wrong then this does not matter. I 
thought that the build procedure would be more robust is it was not necessary 
to import the whole pygtk and wxPython packages in order to test for their 
presence. Is there a standard way to test for the presence of a package 
without actually importing it? I know that I could temporarily export a 
display for the root user - but I don't want to and I don't think it should 
be necessary if it is not required.

I have been thinking about ways to test for packages without importing them. 
Would it be possible to test for the offending packges by importing 
subpackages that do not connect to the X server? For example in the case of 
pygtk 'gobject' can be imported successfully when no X display is available. 
(This works on my system because pygtk-2.0 is part of the python path - I did 
not put it there so I assume that is standard - if not this procedure would 
require that the appropriate directory was appended to then removed from the 
python path.)

The disadvantages that I can see are that it would make the build procedure 
dependant on the naming of subpackages within a package and it would not 
actually check for a working installation just the presence of a certain 
package. I guess it depends how great the demand is to be able to install 
matplotlib from an environment that does not have a X display.

Cheers
Chris

Dear Mr. Horton:

I am investigating options for creating 2D contour plots for the freely
distributable Matplotlib package (http://matplotlib.sourceforge.net/).
The Matplotlib license requires all the software to be free for
noncommercial and commercial distribution.

I had the idea to try to implement marching squares for this package.  We
know the marching cubes algorithm is patented, but what about the 2D
marching squares?  Can my implementation be used in this freely
distributed package without obtaining a license grant?

Thanks,
Curtis

      * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    *   Curtis S. Cooper, Graduate Research Assistant         *
   *    Lunar and Planetary Laboratory, University of Arizona  *
   *    http://www.lpl.arizona.edu/~curtis/		       *
   *    Kuiper Space Sciences, Rm. 318                         *
    *   1629 E. University Blvd.,                             *
     *  Tucson, AZ 85721        * * * * * * * * * * * * * * *
      * Wk: (520) 621-1471     *
       * * * * * * * * * * * *

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

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

2 ways:

1) automatically: define a coarser(user defined coarseness) mesh on
   the function to be labelled, and add the labels in the vertices of
   this mesh. the angle of each label can easily be found from the
   closest contour line segment. this method avoids clusters of labels
   effectively, but will not be good in areas with high variability.

2) manually: let the user point and click on contours, I implemented
   this for use with gist that you could take a look at (clabel below).
   matlab also does this, and I think this is the best way for real
   publication quality. I have never seen automatic routines that do
   labelling well. TECPLOT is close but not quite there.

   I also attached a routine to do this for 2D stretched coordinates (see
   the contour plots with labels on
      http://www.ii.uib.no/~avle/python.html 
   for examples) which is called vclabel

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

sure, no problem.

Helge




def clabel(z,clevels,opa=1,col='black',meth='std',digits=1):
    """
    clabel(z,clevels,opa=1,col='black')
    
    At the point where the mouse is clicked, print the contour level
    from clevels that are closest to the interpolated value in this
    point. Meant to be useful for labeling contour lines manually...
    
    optional arguments:
    opa=0 : Transparent text.
    opa=1 : Erase background under label
    col='white'  : text color.
    meth= 'std'   bilinear interpo on a std grid, might give error near coast
          'grid'  values not given cellcentered but on corners of cells. 
          'bigrid' values taken from a bilinearly interpol fine mesh from
	  futil.contour
          'cell'  takes value from cell directly

    Helge Avlesen <av...@ii...>
    
    """
    
    print """
    Insert contour levels by left clicking, middle button display
    values, right button finishes.
    """
    
    button=0
    while button<>3:    
        mus=gist.mouse()                   
        button=mus[9]

	if meth=='bigrid':
	    i=int(2*mus[0])+1 ; j=int(2*mus[1])+1
	    x=2*mus[0]-i+1     ;  y=2*mus[1]-j+1
	elif meth=='std':
	    i=int( mus[0] );  j=int( mus[1] )
	    x=mus[0]-i     ;  y=mus[1]-j
	elif meth=='grid':	    
	    xm=mus[0]+0.5 ; ym=mus[1]+0.5
	    i=int( xm );  j=int( ym )
	    x=xm-i     ;  y=ym-j
        elif meth=='cell':
            print mus[0], mus[1]
            i=int(round(mus[0])) ; j=int(round(mus[1]))

        if meth=='cell':
            val=z[i,j]
            print val,i,j
        else:
            # bilinear interpolation to find value        
            a00=z[i,j] 
            a10=z[i+1,j]-a00 
            a01=z[i,j+1]-a00 
            a11=z[i+1,j+1]-(a00+a10+a01) 
            val=a00 + a10*x + a01*y + a11*x*y
            print val,i,j,x,y            

        if button==1:                    
            # compare this value to the selected levels
            diff= abs( clevels-val )  

            # use the closest
            label=fpformat.fix( clevels[  Numeric.argmin(diff) ], digits )

            gist.plt(label, mus[0], mus[1], opaque=opa, tosys=1, \
                     height=8, justify="CH", color=col )



def vclabel(z,sx,sy,clevels,opa=1,col='black',digits=1):
    """
    manual(z,clevels,opa=1,col='black')
    
    At the point where the mouse is clicked, print the contour level
    from clevels that are closest to the interpolated value in this
    point. Meant to be useful for labeling contour lines manually...

    sx[i,j],sy[i,j] is the x,z coordinate of point z[i,j]. if [:,1]
    denotes the top layer, [:,kb-1] the bottom (common in
    oceanography) j_is_down will be true. (z is always positive in
    the upward direction, but the indice j may go downwards)
    
    optional arguments:
    opa=0 : Transparent text.
    opa=1 : Use background color for text.
    col='white'  : text color.
    digits: number of decimals in label

    Helge Avlesen <av...@ii...>
    
    """
    
    print """
    Insert contour levels by left clicking, middle button display
    depth, right button finishes.
    """
    kb=z.shape[1]
    im=z.shape[0]

    j_is_down=0    
    if sy[0,0]>sy[0,1]:
        j_is_down=1
    
    button=0
    while button<>3:
        mus=gist.mouse()
        button=mus[9]
       
	# bisection search for the indices
        i=hbisect( sx[:,0], mus[0] )
        if i<0 or i>im-1:
            print 'outside:',i
            continue
        
        x=(mus[0]-sx[i,0])/(sx[i+1,0]-sx[i,0])
        
        if j_is_down:
            finn=hbisect( (1.-x)*sy[i,::-1] + x*sy[i+1,::-1] , mus[1] )
            j=kb-2-finn
            if finn<0 or finn>kb-1:
                print 'outside',i,finn
                continue
       
            xa=Numeric.array((sx[i,j+1]+x*(sx[i+1,j+1]-sx[i,j+1]),\
                              sy[i,j+1]+x*(sy[i+1,j+1]-sy[i,j+1])))
            
            if mus[1]-xa[1]<0:
                print 'below'
                continue
            
            xb=Numeric.array((sx[i,j]+x*(sx[i+1,j]-sx[i,j]),\
                              sy[i,j]+x*(sy[i+1,j]-sy[i,j])))
        
            y=(((mus[0]-xa[0])**2 + (mus[1]-xa[1])**2 )\
               /((xb[0]-xa[0])**2 + (xb[1]-xa[1])**2 ))**0.5
                
            # bilinear interpolation to find value
        
            a1=z[i,j+1] 
            a2=z[i+1,j+1]-a1 
            a3=z[i,j]-a1	
            a4=z[i+1,j]-(a1+a2+a3) 
            val=a1 + a2*x + a3*y + a4*x*y
        else:
            print 'increasing j upwards not yet implemented'
            continue
            
        print 'x,y=',x,y,' i,j=',i,j, 'val=',val

        if button==1:                    
            # compare this value to the selected levels
            diff= abs( clevels-val )  

            # use the closest
            label=fpformat.fix( clevels[  Numeric.argmin(diff) ], 1)

            if opa==1:
                label=' '+label+' '

            gist.plt(label, mus[0], mus[1], opaque=opa, tosys=1, \
                     height=8, justify="CH", color=col )

John Hunter schrieb:
>>>>>>"Fernando" =3D=3D Fernando Perez <Fer...@co...> writ=
es:
>=20
>=20
>     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.
>=20
> It's looks like about 90% of your problems result from trying to cross
> GUI backends within IPython.  Is this fair to say?

Well, not quite.  As I mentioned, I put in a matplotlib.use() wrapper whi=
ch=20
traps invalid switches, so it's not a problem if a use() call is made.  C=
ould=20
you add such a call to this one please? :

// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for o=
ther
backends.
run dynamic_image_gtkagg.py


It's only when native GUI examples are run that things crash badly.  Note=
 that=20
some of the segfaults occur from plain python:

// these are OK with gtkagg, but they segfault wxagg.  The segfault happe=
ns
from a normal command line as well (no ipython).

run system_monitor.py
run dynamic_demo.py

And I also have these:
// these two run but segfault on exit under ipython.  They run OK from a =
cmd line.
run dynamic_demo_wx.py
run dynamic_image_wxagg.py

I suspect these two are messing something up badly enough that if python =
quits=20
right away, you don't see the problem, but since ipython continues to run=
 the=20
interpreter, the problem appears.  Since these are segfaults, I'm very mu=
ch=20
willing to blame the wx code in there, and not ipython (which is 100% pur=
e,=20
unpolluted python :)

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

Yes, this is the real nasty.  If you think that the ipython+matplotlib=20
combination is going to be a common one in the future for scientists, it =
may=20
be worth protecting the examples against disaster (given they tend to be =
what=20
people run to first).  If you are willing to pay the price of 12 lines of=
 code=20
per example, you could put this snippet at the beginning of _every_ embed=
ded=20
example:

# Detect if we are inside IPython and bail if so.  Threading problems
# make it very difficult to safely run full GTK/WX apps inside IPython.
try:
     __IPYTHON__
     msg =3D ("This script can NOT be run inside IPython.\n\n"
            "It embeds matplotlib into a complete GUI application, and\n"
            "for a number of reasons this is (and probably will remain)\n=
"
            "unsupported from inside IPython.\n\n"
            "You can run it from the command line as a regular python scr=
ipt.\n")
     raise RuntimeError,msg
except NameError:
     pass

This will make sure that users get a meaningful error message inside ipyt=
hon=20
instead of a bizarre lockup or segfault.


> I'll comment on some of the non cross-GUI problems below....
>=20
>     Fernando> // These don't run with LANG=3D=3Dde_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
>=20
> Do they run from the shell with LANG=3D=3Dde_DE.UTF-8?  Any idea what i=
s
> going wrong?

Yes, the problem has nothing to do with ipython, it also happens with pla=
in=20
python.  Note that the broken ones are:

// These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK with en_US.UTF-=
8
run date_demo1.py
run date_demo2.py
run finance_demo.py

I think my original list had more by mistake.  Here's a traceback (form=20
ipython, so you get better details):

In [5]: run date_demo1.py
-------------------------------------------------------------------------=
--
ValueError                                Traceback (most recent call las=
t)

/home/fperez/code/python/pylab/examples/date_demo1.py
      26 yearsFmt =3D DateFormatter('%Y')
      27
---> 28 quotes =3D quotes_historical_yahoo(
      29     'INTC', date1, date2)
      30 if not quotes:

/usr/local/lib/python2.3/site-packages/matplotlib/finance.py in=20
quotes_historical_yahoo(ticker, date1, date2)
      61         if len(vals)!=3D7: continue
      62         datestr =3D vals[0]
---> 63         dt =3D datetime.date(*time.strptime(datestr, '%d-%b-%y')[=
:3])
      64         d =3D date2num(dt)
      65         open, high, low, close =3D  [float(val) for val in vals[=
1:5]]

/usr/src/build/394694-i386/install/usr/lib/python2.3/_strptime.py in=20
strptime(data_string, format)
     422     found =3D format_regex.match(data_string)
     423     if not found:
--> 424         raise ValueError("time data did not match format:  data=3D=
%s=20
fmt=3D%s" %
     425                          (data_string, format))
     426     if len(data_string) !=3D found.end():

ValueError: time data did not match format:  data=3D31-Mar-04  fmt=3D%d-%=
b-%y
WARNING: Failure executing file: <date_demo1.py>

The problem is that under different locales, dates come out formatted=20
differently.  You seem to have hardcoded format expectations which break =
in=20
the face of non-US locales.

>     Fernando> run print_stdout.py
>=20
> 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

Well, running it again I'm getting this:

Exception in thread Thread-1:
Traceback (most recent call last):
   File "/usr/src/build/394694-i386/install/usr/lib/python2.3/threading.p=
y",=20
line 436, in __bootstrap
     self.run()
   File "/home/fperez/code/python/IPython/Shell.py", line 527, in run
     self.IP.mainloop()
   File "/home/fperez/code/python/IPython/iplib.py", line 948, in mainloo=
p
     self.interact(banner)
   File "/home/fperez/code/python/IPython/iplib.py", line 1036, in intera=
ct
     line =3D self.raw_input(prompt)
   File "/home/fperez/code/python/IPython/iplib.py", line 1263, in raw_in=
put
     return self.prefilter(raw_input(prompt),
IOError: [Errno 9] Ung=FCltiger Dateideskriptor

Pehaps you could add (if you decide that you like that idea) the __IPYTHO=
N__=20
trap code to this as well, so that all examples are made ipython-friendly=
.  In=20
this one, the message could additionally show this:

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

so users know what to do straight away.

> Thanks for the detailed notes.

No prob.  I'm a big believer that good examples are what helps most new u=
sers,=20
so I'm trying to make sure that out-of-the-box, things run as smoothly as=
=20
possible for all those scientists who are just dying to start using matpl=
otlib=20
  with ipython :)

Best,

f

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    >> 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.
    >> 
    Perry> Thanks, that would be helpful. In my search I didn't come
    Perry> across many.  Keep in mind the license needs to be
    Perry> compatible with that of matplotlib.

Of course, in addition to the license, there is the patent issue.  I
believe marching squares is patented.  I know marching cubes is.

  http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4,710,876.WKU.&OS=PN/4,710,876&RS=PN/4,710,876

I checked the header of vtkMarchingSquares.cxx which states

  Program:   Visualization Toolkit
  Module:    $RCSfile: vtkMarchingSquares.cxx,v $
 
  Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
  All rights reserved.
  See Copyright.txt or http://www.kitware.com/Copyright.htm for details.
 
 
     THIS CLASS IS PATENTED UNDER UNITED STATES PATENT NUMBER 4,710,876
     "System and Method for the Display of Surface Structures Contained
     Within the Interior Region of a Solid Body".
     Application of this software for commercial purposes requires
     a license grant from GE. Contact:

but the patent number they reference which is linked above begins with

  A method and apparatus for displaying *three dimensional surface
  images* includes the utilization of a case table for rapid retrieval
  of surface approximation information.

emphasis mine.  So I don't know for sure what the patent status of the
2D algorithm is.

JDH

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