Reading a bitmap

I've read through heaps of posts and read up on the bitmap file type but I'm a little stuck with reading a bitmap.

So far I have read in the info header and the file header but what do I do about the rgbquad and bitmapbits?

They're both arrays so I'm a little confused about knowing how big they are and being able to read them.

Well, I haven't gotten as far as you... I'm still thinkin' about writing a bitmap program...

what do I do about the rgbquad and bitmapbits?

I suppose you save these in arrays. If there's compression, you probably need to de-compress, and store the actual pixel information in arrays.

about knowing how big they are and being able to read them.

I think you can calculate the size from the bitmapinfo structure which is supposed to have the dimensions. I looks like this can be tricky with optional compression, and all the other "options and ifs".

And, before you read-in the pixels, it think you need to get the bit-depth, so you know how many bytes to read per color.

I hope this "guessing" helps a little 'till you get some help form someone who really knows what they're talking about

Hi!

Well I think guessing is probably the best way to attack this problem at the momment.

So far I decided that it'll probably have to be something like:

Code:

RGBQUAD rgbq[x];

I have no idea what the x will be though.

[edit:] Heh, I'm right about that I just read the bmp documentation again "color table, defined as an array of RGBQUAD structures" ..

Now I was really confused because I wasn't getting the number of colors. This is because in a 24bit bitmap it doesn't get specified in the info header.

I think I have it figured out now. I'll just have a go now.

Well, seeing as I don't know what I'm doing I've done the following:

Code:

for(int i = 0;i < 32; i++)
{
 bmp.read((char*) &rgbq[i].rgbRed,1);
 bmp.read((char*) &rgbq[i].rgbGreen,1);
 bmp.read((char*) &rgbq[i].rgbBlue,1);
}

It does get data, I guess it's correct..

The bitmap format isn't quite that simple, in fact it isn't simple at all. Some have color tables, some don't, some use explicit color values, some use masks, some store the bits right after the header/table, some store them elsewhere in memory, some are stored upside down while others are right side up! Then there are the scan-line alignments to deal with, etc, etc, etc. This just isn't a good thing to be guessing at! (Unless of course you enjoy subjecting yourself to hours of frustration and confusion.) The best thing to do is to get a hold of the official bitmap specification, and go from there.

Yeah I know... I'm controlling the experiment. The bitmap uses 7 colors, tis 8 bits, has a color table and is upside down.

I have the headers, but I'm unsure about the color table and the bits.

That code I tried earlier was stupid, I don't need to do that, just read directly to the array without looping....i think .


I've read the specifications on bitmap. But it's a little hard without any examples.

Are you just assuming it uses 7 colors? The easiest way to calculate the number of entries in the color table is

int entries = biClrUsed ? biClrUsed : (int)pow(2, biBitCount);

At the end of the color table will be the bits, if the bitmap is 'packed' (which will obviously be the case if you're reading from a file). Then just keep in mind that:

a) The width of the bitmap will be padded if necessary to align it on a 4 byte boundary. So say the width of an 8 bit bitmap is 97 pixels. That means that every 97 bytes you will then skip/ignore 3 extra bytes of padding.
b) Each byte of the bitmap's bits will be an index into the color table, not actual rgb values.