[MPlayer-dev-eng] RGB vs. BGR

[Michael Niedermayer]

Hi

On Wednesday 28 January 2004 12:06, Alex Beregszaszi wrote:
> Hi,
>
> imho it doesn't make sense to what std we are conforming to, we should
> only settle to one decision and document it to avoid misinterpretations
agree

>
> > arpi, please fill the following tables :)
> > memory order:		name: (big/little endian if different)
> > RGBA			???32
>
> RGB32
>
> > ARGB			???32
>
> Good question (btw, QT Zygo uses this)
>
> > BGRA			???32
>
> BGR32
>
> > ABGR			???32
>
> Good question again
>
> > RGB			???24
>
> RGB24
>
> > BGR			???24
>
> BGR24
>
> > order in an int		name: (big/little endian if different)
> > mostsignifant .. least significant bit
> > 8A8R8G8B		???32
>
> Dunno
>
> > 8A8B8G8R		???32
>
> Dunno (BGR32 would be 8B8G8R8A according to the first table)
>
> > 8R8G8B			???24
>
> RGB24
>
> > 8B8G8R			???24
>
> BGR24
>
> > 5R6G5B			???16
>
> RGB16
>
> > 5B6G5R			???16
>
> BGR16
>
> > 1A5R5G5B		???15
>
> RGB15
>
> > 1A5B5G5R		???15
>
> BGR15
ok

also maybe a BGRA32_ME/RGBA32_ME (BGRA order in machine endian / read as 
int32_t)/...
which is #defined to BGR/RGB depending upon WORDS_BIGENDIAN could be added, it 
would simplify code which accesses RGB/BGR32 as int instead of bytewise
based on that we could also use RGB15/16_ME instead of plain RGB15/16 it would 
be more consistant and harder to missunderstand, and would allow us to 
cleanly add support for byteswaped 15/16 bit formats in the future, IIRC 4xm 
on bigendian would use such a format internally

for the A possition we could use IMGFMT_RGB|32 vs. IMGFMT_RGB|32|64 or maybe 
add a IMGFMT_ARGB= 'ARBx' / IMGFMT_RGBA= 'RBAx' / ...

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en