pixel formats and endian-ness

bridged with qdn.public.ddk.graphics
Post Reply
Patrick Mueller

pixel formats and endian-ness

Post by Patrick Mueller » Thu Jul 17, 2003 3:04 pm

Reference:


http://www.qnx.com/developer/docs/momen ... xel_format

(sorry, that URL may wrap)

I'm curious if the multi-byte sized formats, specifically,

DISP_SURFACE_FORMAT_ARGB1555
DISP_SURFACE_FORMAT_RGB565
DISP_SURFACE_FORMAT_RGB888
DISP_SURFACE_FORMAT_ARGB8888

are expecting the rgb data to be in the order specified, in the current
endian. For example, RGB888 implies 3 bytes per pixel, with the 'first'
byte being red, 'second' being green, 'third' being blue. What I'm
wondering about is the definition of 'first' ... 'third'.

I assume the values are integral based on the current endian. So, a pure
red pixel on big endian would be stored as the following three bytes in
memory:

0xFF 0x00 0x00

But on a little endian platform, would be stored like so:

0x00 0x00 0xFF

I make this assumption based on some of the verbage on the page like "most
signficant bit", which to me, implies that you treat these values as native
integral values (although obviously RGB888 needs a bit of hacking, until we
have platforms that support 3-byte integral values :-)

It would be useful to clarify this in the doc ...

--
Patrick Mueller
pmuellr@yahoo.com

David Donohoe

Re: pixel formats and endian-ness

Post by David Donohoe » Tue Jul 22, 2003 6:38 pm

Patrick Mueller <pmuellr@yahoo.com> wrote:
Reference:

http://www.qnx.com/developer/docs/momen ... xel_format

(sorry, that URL may wrap)

I'm curious if the multi-byte sized formats, specifically,

DISP_SURFACE_FORMAT_ARGB1555
DISP_SURFACE_FORMAT_RGB565
DISP_SURFACE_FORMAT_RGB888
DISP_SURFACE_FORMAT_ARGB8888

are expecting the rgb data to be in the order specified, in the current
endian. For example, RGB888 implies 3 bytes per pixel, with the 'first'
byte being red, 'second' being green, 'third' being blue. What I'm
wondering about is the definition of 'first' ... 'third'.

I assume the values are integral based on the current endian. So, a pure
red pixel on big endian would be stored as the following three bytes in
memory:

0xFF 0x00 0x00

But on a little endian platform, would be stored like so:

0x00 0x00 0xFF

I make this assumption based on some of the verbage on the page like "most
signficant bit", which to me, implies that you treat these values as native
integral values (although obviously RGB888 needs a bit of hacking, until we
have platforms that support 3-byte integral values :-)

It would be useful to clarify this in the doc ...
Will keep this in mind next time the DDK doc is revisited.
--
Patrick Mueller
pmuellr@yahoo.com

Post Reply

Return to “qdn.public.ddk.graphics”