Re: [matplotlib-devel] Cairo backend prospects

[Steve Chaplin]

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

cairo mathtext uses a method copied from gdk/gtk and does render an
image. It needs updating to render text.

imshow does look different on cairo and agg, and yes, It looks like an
image format problem. cairo uses ARGB32 with pre-multiplied alpha, and
the ARGB order depends on whether the machine is little- of big-endian.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[John Hunter]

> "Darren" == Darren Dale <[EMAIL PROTECTED]> 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?

JDH

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[John Hunter]

> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> 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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[Darren Dale]

On Thursday 11 January 2007 09:42, John Hunter wrote:
> > "Darren" == Darren Dale <[EMAIL PROTECTED]> 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.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[Peter Wang]

On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:

>> I have never run into a problem with relative imports, though I don't
>> object to removing them.  Why are they bad style and what is the  
>> danger?
>
> Its because you can unwittingly end up with module name clashes. There
> can be two different modules in two different directories with the  
> same
> name and you import the wrong module by mistake.

Just wanted to chime in here --
with python 2.5, you can have your cake and eat it too:

from .localpkg import Symbol1, Symbol2
from . import localpkg

This disambiguates the "calendar.py" problem that you had (and that  
about 90% of python coders have had at least once in their lives). :)


-Peter

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[Steve Chaplin]

On Thu, 2007-01-11 at 08:50 -0600, John Hunter wrote:
> > "Steve" == Steve Chaplin <[EMAIL PROTECTED]> 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 0x8080, not 0x80ff.)

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 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[John Hunter]

> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> 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 0x8080, not 0x80ff.)

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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[Darren Dale]

On Thursday 11 January 2007 02:01, Fernando Perez wrote:
> On 1/10/07, Steve Chaplin <[EMAIL PROTECTED]> 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:


$ ipython

In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
locals(),['backend_ps'])

output:
---
exceptions.AttributeErrorTraceback (most recent 
call last)

/home/darren/

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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] matplotlib-0.87.7 Build Failure -- Part I

[Rich Shepard]

On Thu, 11 Jan 2007, Rich Shepard wrote:

>  When I ran the script with -dWXAgg, it segfaulted.

   But, when I run with -dWX, it completes and displays the plot. Ergo,
there's something wrong with Agg here, I suppose.

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.   |The Environmental Permitting
Applied Ecosystem Services, Inc.|  Accelerator(TM)
 Voice: 503-667-4517  Fax: 503-667-8863

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[Darren Dale]

On Thursday 11 January 2007 16:12, Darren Dale wrote:
> $ ipython
>
> In [1]: __import__('matplotlib.backends.backend_ps', globals(),\
> locals(),['backend_ps'])
>
> output:
> ---
> exceptions.AttributeErrorTraceback (most recent
> call last)
>
> /home/darren/
>
> /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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Cairo backend prospects

[Steve Chaplin]

On Thu, 2007-01-11 at 09:56 -0600, John Hunter wrote:
> > "Steve" == Steve Chaplin <[EMAIL PROTECTED]> 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 0x8080, not 0x80ff.)
> 
> 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 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] matplotlib-0.87.7 Build Failure -- SOLVED

[Rich Shepard]

On Thu, 11 Jan 2007, John Hunter wrote:

> Hmm, what version of wx are you using?  Charlie Moad wrote some
> extension code to make the transfer from agg to the wx canvas more
> efficient.  This looks like the module in question.  Can you

John, et al.:

   Running 0.87.7 on my Slackware-11.0 box does not produce the segmentation
fault that it does on my Slackware-10.2 box. So, the latter will be upgraded
on Saturday and it won't be an issue any more.

Thanks,

Rich

-- 
Richard B. Shepard, Ph.D.   |The Environmental Permitting
Applied Ecosystem Services, Inc.|  Accelerator(TM)
 Voice: 503-667-4517  Fax: 503-667-8863

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel