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.phpp=sourceforgeCID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
