On Fri, 19 Apr 2002, Herbert Voss wrote:
> I want to understand, so please give an answer to this:
>
> r/g or b has a range from 00000000 to 11111111 or only 6 bits
> for some graphic cards.
> converting to for example 4 bit could'nt only take the significant
> nibble ...
Assume you have the color encoded in 15 bits like this:
Bit 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01
NA r4 r3 r2 r1 r0 g4 g3 g2 g1 g0 b4 b3 b2 b1 b0
and you want to reduce this to 4 bits, you would do this:
Bit 04 03 02 01
NA r4 g4 b4
Why? Because you want the most significant bit for each color,
because this bit contains the most information about the color.
It is important to realize that just because we encode the
color in one word like we do it above, the information is really a
triple: The red color component is a 4-bit number, the green color is
a 4-bit number, and the blue color is a 4-bit number. Each is
separate, and we could express like it something like this:
struct RGB {
unsigned int red:4;
unsigned int green:4;
unsigned int blue:4;
}
When you quantify the color, you should treat each color
component separately, and take the most significant bits
for each.
If we would use all the available information in the 4 bits,
we would use one extra bit for the green channel and do this:
Bit 04 03 02 01
r4 g4 g3 b4
Once again, we want the most significant bits. (There is a good
reason to prefer the green bits rather than the others, but that's
a separate story.)
If we would quantify to 8 bits, we would do this:
Bit 08 07 06 05 04 03 02 01
r4 r3 g4 g3 g2 b4 b3 b2
Note that the encoding of the color is given in advance,
and we treat each color channel separately.
Now, if we wanted to do better, we would round according to the
next omitted bit.
Also, if we want to expand the color space to more bits, we
would just fill in zeros, because we do not have the extra information
to put into the new bits available.
I hope this clears things up a bit.
Greets,
Asger
