<div class="im">On Tue, Jun 1, 2010 at 4:29 PM, Bill Spitzak <span dir="ltr">&lt;<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>&gt;</span>
 wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Actually Cairo&#39;s image format is ARGB32, meaning each 32-bit word has 
the bits arranged so that A is the high-order 8 bits and B in the lowest
 8 bits. On a little-endian machine the bytes are then arranged in BGRA 
order, but on a big-endian machine they would be ARGB.<br>
</blockquote></div><div><br>Isn&#39;t that what I said? On x86, Cairo&#39;s 
format looks like (B, G, R, A) when addressed as individual bytes, where
 A is the most significant byte of the 32-bit number. DevIL&#39;s IL_RGBA 
format looks like (R, G, B, A) on my Intel PC, so I&#39;m assuming its 
format is not affected by endianness (it would be silly to call it RGBA 
if stored as ABGR on big-endian systems).<br>
 <br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I think DevIL will need to be changed. ARGB32 is used extensively and is
 often the only or most-accelerated option on graphics hardware, due to 
it being the format used by the Windows API.<div><div>
<br></div></div></blockquote></div><br>On x86 systems you can get 
the same ordering as Cairo by loading images as IL_BGRA, but I think 
that makes the labeling differences even more confusing. In any case, so
 long as it&#39;s properly documented I&#39;m not sure how much it matters, as 
dealing with the order of components isn&#39;t the only transformation that 
you need to apply when converting from DevIL to Cairo.