I figured it was something like this, and for what I'm doing it is easy enough to swap the bytes. However, as pointed out here, this will be very platform dependent. I'm a little surprised that cairo does not have a pixel_c (or possibly a set of them -- one for each format) that abstracts the image data away from the platform.<div>
<br></div><div>Maybe I'm just being dumb (being new to cairo and new to this image stuff in general). Is there a clean way to access pixel-level image_surface data that is not going to run into platform issues? Hopefully this isn't too dumb of a question...</div>
<div><br></div><div><br><br><div class="gmail_quote">On Wed, Feb 11, 2009 at 4:21 AM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@thefoundry.co.uk">spitzak@thefoundry.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Gerdus van Zyl wrote:<br>
> It's in BGRA format. I think it's platform and not architecture<br>
> specific since windows at least works with BGR. And the reason for<br>
> that is I guess performance.<br>
<br>
</div>The bytes are in the order BGRA:<br>
<br>
unsigned char* p = data;<br>
p[0] == B, p[1] == G, p[2] == B, p[3] == A<br>
<br>
Sometimes this is called ARGB32 (and sometimes just ARGB), because this<br>
is the order the bytes appear if you look at a 32-bit word:<br>
<br>
unsigned int* p = data;<br>
p[0] == (A<<24)+(R<<16)+(B<<8)+(B<<0);<br>
<br>
We are pretty much stuck with this, as Windows used ARGB32 to represent<br>
colors, so all the graphics cards made that the fastest format.<br>
<br>
It appears on big-endian machines like PowerPC, the native data is<br>
*still* ARGB32, but that means the bytes are in the reversed order ARGB.<br>
This is because the 32-bit bus that connects to the graphics is swapped<br>
around so that 32-bit integers and floats look the same to the graphics<br>
cards. I am not sure about this, somebody please correct me if wrong.<br>
However if this is true it is probably best to not use bytes, but use<br>
words to address your image data at all times, so that your code is<br>
portable to big-endian.<br>
<font color="#888888"><br>
--<br>
Bill Spitzak, Senior Software Engineer<br>
The Foundry, 1 Wardour Street, London, W1D 6PA, UK<br>
Tel: +44 (0)20 7434 0449 * Fax: +44 (0)20 7434 1550 * Web:<br>
<a href="http://www.thefoundry.co.uk" target="_blank">www.thefoundry.co.uk</a><br>
The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
cairo mailing list<br>
<a href="mailto:cairo@cairographics.org">cairo@cairographics.org</a><br>
<a href="http://lists.cairographics.org/mailman/listinfo/cairo" target="_blank">http://lists.cairographics.org/mailman/listinfo/cairo</a><br>
</div></div></blockquote></div><br></div>