matplotlib-devel Mailing List for matplotlib

>>>>> "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 2005年3月17日 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