matplotlib-devel Mailing List for matplotlib

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

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)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

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