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