matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> This looks incomplete, what's the Exception type?  I tried
    Steve> on my system and it ran OK.


Oops, the complete traceback is below.  Maybe my cairo is out of
whack. Are you using CVS?

I tried upgrading my cairo from CVS and got the build error indicated
below.  Any ideas?  I can post to the cairo mailing list....


    Steve> The Cairo colour problem has been noticed and discussed on
    Steve> the Cairo mailing list. The cairo.FORMAT_ARGB32 stores each
    Steve> 32-bit pixel in native-endian format so on big-endian
    Steve> systems it looks like ARGB and on little-endian systems
    Steve> (like my PC) it looks like BGRA, I'm not sure if Cairo will
    Steve> be updated to 'fix' this or not.  A possible workaround is
    Steve> to check sys.byteorder, and if its 'little' then get the
    Steve> image module / Agg to generate BGRA (I'm not sure if it can
    Steve> do this) and even then I think it must be BGRA with
    Steve> litte-endian ordering. Or a 'bit-flipping' routine could be
    Steve> written to do the same, but seems like a very inefficient
    Steve> thing to need to do.

    Steve> I guess a good test to start with would be to see if the
    Steve> colours are actually correct on a big-endian system. I
    Steve> understand the PowerPC is bi- endian - the OS imposes the
    Steve> endianness, and that with OS X it is big- endian. So
    Steve> perhaps someone with a Mac could test if the colours do
    Steve> currently work.

    Steve> Or we could simply use RGB32 where the byte order is
    Steve> correct, and do without the alpha.

I would vote for dealing with the endianess and different pixel
formats in a platform specific way.  The current pixel converters in
agg

    tostring_rgb
    tostring_argb
    tostring_bgra
    buffer_rgba

and I can provide whatever you need, or you can follow the existing
code and provide them yourself.  agg prettty much has a converter for
every format I've heard of.

JDH








### Cairo backend traceback
peds-pc311:~/python/projects/matplotlib/examples> python simple_plot.py -dCairo
Traceback (most recent call last):
  File "simple_plot.py", line 15, in ?
    savefig('simple_plot')
  File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig
    return fig.savefig(*args, **kwargs)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure
    orientation)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn
    if ext == 'png': _save_png (figure, fileObject)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png
    ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height)
TypeError: Context.set_target_png() argument 1 must be string, not file
peds-pc311:~/python/projects/matplotlib/examples>


