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