I figured it was something like this, and for what I&#39;m doing it is easy enough to swap the bytes. &nbsp;However, as pointed out here, this will be very platform dependent. &nbsp;I&#39;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&#39;m just being dumb (being new to cairo and new to this image stuff in general). &nbsp;Is there a clean way to access pixel-level image_surface data that is not going to run into platform issues? &nbsp;Hopefully this isn&#39;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">&lt;<a href="mailto:spitzak@thefoundry.co.uk">spitzak@thefoundry.co.uk</a>&gt;</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>
&gt; It&#39;s in BGRA format. I think it&#39;s platform and not architecture<br>
&gt; specific since windows at least works with BGR. And the reason for<br>
&gt; that is I guess performance.<br>
<br>
</div>The bytes are in the order BGRA:<br>
<br>
 &nbsp;unsigned char* p = data;<br>
 &nbsp;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>
 &nbsp;unsigned int* p = data;<br>
 &nbsp;p[0] == (A&lt;&lt;24)+(R&lt;&lt;16)+(B&lt;&lt;8)+(B&lt;&lt;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>