From c8610ae9e29d12aadd436203336c4d8ec85415d6 Mon Sep 17 00:00:00 2001 From: pacman Date: Fri, 24 Feb 2006 22:18:45 +0000 Subject: Add a practical description of endian-independent RGB/BGR coding git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17681 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/tech/colorspaces.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'DOCS/tech/colorspaces.txt') diff --git a/DOCS/tech/colorspaces.txt b/DOCS/tech/colorspaces.txt index f4a1f88c2a..dc00fd388d 100644 --- a/DOCS/tech/colorspaces.txt +++ b/DOCS/tech/colorspaces.txt @@ -135,3 +135,24 @@ that you actually get: Depending upon the CPU being little- or big-endian, different 'in memory' and 'in register' formats will be equal (LE -> BGRA == BGR32 / BE -> ARGB == BGR32) + +Practical coding guide: + +The 4, 8, 15, and 16 bit formats are defined so that the portable way to +access them is to load the pixel into an integer and use bitmasks. + +The 24 bit formats are defined so that the portable way to access them is +to address the 3 components as separate bytes, as in ((uint8_t *)pixel)[0], +((uint8_t *)pixel)[1], ((uint8_t *)pixel)[2]. + +When a 32-bit format is identified by the four characters A, R, G, and B in +some order, the portable way to access it is by addressing the 4 components +as separate bytes. + +When a 32-bit format is identified by the 3 characters R, G, and B in some +order followed by the number 32, the portable way to access it is to load +the pixel into an integer and use bitmasks. + +When the above portable access methods are not used, you will need to write +2 versions of your code, and use #ifdef WORDS_BIGENDIAN to choose the correct +one. -- cgit v1.2.3