[MPlayer-cvslog] CVS: main/postproc rgb2rgb_template.c,1.76,1.77

[Alan Curry]

Oded Shimon writes the following:
>
>On Fri, Feb 24, 2006 at 10:53:02AM +0100, Alan Curry CVS wrote:
>
>> -		const int src= *s; s += 4;
>> -		*d++ = ((src&0xF8)<<8) + ((src&0xFC00)>>5) + ((src&0xF80000)>>19);
>> +		register int rgb = *(uint32_t*)s; s += 4;
>> +		*d++ = ((rgb&0xF8)<<8) + ((rgb&0xFC00)>>5) + ((rgb&0xF80000)>>19);
>
>Is this endian safe?

I'm sure it is... I kept DOCS/tech/colorspaces.txt very close for every one
of these changes to rgb2rgb. Here's the condensed version of what I learned:

  The 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, #ifdef'ing is
  necessary.

The functions addressed in this commit involve formats identified as
{rgb,bgr}{15,16,32} and only use bitmasking, so the same code is good for
little-endian and big-endian.

By the way, how would you like the indented paragraphs above as an addition
to DOCS/tech/colorspaces.txt?