Thread: [matplotlib-devel] Re: image colors wrong on GTK Cairo

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

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

On Thu, 2005-03-17 at 17:16 -0600, John Hunter wrote:
> >>>>> "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?
Yes, I'm using CVS. Cairo is currently undergoing rapid development so
one day CVS may compile, the next day it may not, and the day after it
may be fixed and working again. PyCairo will be constantly lagging
behind, trying to keep up with all the changes. Periodically cairo does
a snapshot release and I intend to do a pycairo snapshot release that is
synchronised to cairo snapshot.
The most recent releases are the cairo 0.4.0 and pycairo 0.4.0 snapshots
which should compile OK and work together.

> ### 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>
This looks like an old pycairo version which took a filename (str) instead of a fileobject for set_target_png()

Steve

On Thu, 2005-03-17 at 17:16 -0600, John Hunter wrote:
> ### 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

Here's some notes I found regarding changes to cairo-features.h:

1) The public header files will no longer be directly installed into
   the system include directory. They will now be installed in a
   subdirectory named "cairo", (eg. in /usr/include/cairo rather than
   in /usr/include).

   For applications using pkg-config, the change should be mostly
   transparent, as pkg-config will find the new directory.

   However, user will also need to manually remove the old versions of
   cairo.h and cairo-features.h from the system include directories in
   order to prevent them being found first.

Steve