[IPOL discuss] RGB->gray conversion and speed comparison

[Pascal Getreuer]

>> The only point to worry about is that the arithmetic requires integers
>> that are at least 24 bits.
>
> Where does this condition come from?

The operation
   6969 * R + 23434 * G + 2365 * B
where R, G, B are values between 0 to 255, has a maximum value of
8355840, so at least 23 bits are needed to represent this (I was
previously off by one bit).  It would be good to use 32-bit unsigned
integers (uint32_t) to do the arithmetic.

> Nowadays most modern machines use 2's complement to represent integer
> numbers, so 16384 will contain only one bit equal to one a the other set
> to zero.

It is true that not all architectures represent negative integers in
the same way, and the C standard does not guarantee signed integers to
be 2's complement.

But fortunately we can dodge this issue.  The RGB components and the
calculations are all with nonnegative values, and can be computed with
an unsigned integer type like uint32_t.  Unsigned integers are
represented consistently across platforms, except for endianness
(memory order), and as Nicolas said, bitshifts are not dependent on
this.

Best,
Pascal