How do you convert from one bpp to another? 16-bit to 24-bit to 32-bit and the other way around?

by scaling and aliasing the bits.

24bpp & 32bpp are identically, except the 32bit mode "listens" to that last 8bits as an alpha channel (tranparency). In 32bit mode you still "only" have 16million colors.
24bpp color uses 32bpp storage (and ignores 8bits) for performance reasons.


you need to make 5->8 or 8->5
You could create a complicated system that attempts to fix the aliasing by twiddling the bits a little (dithering or blending), or just create a look-up table and blast through it if it needs to be fast.

Edited by - Magmai Kai Holmlor on November 25, 2000 3:10:53 AM

I still don''t understand

Do you know how the color bits are stored?

if you''re going from a 5.5.5.x to a 8.8.8.x you could multiply the rgb values in the 5.5.5 format by 8/5 and store it in the 8.8.8 pixel. You could also create a looup table, since there are only 5 possiblities, and 5 outcomes.

Going from 8.8.8.x to 5.5.5.x makes more sense, you would not want to do the opposite unless you absolutely had to. Multiply each rgb value of the 8.8.8 pixel by 5/8 and store in the 5.5.5 pixel.

These operations are not fast, ie do once at load time.

How exactly is the colors bit stored?

Ok, look, color is stored in memory by a sequence of bits. 16 bit color is stored in 16-bits(thats 2 bytes) and can be in a 5-5-5 format(thats 5 bits for red, 5 bits for green, 5 bits for blue), or in a 5-6-5 format(5 bits for red, 6 bits for green, and 5 bits for blue). In their binary forms, they look like the following:

5-5-5 format

__Red__ _Green_ __Blue_
| | | | | |
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

5-6-5 format

__Red__ __Green__ __Blue_
| | | | | |
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Notice how in the 5-5-5 format, the first bit is ignored.



Now, as Magmai previously stated, 24 bit color is stored identically(ususally) to the 32 bit color, except that in 24 bit color, the last 8 bits are ignored. In 32 bit color, those last 8 bits are interpreted as an alpha value. Don''t worry about that though.

And last but no least, in 256 color mode, colors are stored in 8 bits(1 byte) and the value in the byte is actually an index into a color palette.

Now, as for converting between modes 16 bit color and 24 bit and 32 bit, here are some macros:

// converts from 32bit mode to 16 bit 555 format
#define RGB32_TO_RGB16_555(r,g,b) ((br%32)|((g%32)<<5)|((r%32)<<10))

// converts from 32bit mode to 16 bit 565 format
#define RGB32_TO_RGB16_565(r,g,b) ((br%32)|((g%32)<<5)|((r%32)<<11))

If you want to build 24 bit or 32 bit color, just use the RGB macro, defined in the windows header files.

Hope that helped.

Implementation is everything. Period.
Particle Toast

Sorry, but the vertical characters I used in the description of color format''s got shifted in the display. Basically, they just segmented off the sections of 5-bits and 6-bits.

I''m really sorry, but could you explain the codes in the macros? I know it has to do with bit shifting...something.....

16bit colours are stored as
X RRRRR GGGGG BBBBB in 555 mode and
RRRRR GGGGGG BBBBB in 565 mode.
As you can see 555 uses 5 bits for each mode with one blank, and 565 uses 5 bits for red and blue, and 6 bits for green.
So with 5 bits, the maximum value is 32, and with 6 it's 64.
The macro first mods(%) the value with 32, which will divide the value by 32 and then give the remainder, effectively reducing the value to under 32, so it will fit in 5 bits. In 565 mode, green should be moded with 64, because green has 6 bits.

After the values have been reduced to fit in the new 16 bit value, they are shifted to the correct position.

If you don't understand shifting, read this:
------
Shifting involves moving the bits either to the left( << ), or to the right ( >> ).
You have to think in binary form for this .
E.g.:
A 16 bit number:
0000000000001101
This in binary represents 13 in decimal(1 * 1 + 0 * 2 + 1 * 4 + 1 * 8)
Now if you wanted to shift all these bits to look like this:
0000000000110100
You have to shift them to the left 2 places.
Like so:
MyVar = MyVar << 2;
Now the value is actually changed to give 52.
Shifting to the left by n is the equivilant of multiplying by 2^n (where ^ means power).
So anyway.. lets get on with it.
------

If you were to place the colours in a 16bit integer without shifting them to the correct position, they would overlap and it would look something like this:
Unused---Used
0 00000 00000 RRRRR
0 00000 00000 GGGGG
0 00000 00000 BBBBB
Now obviously this would result in a very screwed up colour
Now you need to shift it so it will look like it does in my diagram above:
X RRRRR GGGGG BBBBB or RRRRR GGGGGG BBBBB in 565 mode.
As you can see you will need to shift the bits to the left - but only red and green, blue needs to stay where it is
Nothing is done with blue, because it is already in the right position - to the right of the pixel.
For green, you need to shift it 5 bits to the left in 555, or 6 bits in 565. This is because in 565 the value takes up one extra bit, and if you didn't shift it 6 bits it would overwrite the blue bits. Now the pixel looks like this:
X XXXXX GGGGG BBBBB, or XXXXX GGGGGG BBBBB
And the red is still overlapping with the blue, so to speak.
So you need to shift the red bits into place. The principle is the same as the blue and green shifting.
For 555 you need to shift it 10 bits, so it looks like this:
X RRRRR GGGGG BBBBB.
For 565 you have to shift it one extra bit, because there is no unused bit at the start.
RRRRR GGGGGG BBBBB.

Geez...that's a lot in one go. Tell me if you don't understand anything.
Anyway, hope this helps



Edited by - Quantum on November 28, 2000 1:04:32 AM

Thanks a lot, but question...

let''s say you have one pixel, in linear memory, 16 bit would be something like:

RRRRRGGGGGGBBBBB or XRRRRRGGGGGBBBBB right?

Then what it is that is 3 lines as in:

Unused---Used
0 00000 00000 RRRRR
0 00000 00000 GGGGG
0 00000 00000 BBBBB

is that equivalent to:

0 00000 00000 RRRRR 0 00000 00000 GGGGG 0 00000 00000 BBBBB?