24, 16 and 8 bit bimaps
Author
I know for 24 bit bitmaps, for each pixel we have a byte for R,G and B- and so it's easy to read in.
So for 16 and 8 bit bitmaps how much is each RGB value in bits and where can I found them in the bitmap ?
(eg for a 24 bit bitmap I simply read the R,G,B byte values in turn and store them as a byte for each)
cheers
16 bit surfaces are packed
A1 R5 G5 B5
However, some packages dont use alpha at all, and give you
R5 G6 B5
This is understandably great fun to work with.
It would be more useful to read in each value and store them as a 24bit surface, if you plan to manipulate it.
A1 R5 G5 B5
However, some packages dont use alpha at all, and give you
R5 G6 B5
This is understandably great fun to work with.
It would be more useful to read in each value and store them as a 24bit surface, if you plan to manipulate it.
Author
err, was that sarcasm ..
(got to make sure in case I make all my textures 16 bit !)
(got to make sure in case I make all my textures 16 bit !)
You could use a set of bitwise operations to get each colour component, if you are using the images for texturing, does your rendering system not convert textures to be compatible with the display format anyway?
If you are not planning to manipulate them, let the system do the work, if you want to alter them then usually your system will provide access functions and handle the complexity for you.
If you are not planning to manipulate them, let the system do the work, if you want to alter them then usually your system will provide access functions and handle the complexity for you.
By far the most common 16 bit format these days is 565 rgb with 6 bits for the green channel, because the human eye is more sensitive the green light, or so I've read.
What I did when working with 16 bit formats was to store the images as 16bit 565, and then shift the green channel right one bit when loading the image if I'm in 555 mode.
There are other 16 bit modes too, A1 R5 G5 B5 and R5 G6 B5 are the most common, but there are other weird formats, so you might want to query the graphics hardware and get the bitmasks fior each color channel manually.
8bit is much more easy to work with though, each palette entry is R8 G8 B8 8 bits per channel, but you can only show 256 of those colors at once. That's what palettes are for.
What I did when working with 16 bit formats was to store the images as 16bit 565, and then shift the green channel right one bit when loading the image if I'm in 555 mode.
There are other 16 bit modes too, A1 R5 G5 B5 and R5 G6 B5 are the most common, but there are other weird formats, so you might want to query the graphics hardware and get the bitmasks fior each color channel manually.
8bit is much more easy to work with though, each palette entry is R8 G8 B8 8 bits per channel, but you can only show 256 of those colors at once. That's what palettes are for.
Ok, here it is. I have a very robust bmp file loader (supporting version 4 and version 5 bitmap files, with alpha blending and everything) and if you'd like to look at my code that would be fine.
Anyways, for 16 and 32 bit images, you can have a compression identifier of either BI_RGB or BI_BITFIELDS. If the identifier is BI_RGB you have an RGB image that is encoded as follows:
16-bit: X1R5G5B5
32-bit: X8R8G8G8
If the compression identifier is set to BI_BITFIELDS, you have have two possibilities. If the infoheader size == 40, you have a version 3 or below bitmap, and that means in the area where the palette is normally stored you have three bitmasks (red, green and blue). The masks are 16 bits in length if it's a 16 bit image, and 32 bits in length if it's a 32. If the infoheader.size is > 40, then you have a version 4 or a version 5 bitmap, and the red, green and blue mask are part of the header (check msdn for BMPV4InfoHeader and BMPV4InfoHeader or whatever it is). At any rate, once you get past this, you have to ascertain if it's an alpha image (just check if InfoHeader.size > 40 && InfoHeader.AlphaMask != 0). After that you have to figure out how far to rshift the images once the mask is applied, and then lshift it back up to align it with 8-bits again.
Now that that part is over, for 8 bits, it can be saved as BI_RGB , in which case you load a color palette, and then each area of the color data is an 8-bit index into the palette rather than a color itself, or it can be RLE encoded (I won't explain the algorithm here, though it's very simple) in which case you still have a color palette, but you must first get the data from the encoded area for the indexes.
4-bit images are the same as 8, except for BI_RGB each index is a 4-bit number, and the RLE algorithm is slightly different.
1-bit images only come in BI_RGB, and each bit is an index into the color palette which has exactly two colors.
24-bit (as you said) is in basic RGB format.
I've currently tested my implementation with the following formats. It was about 800 lines of code to get it working. I'll give you the code if you want:
1-bit RGB
1-bit RGB Top-Down
4-bit RGB
4-bit RGB Top-Down
4-bit RLE
4-bit RLE Top-Down (supposedly illegal, but photoshop 7 saves in this format, and it works)
8-bit RGB
8-bit RGB Top-Down
8-bit RLE
8-bit RLE Top-Down (supposedly illegal, but photoshop 7 saves in this format, and it works)
16-bit X1R5G5B5
16-bit X1R5G5B5 Top-Down
16-bit A1R5G5B5
16-bit A1R5G5B5 Top-Down
16-bit R5G6B5
16-bit R5G6B5 Top-Down
16-bit A4R4G4B4
16-bit A4R4G4B4 Top-Down
24-bit R8G8B8
24-bit R8G8B8 Top-Down
32-bit X8R8G8B8
32-bit X8R8G8B8 Top-Down
32-bit A8R8G8B8
32-bit A8R8G8B8 Top-Down
Anyways, for 16 and 32 bit images, you can have a compression identifier of either BI_RGB or BI_BITFIELDS. If the identifier is BI_RGB you have an RGB image that is encoded as follows:
16-bit: X1R5G5B5
32-bit: X8R8G8G8
If the compression identifier is set to BI_BITFIELDS, you have have two possibilities. If the infoheader size == 40, you have a version 3 or below bitmap, and that means in the area where the palette is normally stored you have three bitmasks (red, green and blue). The masks are 16 bits in length if it's a 16 bit image, and 32 bits in length if it's a 32. If the infoheader.size is > 40, then you have a version 4 or a version 5 bitmap, and the red, green and blue mask are part of the header (check msdn for BMPV4InfoHeader and BMPV4InfoHeader or whatever it is). At any rate, once you get past this, you have to ascertain if it's an alpha image (just check if InfoHeader.size > 40 && InfoHeader.AlphaMask != 0). After that you have to figure out how far to rshift the images once the mask is applied, and then lshift it back up to align it with 8-bits again.
Now that that part is over, for 8 bits, it can be saved as BI_RGB , in which case you load a color palette, and then each area of the color data is an 8-bit index into the palette rather than a color itself, or it can be RLE encoded (I won't explain the algorithm here, though it's very simple) in which case you still have a color palette, but you must first get the data from the encoded area for the indexes.
4-bit images are the same as 8, except for BI_RGB each index is a 4-bit number, and the RLE algorithm is slightly different.
1-bit images only come in BI_RGB, and each bit is an index into the color palette which has exactly two colors.
24-bit (as you said) is in basic RGB format.
I've currently tested my implementation with the following formats. It was about 800 lines of code to get it working. I'll give you the code if you want:
1-bit RGB
1-bit RGB Top-Down
4-bit RGB
4-bit RGB Top-Down
4-bit RLE
4-bit RLE Top-Down (supposedly illegal, but photoshop 7 saves in this format, and it works)
8-bit RGB
8-bit RGB Top-Down
8-bit RLE
8-bit RLE Top-Down (supposedly illegal, but photoshop 7 saves in this format, and it works)
16-bit X1R5G5B5
16-bit X1R5G5B5 Top-Down
16-bit A1R5G5B5
16-bit A1R5G5B5 Top-Down
16-bit R5G6B5
16-bit R5G6B5 Top-Down
16-bit A4R4G4B4
16-bit A4R4G4B4 Top-Down
24-bit R8G8B8
24-bit R8G8B8 Top-Down
32-bit X8R8G8B8
32-bit X8R8G8B8 Top-Down
32-bit A8R8G8B8
32-bit A8R8G8B8 Top-Down
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement