Menu
▾
▴
matplotlib-devel
|
From: Darren D. <dd...@co...> - 2007-01-11 15:05:24
|
On Thursday 11 January 2007 09:42, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> I had to alter the following lines from backend_gtkcairo, > Darren> from > > Darren> import matplotlib.backends.backend_cairo as be_cairo from > Darren> matplotlib.backends.backend_gtk import * > > Darren> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py >", Darren> line 11, in ? import matplotlib.backends.backend_cairo as > Darren> be_cairo AttributeError: 'module' object has no attribute Darren> > 'backends' > > > My guess is that you were running your test code in which there was a > "matplotlib" dir that was not *the* matplotlib install dir. > > Possible? It wouldn't have been the first time I made that mistake, but that doesn't seem to be the problem. |
|
From: John H. <jdh...@ac...> - 2007-01-11 14:50:23
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>> I only had a short time to work with backend_gtkcairo, but a
>> couple of things caught my attention. mathtext support seemed
>> to need some improvement, it looked like it was rendered as an
>> image rather than as text. Also, imshow(rand(100,100)) looked
>> very different with gtkcairo and gtkagg, (maybe because the
>> rgba ordering is different in agg and cairo? I'm not sure this
>> is even the case, I'm taking a stab in the dark.)
Steve> cairo mathtext uses a method copied from gdk/gtk and does
Steve> render an image. It needs updating to render text.
Steve> imshow does look different on cairo and agg, and yes, It
Steve> looks like an image format problem. cairo uses ARGB32 with
Steve> pre-multiplied alpha, and the ARGB order depends on whether
Steve> the machine is little- of big-endian.
I am confused by what you mean about the ARGB order depending on
endianess. ARGB defines the order, and each color is one byte, so
where is the ambiguity? Do you mean that depending on endianness,
cairo will use other orderings than ARGB?
In _image.cpp we provide a few buffer methods for various pixel
orderings, eg buffer_argb32. We may need to provide additional
orderings for cairo, and call the right one depending on the platform.
JDH
|
|
From: Steve C. <ste...@ya...> - 2007-01-11 15:37:41
|
On Thu, 2007-01-11 at 08:50 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > >> I only had a short time to work with backend_gtkcairo, but a > >> couple of things caught my attention. mathtext support seemed > >> to need some improvement, it looked like it was rendered as an > >> image rather than as text. Also, imshow(rand(100,100)) looked > >> very different with gtkcairo and gtkagg, (maybe because the > >> rgba ordering is different in agg and cairo? I'm not sure this > >> is even the case, I'm taking a stab in the dark.) > > Steve> cairo mathtext uses a method copied from gdk/gtk and does > Steve> render an image. It needs updating to render text. > > Steve> imshow does look different on cairo and agg, and yes, It > Steve> looks like an image format problem. cairo uses ARGB32 with > Steve> pre-multiplied alpha, and the ARGB order depends on whether > Steve> the machine is little- of big-endian. > > I am confused by what you mean about the ARGB order depending on > endianess. ARGB defines the order, and each color is one byte, so > where is the ambiguity? Do you mean that depending on endianness, > cairo will use other orderings than ARGB? > > In _image.cpp we provide a few buffer methods for various pixel > orderings, eg buffer_argb32. We may need to provide additional > orderings for cairo, and call the right one depending on the platform. This is the official definition from the manual: CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then red, then green, then blue. The 32-bit quantities are stored native-endian. Pre-multiplied alpha is used. (That is, 50% transparent red is 0x80800000, not 0x80ff0000.) What I think this means is: cairo ARGB32 is stored not as 4 8-bit quantities, but as one 32-bit int. On big-endian systems the byte order is ARGB, as you would expect, but on little-endian systems (like a PC) the byte order is BGRA. I imagine the reason is that its easier/faster to read/write one 32-bit int than it is to read/write four bytes. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: John H. <jdh...@ac...> - 2007-01-11 15:56:13
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> This is the official definition from the manual:
Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
Steve> alpha in the upper 8 bits, then red, then green, then
Steve> blue. The 32-bit quantities are stored
Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
Steve> transparent red is 0x80800000, not 0x80ff0000.)
Steve> What I think this means is: cairo ARGB32 is stored not as 4
Steve> 8-bit quantities, but as one 32-bit int. On big-endian
Steve> systems the byte order is ARGB, as you would expect, but on
Steve> little-endian systems (like a PC) the byte order is BGRA.
Steve> I imagine the reason is that its easier/faster to
Steve> read/write one 32-bit int than it is to read/write four
Steve> bytes.
OK, I see the source of my confusion. argb determines the order but
it doesn't determine whether the most significant bit is first or
last....
I added a method buffer_bgra32 to the image backend. I'm not sure
this is the right way to deal with the endianness bit it's easy and
will probably work. I'll leave it to you guys to fix the cairo
backend to selectively call the right method and test it across
platforms, or propose a better solution if you don't like this one...
JDH
|
|
From: Darren D. <dd...@co...> - 2007-01-11 21:13:28
|
On Thursday 11 January 2007 02:01, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
> > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcair
> > >o.py", line 11, in ?
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
>
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was... As far as I can see, that
> code in ipython is simply calling
>
> # Initialize matplotlib to interactive mode always
> import matplotlib
> from matplotlib import backends
>
> inside a function (the _matplotlib_config method). I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.
I've been looking at this, but haven't made much progress. Try this with
backend:gtkcairo in matplotlibrc:
$ python
>>> __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])
output:
<module 'matplotlib.backends.backend_ps'
from '/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_ps.pyc'>
$ ipython
In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])
output:
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent
call last)
/home/darren/<ipython console>
/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
54
55 # a hack to keep old versions of ipython working with mpl
56 if 'IPython.Shell' in sys.modules:
---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
58
/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
pylab_setup()
24 time.sleep(1)
25 backend_mod = __import__('matplotlib.backends.'+backend_name,
---> 26 globals(),locals(),[backend_name])
27
28 # Things we pull in from all backends
/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
7 import cairo.gtk
8
----> 9 import matplotlib.backends.backend_cairo as be_cairo
10 from matplotlib.backends.backend_gtk import *
11
AttributeError: 'module' object has no attribute 'backends'
If you change backend:gtkagg in matplotlibrc, then ipython doesnt complain.
Very strange.
|
|
From: Darren D. <dd...@co...> - 2007-01-11 21:45:20
|
On Thursday 11 January 2007 16:12, Darren Dale wrote:
> $ ipython
>
> In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
> locals(),['backend_ps'])
>
> output:
> ---------------------------------------------------------------------------
> exceptions.AttributeError Traceback (most recent
> call last)
>
> /home/darren/<ipython console>
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py
> 54
> 55 # a hack to keep old versions of ipython working with mpl
> 56 if 'IPython.Shell' in sys.modules:
> ---> 57 new_figure_manager, draw_if_interactive, show = pylab_setup()
> 58
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py in
> pylab_setup()
> 24 time.sleep(1)
> 25 backend_mod = __import__('matplotlib.backends.'+backend_name,
> ---> 26 globals(),locals(),[backend_name])
> 27
> 28 # Things we pull in from all backends
>
> /usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
> 7 import cairo.gtk
> 8
> ----> 9 import matplotlib.backends.backend_cairo as be_cairo
> 10 from matplotlib.backends.backend_gtk import *
> 11
>
> AttributeError: 'module' object has no attribute 'backends'
I found a workaround, and committed it. I don't understand what the root of
the problem was, probably because the AttributeError at the end of the
Traceback is misleading. Changing this:
import matplotlib.backends.backend_cario as be_cairo
to this:
from matplotlib.backends import backend_cairo
and updating references to be_cairo was all that was needed. The fix is in svn
2979.
Darren
|
|
From: Steve C. <ste...@ya...> - 2007-01-12 00:53:28
|
On Thu, 2007-01-11 at 09:56 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> Steve> This is the official definition from the manual:
> Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
> Steve> alpha in the upper 8 bits, then red, then green, then
> Steve> blue. The 32-bit quantities are stored
> Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
> Steve> transparent red is 0x80800000, not 0x80ff0000.)
>
> Steve> What I think this means is: cairo ARGB32 is stored not as 4
> Steve> 8-bit quantities, but as one 32-bit int. On big-endian
> Steve> systems the byte order is ARGB, as you would expect, but on
> Steve> little-endian systems (like a PC) the byte order is BGRA.
>
> Steve> I imagine the reason is that its easier/faster to
> Steve> read/write one 32-bit int than it is to read/write four
> Steve> bytes.
>
> OK, I see the source of my confusion. argb determines the order but
> it doesn't determine whether the most significant bit is first or
> last....
>
> I added a method buffer_bgra32 to the image backend. I'm not sure
> this is the right way to deal with the endianness bit it's easy and
> will probably work. I'll leave it to you guys to fix the cairo
> backend to selectively call the right method and test it across
> platforms, or propose a better solution if you don't like this one...
Thanks, I used the new buffer_bgra32 and now examples/image_demo.py
looks correct (except that sometimes it looks like the pixels right at
the edge of the image might be corrupted).
The backend_cairo.py code does look a little strange, it calls
rows, cols, str_ = im.buffer_bgra32()
and then
X = numx.fromstring (str_, numx.UInt8)
which is used merely to convert the (readonly) string returned from
buffer_bgra32 into a read-write buffer for cairo. If buffer_bgra32
returned a buffer (as its name suggests!) instead of a string this would
not be needed, and it would save copying the image around in memory.
I propose this new version of buffer_bgra32 (and buffer_argb32). I
tested it with cairo and it seems to work OK.
Py::Object
Image::buffer_bgra32(const Py::Tuple& args) {
//"Return the image object as bgra32";
_VERBOSE("RendererAgg::buffer_bgra32");
args.verify_length(0);
int row_len = colsOut * 4;
PyObject* py_buffer = PyBuffer_New(row_len * rowsOut);
if (py_buffer ==NULL)
throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
unsigned char* buf;
int buffer_len;
int ret = PyObject_AsWriteBuffer(py_buffer, (void **)&buf,
&buffer_len);
if (ret !=0)
throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
agg::rendering_buffer rtmp;
rtmp.attach(buf, colsOut, rowsOut, row_len);
agg::color_conv(&rtmp, rbufOut, agg::color_conv_rgba32_to_bgra32());
PyObject* o = Py_BuildValue("llN", rowsOut, colsOut, py_buffer);
return Py::asObject(o);
}
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: John H. <jdh...@ac...> - 2007-01-12 14:44:58
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> I propose this new version of buffer_bgra32 (and
Steve> buffer_argb32). I tested it with cairo and it seems to work
Steve> OK.
This looks good -- please test it with one of the memleak scripts, eg
a variant of units/memleak_hawaii.py to make sure everything is being
cleaned up properly. If you feel motivated, please port these over to
the other buffer methods. One way to do this cleanly would be to set
up an enum of the agg pixel formats supported by agg::color_conv and
then simply allow the user to pass in the pixel format desired. Ie,
support
color_conv_rgba32_to_abgr32
color_conv_rgba32_to_argb32
color_conv_rgba32_to_bgra32
in a single function with a single arg.
JDH
|
|
From: Steve C. <ste...@ya...> - 2007-01-15 12:04:10
|
On Fri, 2007-01-12 at 08:44 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> I propose this new version of buffer_bgra32 (and > Steve> buffer_argb32). I tested it with cairo and it seems to work > Steve> OK. > > This looks good -- please test it with one of the memleak scripts, eg > a variant of units/memleak_hawaii.py to make sure everything is being > cleaned up properly. If you feel motivated, please port these over to > the other buffer methods. One way to do this cleanly would be to set > up an enum of the agg pixel formats supported by agg::color_conv and > then simply allow the user to pass in the pixel format desired. Ie, > support > > color_conv_rgba32_to_abgr32 > color_conv_rgba32_to_argb32 > color_conv_rgba32_to_bgra32 > > in a single function with a single arg. I've replaced buffer_argb32() and buffer_bgra32() with Image::color_conv(format) and tested it for memory leaks and it seems OK. I think this only affects the cairo backend, since the other backends seem to use rgba and don't need to use a color conversion method. Steve Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Steve C. <ste...@ya...> - 2007-01-15 04:16:46
|
On Thu, 2007-01-11 at 00:01 -0700, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <ste...@ya...> wrote:
> > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote:
>
> > > I had to alter the following lines from backend_gtkcairo, from
> > >
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > from matplotlib.backends.backend_gtk import *
> > >
> > > to
> > >
> > > import backend_cairo as be_cairo
> > > from backend_gtk import *
> > >
> > > in order to prevent the following traceback:
> > >
> > > Traceback (most recent call last):
> > > File "/usr/bin/ipython", line 27, in ?
> > > IPython.Shell.start().mainloop()
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in
> > > start
> > > return shell(user_ns = user_ns)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in
> > > __init__
> > > shell_class=MatplotlibMTShell)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in
> > > __init__
> > > on_kill=[mainquit])
> > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in
> > > make_IPython
> > > embedded=embedded,**kw)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in
> > > __init__
> > > user_ns,b2 = self._matplotlib_config(name,user_ns)
> > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in
> > > _matplotlib_config
> > > from matplotlib import backends
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > line 55, in ?
> > > new_figure_manager, draw_if_interactive, show = pylab_setup()
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py",
> > > line 23, in pylab_setup
> > > globals(),locals(),[backend_name])
> > >
> > > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py",
> > > line 11, in ?
> > > import matplotlib.backends.backend_cairo as be_cairo
> > > AttributeError: 'module' object has no attribute 'backends'
> >
> > The original matplotlib code is correct, you should be editing IPython
> > and correcting their bug!
>
> Well, I'd be delighted to correct the ipython bug, if only I
> understood exactly what the problem was... As far as I can see, that
> code in ipython is simply calling
>
> # Initialize matplotlib to interactive mode always
> import matplotlib
> from matplotlib import backends
>
> inside a function (the _matplotlib_config method). I don't see a bug
> in that, but if you provide some pointers, I'll be happy to fix any
> issues that are on ipython's side of the fence.
Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My
view is that the lines
from matplotlib.backends import backend_cairo
from matplotlib.backends.backend_gtk import *
work fine when called from the Python prompt. They are using the
absolute package path and are correct and should not be "fixed" to use
relative imports (which is bad style). So if there is a bug it is
elsewhere and from the traceback it looked like ipython is involved.
The traceback shows that this code is being executed
# a hack to keep old versions of ipython working with mpl
if 'IPython.Shell' in sys.modules:
new_figure_manager, draw_if_interactive, show = pylab_setup()
which is ipython-specific code.
I don't usually use IPython, but I installed it today and ran a few
simple matplotlib plots with the GTKCairo backend and they worked OK! So
I can't offer more info, perhaps Darren can produce a minimal test case
to isolate the problem.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: Darren D. <dd...@co...> - 2007-01-15 11:36:28
|
On Monday 15 January 2007 12:16 am, Steve Chaplin wrote: > On Thu, 2007-01-11 at 00:01 -0700, Fernando Perez wrote: > > On 1/10/07, Steve Chaplin <ste...@ya...> wrote: > > > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > > > > I had to alter the following lines from backend_gtkcairo, from > > > > > > > > import matplotlib.backends.backend_cairo as be_cairo > > > > from matplotlib.backends.backend_gtk import * > > > > > > > > to > > > > > > > > import backend_cairo as be_cairo > > > > from backend_gtk import * > > > > > > > > in order to prevent the following traceback: > > > > > > > > Traceback (most recent call last): > > > > File "/usr/bin/ipython", line 27, in ? > > > > IPython.Shell.start().mainloop() > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 1034, in start > > > > return shell(user_ns = user_ns) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 945, in __init__ > > > > shell_class=MatplotlibMTShell) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 622, in __init__ > > > > on_kill=[mainquit]) > > > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line > > > > 90, in make_IPython > > > > embedded=embedded,**kw) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 506, in __init__ > > > > user_ns,b2 = self._matplotlib_config(name,user_ns) > > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line > > > > 397, in _matplotlib_config > > > > from matplotlib import backends > > > > File > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > > > line 55, in ? > > > > new_figure_manager, draw_if_interactive, show = pylab_setup() > > > > File > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > > > line 23, in pylab_setup > > > > globals(),locals(),[backend_name]) > > > > > > > > File > > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkca > > > >iro.py", line 11, in ? > > > > import matplotlib.backends.backend_cairo as be_cairo > > > > AttributeError: 'module' object has no attribute 'backends' > > > > > > The original matplotlib code is correct, you should be editing IPython > > > and correcting their bug! > > > > Well, I'd be delighted to correct the ipython bug, if only I > > understood exactly what the problem was... As far as I can see, that > > code in ipython is simply calling > > > > # Initialize matplotlib to interactive mode always > > import matplotlib > > from matplotlib import backends > > > > inside a function (the _matplotlib_config method). I don't see a bug > > in that, but if you provide some pointers, I'll be happy to fix any > > issues that are on ipython's side of the fence. > > Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My > view is that the lines > from matplotlib.backends import backend_cairo > from matplotlib.backends.backend_gtk import * > work fine when called from the Python prompt. They are using the > absolute package path and are correct and should not be "fixed" to use > relative imports (which is bad style). So if there is a bug it is > elsewhere and from the traceback it looked like ipython is involved. > > The traceback shows that this code is being executed > # a hack to keep old versions of ipython working with mpl > if 'IPython.Shell' in sys.modules: > new_figure_manager, draw_if_interactive, show = pylab_setup() > > which is ipython-specific code. > I don't usually use IPython, but I installed it today and ran a few > simple matplotlib plots with the GTKCairo backend and they worked OK! So > I can't offer more info, perhaps Darren can produce a minimal test case > to isolate the problem. They work ok now, after changing the import statement so that it doesnt rename backend_cairo to be_cairo in the gtkcairo namespace. I can't think of a more minimal example than the one I already provided: starting IPython without the pylab flag and importing matplotlib.backends.backend_gtkcairo. I looked at this for a couple hours last week, and was not able to determine whether it was an IPython bug or a matplotlib bug that is exposed by IPython's magic. I do agree that the absolute path imports are correct and are not the source of the problem. Since a workaround has been committed, I don't think I should spend more time on this issue (unless another problem emerges). Darren |
|
From: Fernando P. <fpe...@gm...> - 2007-01-15 15:26:40
|
On 1/14/07, Steve Chaplin <ste...@ya...> wrote: > Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My > view is that the lines > from matplotlib.backends import backend_cairo > from matplotlib.backends.backend_gtk import * > work fine when called from the Python prompt. They are using the > absolute package path and are correct and should not be "fixed" to use > relative imports (which is bad style). So if there is a bug it is > elsewhere and from the traceback it looked like ipython is involved. > > The traceback shows that this code is being executed > # a hack to keep old versions of ipython working with mpl > if 'IPython.Shell' in sys.modules: > new_figure_manager, draw_if_interactive, show = pylab_setup() > > which is ipython-specific code. > I don't usually use IPython, but I installed it today and ran a few > simple matplotlib plots with the GTKCairo backend and they worked OK! So > I can't offer more info, perhaps Darren can produce a minimal test case > to isolate the problem. Those lines also work fine from an ipython prompt: In [1]: from matplotlib.backends import backend_cairo In [2]: from matplotlib.backends.backend_gtk import * The point is that for some bizarre reason, /inside/ the ipython/matplotlib initialization, Darren was seeing a problem. It may very well be that the real culprit is ipython, but after looking at the issue I can't see anything, and Darren also tried to understand it and failed. So given this, Darren found a solution by modifying matplotlib. Unless you can suggest a proper fix, I think we'll have for now to live with this, even if it's in principle not ideal. If none of us can figure out the real problem, at least Darren's solution works, so it's better than leaving the bug in place. Cheers, f |
|
From: Steve C. <ste...@ya...> - 2007-01-16 01:47:30
|
On Mon, 2007-01-15 at 08:26 -0700, Fernando Perez wrote:
> Those lines also work fine from an ipython prompt:
>
> In [1]: from matplotlib.backends import backend_cairo
>
> In [2]: from matplotlib.backends.backend_gtk import *
They work, but they are not relevant to this problem. Darren has
confused the issue by applying a fix to backend_gtkcairo.py (with no
CHANGELOG comment) while you and I are investigating the problem. So we
are executing the workaround command and are unable to reproduce the
bug.
However, if I put the line
import matplotlib.backends.backend_cairo as be_cairo
back into backend_gtkcairo.py I can now see the problem.
$ python
Python 2.4.3 (#1, Oct 1 2006, 18:00:19)
[GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.backends.backend_gtkcairo
$ ipython
Python 2.4.3 (#1, Oct 1 2006, 18:00:19)
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import matplotlib.backends.backend_gtkcairo.py
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most
recent call last)
/home/iuser/<ipython console>
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py
52
53 # a hack to keep old versions of ipython working with mpl
54 if 'IPython.Shell' in sys.modules:
---> 55 new_figure_manager, draw_if_interactive, show =
pylab_setup()
56
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py in
pylab_setup()
22 backend_name = 'backend_'+backend.lower()
23 backend_mod =
__import__('matplotlib.backends.'+backend_name,
---> 24 globals(),locals(),[backend_name])
25
26 # Things we pull in from all backends
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
8
9 #from matplotlib.backends import backend_cairo
---> 10 import matplotlib.backends.backend_cairo as be_cairo
11 from matplotlib.backends.backend_gtk import *
12
AttributeError: 'module' object has no attribute 'backends'
Send instant messages to your online friends http://au.messenger.yahoo.com
|
|
From: Eric F. <ef...@ha...> - 2007-07-06 19:33:02
|
All, I am reviving this old thread because the topic came up in a thread with a less-apropos name, and I think we can move it forward a bit more now. Steve's message (below) is still a useful summary of the cairo status. examples/backend_driver.py can now be used for wholesale testing and comparison of the cairo backend. Example: python backend_driver.py cairo.png agg will make png files using cairo and using agg. On my machine (Thinkpad T60, ubuntu feisty) it takes 0.96 minutes for Cairo, 0.76 for Agg. There are two conspicuous bugs in the Cairo output: 1) contour_demo.py: the image part of the figure is wrong in shape and content. It looks like an array dimensions confusion or something like that. Strangely, the very similar image in image_demo.py is fine. 2) polar_demo.py: the part of the spiral outside the bounding circle is removed in the Agg version but not in the Cairo version. There are also subtle differences such as in text positioning. The colorbar in image_masked.py is an example of a case where the agg rendering is much better than the Cairo rendering, which has some sort of aliasing that causes stripes. There are probably other such things worth pointing out. For pdf output I have not tried to look at all the images, but the timing is Cairo 0.71 minutes, pdf backend 1.56 minutes. I have also modified matplotlib.use() and the command-line parsing so that the "cairo.pdf" style of backend.output specification works in both places. (Only for cairo--it is not needed for any other backend.) I am not the right person to try to fix the bugs in the Cairo backend, but I hope it will indeed be moved forward. It looks like it is close, and it could be a big asset for matplotlib in the longer term. Eric Steve Chaplin wrote: > On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote: >> Steve, >> >> Darren Dale raised a question offline that I think will be of general >> interest to mpl devels, and that you are the person to answer: >> >> How do you see the future of a cairo backend as a prospective >> replacement for most or all of the primary mpl backends? > I think cairo could potentially be used to replace the pdf, ps, svg > and gdk/gtk backends which would unify most of the backends and simplify > a lot of the code. > >> What would need to be completed in cairo? Based on the cairo web page, I >> get the impression that quite a bit is still missing, including eps >> generation and genuine vector ps. But maybe the web page is just out of >> date. > Which web page is out of date? Where does it mention eps and ps, I > couldn't find it. > > My general impression of the cairo "surfaces" is: > ImageSurface/png - support is very good > gtk/xlib - support is very good > ps/pdf/svg are usable but less mature and still developing so there may > be occasional problems drawing specific items > ps - it used to embed bitmap images but now most output is vector based > eps - is not supported yet, but may be in a future version > >> What would need to be done in mpl, and how hard would it be? > The cairo backend can already be used for png, ps, pdf and gtk output so > I don't think there would be much to do. Mostly, it needs testing - > running all the mpl examples and checking the output looks OK. > >> Would mpl get slower if everything went through cairo? > Not sure, you would need to run cairo and test it. It used to be much slower > than Agg but more recent versions have had many optimisations applied and > the difference is much smaller now. > >> Any other considerations? > Some parts of mpl are Agg-specific and other parts (the whole drawing model) > are designed around the gdk drawing style - this makes things harder and > inefficient when using cairo. > > On Sat, 2007-01-06 at 09:36 -1000, Eric Firing wrote: >> One more question: how does the image quality of cairo compare to >> Agg? >> Is the antialiasing as good? > Image quality looks OK to me, but I'm no expert. > > The web browser Firefox 3.0 (due to be released early in 2007) will use > cairo for all rendering. Firefox requires a high level of graphics > performance and the upcoming cairo 1.4 release is expected to provide > that. > > Steve > > Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: John H. <jd...@gm...> - 2007-07-06 20:02:34
|
On 7/6/07, Eric Firing <ef...@ha...> wrote:
> 2) polar_demo.py: the part of the spiral outside the bounding circle is
> removed in the Agg version but not in the Cairo version.
This is a fairly new feature I added to add -- clipping to a polygon.
I haven't ported it to postscript yet. The GraphicsContext now has a
clip_path attribute, which is an agg path storage instance. Even
though it is an agg object (not related to backend_agg actually,
separate code base and wrapping) Eg if we construct a path with
from matplotlib import agg
path = agg.path_storage()
path.move_to(10,10)
path.line_to(100,100)
path.line_to(200,200)
path.line_to(100,200)
path.close_polygon()
We can access it from python code like
In [62]: for i in range(path.total_vertices()):
....: cmd, x, y = path.vertex(i)
....: print cmd, x, y
....:
1 10.0 10.0
2 100.0 100.0
2 200.0 200.0
2 100.0 200.0
79 0.0 0.0
Where each of the cmd is an integer given by one of the path commands
In [60]: for name in dir(agg):
....: if not name.startswith('path_cmd'): continue
....: print name, getattr(agg, name)
....:
path_cmd_catrom 6
path_cmd_curve3 3
path_cmd_curve4 4
path_cmd_curveN 5
path_cmd_end_poly 15
path_cmd_line_to 2
path_cmd_mask 15
path_cmd_move_to 1
path_cmd_stop 0
path_cmd_ubspline 7
The final command "79" which is the result of the
path.close_polygon() function call is a mask of two flags
In [65]: agg.path_flags_close | agg.path_cmd_end_poly
Out[65]: 79
Steve had expressed some dissatisfaction in using the agg python
object for path storage, because agg is C++ whereas cairo is C, and it
just feels wrong to be using an agg path for cairo, but at the end of
the day, we faced either rolling our own backend independent path
object or reusing one, and since agg is fairly deeply ingrained into
mpl and unlikely to disappear, I decided to do a backend independent
SWIG wrapping of agg that could be used across backends to expose some
of the data structures and functionality (eg image interpolation, path
structures, whatever). The idea was to eventually get rid of backend
agg entirely and replace it with backend_agg2 which uses the SWIG
python layer and thereby exposing more of agg's general functionality
at the python/user layer. Unfortunately, this project has stalled and
we currently have the agg layer but are not using it for agg backend
rendering, which is still done in the custom CXX extension code.
The agg path structure is used very lightly currently at the python
level, so if folks fine this arrangement problematic we can
reconsider.
JDH
|
|
From: Steve C. <ste...@ya...> - 2007-07-08 12:23:39
|
Carl, I've not been following the matplotlib mailing lists recently, but I came across your blog and had a look at the cairo patches. It looks like all the cairo patches are against some old version of matplotlib. patch #2 enable clipping I enabled clipping in Jan-2007. patch #1 for 'snapping' The patch did not reach the mailing list (?). But in a later mail you mention that snapping smooth, curved user data is a really bad idea. So the patch should probably not be applied. patch #3 snap dash lengths, relies on patch #1. I think this patch has the problems of patch #1 - if the dashes are being used to draw axes or gridlines then snapping is OK. But if the dashes are for user data then snapping is not necessarily what you want. I think the real problem highlighted by patches #1 and #3 is that matplotlib (the frontend) does not tell the backends when it is drawing the plot axes and gridlines to enable the backends to switch on pixel aligned drawing. patch #4 for arcs Looks good, applied it today. Regards, Steve. |
|
From: Eric F. <ef...@ha...> - 2007-07-06 23:30:35
|
> There are two conspicuous bugs in the Cairo output: > > 1) contour_demo.py: the image part of the figure is wrong in shape and > content. It looks like an array dimensions confusion or something like > that. Strangely, the very similar image in image_demo.py is fine. I fixed this bug. There is still a bug illustrated by examples/figimage_demo.py, however, that I did not mention before. I don't plan to look for it, so I hope someone else does. Eric |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X