RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity

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
This commit is contained in:
pacman 2006-02-24 22:18:45 +00:00
parent 469dda5b0a
commit c8610ae9e2
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
DOCS/tech/colorspaces.txt
View File

@ -135,3 +135,24 @@ that you actually get:
Depending upon the CPU being little- or big-endian, different 'in memory' and 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) '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.