### Cairo CVS build error
make[2]: Entering directory `/home/jdhunter/python/cvs/cairo/src'
if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include    -I/usr/local/include/libpng12      -I/usr/local/include   -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes  -Wmissing-prototypes -Wmissing-declarations     -Wnested-externs -fno-strict-aliasing    -g -O2 -MT cairo.lo -MD -MP -MF ".deps/cairo.Tpo" -c -o cairo.lo cairo.c; \
then mv -f ".deps/cairo.Tpo" ".deps/cairo.Plo"; else rm -f ".deps/cairo.Tpo"; exit 1; fi
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include -I/usr/local/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -g -O2 -MT cairo.lo -MD -MP -MF .deps/cairo.Tpo -c cairo.c  -fPIC -DPIC -o .libs/cairo.lo
In file included from cairo.h:48,
                 from cairoint.h:60,
                 from cairo.c:37:
cairo-features.h:42:9: macro names must be identifiers
cairo-features.h:48:9: macro names must be identifiers
cairo-features.h:52:9: macro names must be identifiers
cairo-features.h:56:9: macro names must be identifiers
cairo-features.h:58:9: macro names must be identifiers
cairo-features.h:60:9: macro names must be identifiers
make[2]: *** [cairo.lo] Error 1

peds-pc311:~/python/cvs/cairo> gcc --version
gcc (GCC) 3.3.3
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
peds-pc311:~/python/cvs/cairo> uname -a
Linux peds-pc311.bsd.uchicago.edu 2.4.21-15.0.2.ELsmp #1 SMP Wed Jun 16 22:52:07 EDT 2004 i686 i686 i386 GNU/Linux

>>>>> "Bryan" == Bryan Cole <bry...@te...> writes:

    Bryan> I've using Python-2.3.4 BTW. Maybe CXX didn't update to the
    Bryan> new python object model. I know nothing about CXX
    Bryan> internals, however.

I just upgraded mpl to the most recent CXX and I still get the
segfault.  What would be most useful is if you created a minimal CXX
extension independent of mpl and see if you can replicate the bug.  If
so, could you file a bug report on the CXX sf project page?

JDH

On Thu, 17 Mar 2005 13:10:24 +0000, Bryan Cole wrote:

> 
>>>> from matplotlib._transforms import *
>>>> from types import *
>>>> V=Value(0)
>>>> issubclass(type(V), TypeType)
> Segmentation fault
> 
> The 'issubclass' function is called by the default pickler. The seg-fault
> seems to occur for any of the matplotlib._transform CXX-types.

I see that

>>> type(V).__bases__
'*'

whereas every other object I have tried gives something like:

>>> type(None).__bases__
(<type 'object'>,)

I've tested this with a trivial external C-type (the 'noddy.c' example in
the python documentation chapter on Extending and Embedding) and even the
most basic python object has it's base class defined as <object> now.

I've using Python-2.3.4 BTW. Maybe CXX didn't update to the new python
object model. I know nothing about CXX internals, however.

I've been looking at how to pickle figures: it looks like is should be
a simple modification to make all _transform objects (Value,
Point, Bbox, Affine etc.) picklable. This should be possible without
modifying any cpp code.

I hit a problem though. The following code generates a seg-fault:

>>> from matplotlib._transforms import *
>>> from types import *
>>> V=Value(0)
>>> issubclass(type(V), TypeType)
Segmentation fault

The 'issubclass' function is called by the default pickler. The seg-fault
seems to occur for any of the matplotlib._transform CXX-types.

I can't reproduce the bug with any other python C-entensions
(SWIG-generated wrappers work differently, so the problem doesn't occur).
Both Numeric array and VTK objects work fine with 'issubclass'.

Could this be a problem with CXX? It may be a python bug of course, but it
will be quicker to fix matplotlib than wait for the next python release.

Ideas?

Bryan

On Wed, 2005-03-16 at 20:27 -0800, matplotlib-devel-
re...@li... wrote:
> > I just noticed all of the image and colorbar colors are wrong in
> > GTKCairo (on linux).  When I tried to test on the pure Cairo backend,
> > I get
> > 
> > peds-pc311:~/python/projects/matplotlib/examples> python pcolor_demo.py -dCairo Traceback (most recent call last):
> >   File "pcolor_demo.py", line 25, in ?
> >     savefig('pcolor_demo')
> >   File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig
> >     return fig.savefig(*args, **kwargs)
> >   File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig
> >     self.canvas.print_figure(*args, **kwargs)
> >   File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure
> >     orientation)
> >   File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn
> >     if ext == 'png': _save_png (figure, fileObject)
> >   File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png
> >     ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height)

This looks incomplete, what's the Exception type?
I tried on my system and it ran OK.

The Cairo colour problem has been noticed and discussed on the Cairo
mailing list. The cairo.FORMAT_ARGB32 stores each 32-bit pixel in
native-endian format so on big-endian systems it looks like ARGB and on
little-endian systems (like my PC) it looks like BGRA, I'm not sure if
Cairo will be updated to 'fix' this or not. 
A possible workaround is to check sys.byteorder, and if its 'little'
then get the image module / Agg to generate BGRA (I'm not sure if it can
do this) and even then I think it must be BGRA with litte-endian
ordering. Or a 'bit-flipping' routine could be written to do the same,
but seems like a very inefficient thing to need to do.

I guess a good test to start with would be to see if the colours are
actually correct on a big-endian system. I understand the PowerPC is bi-
endian - the OS imposes the endianness, and that with OS X it is big-
endian. So perhaps someone with a Mac could test if the colours do
currently work.

Or we could simply use RGB32 where the byte order is correct, and do
without the alpha.

Steve

I just noticed all of the image and colorbar colors are wrong in
GTKCairo (on linux).  When I tried to test on the pure Cairo backend,
I get

peds-pc311:~/python/projects/matplotlib/examples> python pcolor_demo.py -dCairo Traceback (most recent call last):
  File "pcolor_demo.py", line 25, in ?
    savefig('pcolor_demo')
  File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig
    return fig.savefig(*args, **kwargs)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure
    orientation)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn
    if ext == 'png': _save_png (figure, fileObject)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png
    ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height)

Here is my configuration information


matplotlib data path /usr/local/share/matplotlib
loaded rc file /home/jdhunter/.matplotlibrc
matplotlib version 0.73
verbose.level helpful
interactive is False
platform is linux2
numerix Numeric 23.6
font search path ['/usr/local/share/matplotlib']
loaded ttfcache file /home/jdhunter/.ttffont.cache
backend GTKCairo version PyGTK(2.2.0),PyCairo ??


JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:

    Jochen> Hi John, in case it is not obvious from my inactivity: it
    Jochen> turns out that I have not enough time and energy to do
    Jochen> much for matplotlib's PostScript backend.  Therefore I
    Jochen> would prefer not to be considered the backend maintainer
    Jochen> any more :-(

    Jochen> Of course I will continue to follow the matplotlib
    Jochen> development and will try to provide patches from time to
    Jochen> time.

Hi Jochen,

Sorry to see you go :-(

Thanks for all the hard work you've put into making the PS backend
compliant.  We'll keep hammering away at it.  Poke in every once in a
while to make sure we aren't mucking things up.

Again, thanks a lot, and thanks for bowing out officially so I know to
take over rather than just grumbling and pestering!

JDH

Hi John,

in case it is not obvious from my inactivity: it turns out that I have
not enough time and energy to do much for matplotlib's PostScript backend.
Therefore I would prefer not to be considered the backend maintainer any
more :-(

Of course I will continue to follow the matplotlib development and will
try to provide patches from time to time.

All the best,
Jochen
--=20
http://seehuhn.de/

I've been tooling around with matplotlib,  as graciously packaged by  
Chris Barker, and hosted on Bob Ippolito's pythonmac.org/packages site.  
  Everything seems to be working smoothly,  but I've run into a couple  
of warnings I can't decrypt.

1) Executing the following code,
#! /usr/bin/pythonw
import pylab
pylab.plot([1, 2, 3], [4, 5, 6])
pylab.show()

displays a chart as expected (the toolbar icons are a little mucked,  
but that's minor).  However, dismissing the chart window brings up this  
warning:

2005-03-12 17:26:52.075 Python[569] *** _NSAutoreleaseNoPool(): Object  
0x66402d0 of class NSCFString autoreleased with no pool in place - just  
leaking
*** malloc[569]: Deallocation of a pointer not malloced: 0x66c73d0;  
This could be a double free(), or free() called with the middle of an  
allocated block; Try setting environment variable MallocHelp to see  
tools to help debug

Is this a bug with matplotlib, with my installation of matplotlib, or  
with my script?  Can I ignore it, and if not, what can I do to address  
it?

2) a smaller issue:  I tried to change matplotlib's array class by  
opening
/system/library/frameworks/python.framework/version/2.3/share/ 
.matplotlibrc
and changing "numerix : numeric"  to "numerix: numarray"  but I got the  
following error:

The import of the numarray version of the _contour module,
_na_contour, failed.  This is is either because numarray was
unavailable when matplotlib was compiled, because a dependency of
_na_contour could not be satisfied, or because the build flag for
this module was turned off in setup.py.  If it appears that
_na_contour was not built, make sure you have a working copy of
numarray and then re-install matplotlib. Otherwise, the following
traceback gives more details:
   File "/platlib/matplotlib/_contour.py", line 5, in ?
ImportError: No module named _na_contour

I know I had numarray installed before unpackaging matplotlib.  Chris'  
notes say that he had numeric installed when he packaged matplotlib,  
but makes no mention of numarray.  Perhaps the matplotlib.mpkg needs to  
be rebuilt on a machine that has numarray installed?  It isn't a big  
deal, as the two types are -mostly- interchangeable, but it would be  
nice to have the choice.

-Brendan

______________________________________________________________________ 

Post your free ad now! http://personals.yahoo.ca

I should have also mentioned that the new signature is document in
backend_bases in the _draw_markers method

    def _draw_markers(self, gc, path, rgbFace, x, y, trans):
        """
        This method is currently underscore hidden because the
        draw_markers method is being used as a sentinel for newstyle
        backend drawing

        path - a matplotlib.agg.path_storage instance
        
        Draw the marker specified in path with graphics context gc at
        each of the locations in arrays x and y.  trans is a
        matplotlib.transforms.Transformation instance used to
        transform x and y to display coords.  It consists of an
        optional nonlinear component and an affine.  You can access
        these two components as

        if transform.need_nonlinear():
          x,y = transform.nonlinear_only_numerix(x, y)
        # the a,b,c,d,tx,ty affine which transforms x and y
        vec6 = transform.as_vec6_val()
        ...backend dependent affine...
        """
        pass

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> John, I noticed ./examples/dash_control.py -dAgg from the
    Steve> latest cvs, is not working..

    Steve> I think the problem may be in lines.set_dashes() If I
    Steve> change self._dashSeq = seq[1] to self._dashSeq = seq it
    Steve> seems to work.

OK, great.  Thanks.

    Steve> Also, what happened to matplotlib.path - it was being used
    Steve> by Cairo for draw_markers()

Hmm.  I thought I posted this already.  I rewrote the path handling to
use agg paths, which are a more complete implementation (eg supporting
move_rel, line_rel and friends.  I found my post as an emacs backup
file, so will just paste it in here -- it provides a code snippent to
convert an agg path to a list path we were using previously.

To: Steve Chaplin <ste...@ya...>
Cc: mat...@li...
Subject: Re: [matplotlib-devel] refactoring the backend drawing methods
From: John Hunter <jdh...@ac...>
Gcc: nnml:outgoing-mail
References: <m3u...@pe...>
	<1110376248.3691.24.camel@f1>
X-Draft-From: ("nnml:mail-list.matplotlib-devel" 1256)
--text follows this line--
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I've implemented draw_markers() for Cairo, and tested it
    Steve> using line- styles.py - it seems to be working OK. I did
    Steve> find that it caused draw_lines() to stop working and had to
    Steve> modify it to get it working again.

Yes, sorry for failing to update you on this.

    Steve> I don't think 'fill' and 'fill_rgb' information should be
    Steve> encoded into the 'path', and would to prefer to have
    Steve> rendering separated into two independent steps: 1) call a
    Steve> function to parse 'path' and generate a path - the path is
    Steve> a general path (with no fill or colour info) that you can
    Steve> later use any way you wish.  2) set colour etc as desired
    Steve> and fill/stroke the path.


    Steve> The draw_markers() code I've written calls generate_path()
    Steve> before drawing each marker and it reads the fill value and
    Steve> the fill_rgb each time which it unnecessary since the
    Steve> values are the same for all the markers. Passing the
    Steve> fill_rgb as an extra argument to draw_markers() would be
    Steve> one way to 'fix' this.

Done.  I also wrapped agg's path storage and am using this rather than
the list storage.  You can get the old representation from the new
rather easily, as illustrated here

import matplotlib.agg as agg

path = agg.path_storage()
path.move_to(10,10)
path.line_to(20,30)
path.curve3_rel(100,200)
path.end_poly()

print [ path.vertex() for i in range(path.total_vertices())] 

    Steve> Cairo (and probably Agg, PS, SVG) supports rel_move_to()
    Steve> and rel_line_to () - so you can define a path using
    Steve> relative rather than absolute coords, which can sometimes
    Steve> be useful.  For example, instead of translate(x,y)
    Steve> generate_absolute_path(path) stroke() you can use
    Steve> move_to(x,y) generate_relative_path(path) stroke() and the
    Steve> path is stroked relative to x,y with no need to translate
    Steve> the coordinates.

agg has move_rel and line_rel, etc, but I don't think it works the
same way, because it computes the actual move_to, line_to, etc under
the hood and stores these values, so I'm not sure it's possible to
actually store a relative moveto in agg.  Could be missing something,
though.  As far as I can see, everything gtes converted to one of the
6 primitive commands (STOP, MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY)
under the hood.

JDH

John,
I noticed
./examples/dash_control.py -dAgg
from the latest cvs, is not working..

I think the problem may be in lines.set_dashes()
If I change
    self._dashSeq = seq[1]
to
    self._dashSeq = seq
it seems to work.


Also, what happened to matplotlib.path - it was being used by Cairo
for draw_markers()

Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I thought I would implement draw_line_collection() for
    Steve> Cairo and looked for an example script I could use for
    Steve> testing. Yet after adding a 'print "line collection"'
    Steve> statement to backend_bases.draw_line_collection() and
    Steve> running backend_driver.py I did not see any examples using
    Steve> line collections.  Does this mean that line collections are
    Steve> not useful, or just that there is no example script (called
    Steve> by backend_driver.py) which uses line collections?

contours use line collections, as does the finance module.  If you run
the contour_demo*.py examples, you should see them called.  It may be
that none of the backend_driver functions use these yet, but the
driver should be updated to include all the new contouring
functionality (very nice contour labeling thanks to Nadia and filled
contours thanks to Nadia and Eric Firing).

    Steve> Also, is it worthwhile implementing these collections
    Steve> routines or are they effectively deprecated and about to be
    Steve> superseded by new path based drawing routines?

The pure python backend implementation is a good bit faster than the
bad old way of using lots of independent objects and gc calls.  It may
be fast enough for a python module like the pycairo backend.  They are
not deprecated, but since no backend other than agg has implemented
them yet, I am amenable to losing them in favor of a streamlined,
reduced API based around paths.

Profile the contour routines on cairo and compare their performance to
agg.  If they are in the same ballpark, you may want to let this lie
for a while.  Ditto for scatter which uses poly collections.  

JDH

I thought I would implement draw_line_collection() for Cairo and looked for
an example script I could use for testing. Yet after adding a 
'print "line collection"' statement to backend_bases.draw_line_collection() 
and running backend_driver.py I did not see any examples using line collections.
Does this mean that line collections are not useful, or just that there is
no example script (called by backend_driver.py) which uses line collections?

Also, is it worthwhile implementing these collections routines or are they
effectively deprecated and about to be superseded by new path based drawing 
routines?

Steve

I've implemented draw_markers() for Cairo, and tested it using line-
styles.py - it seems to be working OK. I did find that it caused
draw_lines() to stop working and had to modify it to get it working
again.

I don't think 'fill' and 'fill_rgb' information should be encoded into
the 'path', and would to prefer to have rendering separated into two
independent steps:
1) call a function to parse 'path' and generate a path - the path is a
general path (with no fill or colour info) that you can later use any
way you wish.
2) set colour etc as desired and fill/stroke the path.

The draw_markers() code I've written calls generate_path() before
drawing each marker and it reads the fill value and the fill_rgb each
time which it unnecessary since the values are the same for all the
markers. Passing the fill_rgb as an extra argument to draw_markers()
would be one way to 'fix' this.

Cairo (and probably Agg, PS, SVG) supports rel_move_to() and rel_line_to
() - so you can define a path using relative rather than absolute
coords, which can sometimes be useful.
For example, instead of
	translate(x,y)
 	generate_absolute_path(path)
        stroke()
you can use 
	move_to(x,y) 
        generate_relative_path(path)
        stroke()
and the path is stroked relative to x,y with no need to translate the
coordinates.

Steve

Hi there,

has anybody thought about a Grace backend, yet? I've recently been using 
Grace for some plotting and was really surprised how the version 5.99 
has evolved over the past months. Not quite finished, but a huge step 
forward compared to the former versions of Grace.

For other tasks, I also have gotten to like the possibility of scripting 
plotting tasks in matplotlib. I have a number of scripts that I really 
don't want to dump completely.

Now my idea was: how about a matplotlib backend producing a .xgr file? 
Unlike the old .agr format, .xgr is now a XML based format describing a 
plot in Grace (without any scripting possibilities)

The structure of an .xgr file is not too different from the model that 
matplotlib uses, so the basic functionality should be rather simple to 
implement.

The main difficulty would probably be, that .xgr describes plots at a 
much higher level than the usual backends. The usual backend interface 
will therefore not work. I have no clear idea yet how the .xgr export 
could be incorporated in the easiest way.

B.t.w: I myself will most likely not be able to spend any serious time 
on this in the near future, so if anybody wants to look into it, I will 
not stand in the way.

Ciao,
Norbert