On Sun, 2 Apr 2006 23:30:31 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > 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 :) there was - i never finished off the BGRA code for the buffer canvas :) i never used it - and i think this was the first case of someone using it :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- 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&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
