Jason Tackaberry writes:
> Evas's internals are ARGB? Well isn't that a hell of a thing.
> I thought for sure when I was looking at the raw data from
> evas_object_image_data_get() that it was in BGRA pixel format.
> (Note that I'm on intel, which is little endian, so BGRA32 has
> BGRA pixel order [low to high memory address])
I'm glad you've brought this issue up, since it's
something that has always caused some confusion for me.
Let me thus take a minute here to write what I see as
the relevant aspects here, and when Carsten wakes up he can set
this straight :)
That evas internally uses 'argb32 pixel format' for image
data means the following:
If you give four unsigned char values, a, r, g, b, which are
supposed to represent the alpha, red, green, blue, components
of a color, then evas will encode this as an unsigned int c,
of value c = (a<<24)+(r<<16)+(g<<8)+(b).
To obtain the a,r,g,b components back from c, we have
that a = (c>>24)&0xff, r = (c>>16)&0xff, g = (c>>8)&0xff, and
b = (c>>0)&0xff,
This is, as I understand it, independent of machine byte
order.
Now, if you give instead an unsigned char* s which
is 4 bytes in size, then there are two separate but related
notions dealing with how to obtain the pixel c (in argb32 format
as defined above) -- one notion is the machine byte order, and
the other is the 'pixel format' of the given s.
Similarly, if we start with c, and we are asked to
assign a 4 byte sized unsigned char* s from it, then again one
has these two notions to deal with.
Let's take the case of how to assign an unsigned char *s
(of 4 bytes in size) from the unsigned int c.
We can get the a,r,g,b values as above, but there is
a question as to how to assign these to s, ie. what values to
give to s[0],s[1],s[2],s[3]. Should s[0] be a or b or what...
That is presumably what the 'pixel-format' of the output
is supposed to determine. As I interpret this, that s has 'argb'
pixel-format means s[0] is the a, s[1] the r, etc.. and that it
has 'bgra' format means that s[0] is the b, s[1] the g, etc.
The notion of machine byte order further complicates
matters if one tries to obtain the a,r,g,b components from c
by casting &c to an unsigned char*, as then we have that eg.
(unsigned char*)(&c)[0] can be either b or a, depending on wether
the machine byte-order is big-endian or little-endian, respectively.
If we are on a "big-endian" machine, like an x86, then
(unsigned char*)(&c)[3] gives the a, whereas on a "little-endian"
machine, a is instead (unsigned char*)(&c)[0].
So, eg. if on a big-endian machine:
If s is to be in 'argb32' pixel-format, then,
s[0] = a = (c>>24)&0xff = (unsigned char*)(&c)[3],
s[1] = r = (c>>16)&0xff = (unsigned char*)(&c)[2],
etc.
If s is to be in 'bgra32' format, then,
s[0] = b = (c>>0)&0xff = (unsigned char*)(&c)[0]
s[1] = g = (c>>8)&0xff = (unsigned char*)(&c)[1]
etc.
On a little-endian machine, this becomes:
If s is to be in 'argb32' pixel-format, then,
s[0] = a = (c>>24)&0xff = (unsigned char*)(&c)[0],
s[1] = r = (c>>16)&0xff = (unsigned char*)(&c)[1],
etc.
If s is to be in 'bgra32' format, then,
s[0] = b = (c>>0)&0xff = (unsigned char*)(&c)[3]
s[1] = g = (c>>8)&0xff = (unsigned char*)(&c)[2]
etc.
I've not really had a chance to look at what
evas actually does for the conversions to/fro of the
internal unsigned int 'argb32' encoded color data that
it uses, and the various output formats.. It's possible
that there may be some funkiness somewhere :)
jose.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
