Thread: Programming with the bitmap file format

I'm not sure if this is the right place to ask this but I couldn't think of anywhere else.

I'm writing an app where I'm wanting to convert raw byte data into bitmaps. I did a bit of reading about the bitmap file format before I attempted writing this and I've created an app which spits out the two headers required, the palette (I'm converting the data into an 8bit image with an indexed palette) and then the data. Because it's 8bpp I can just write the raw data out, with one exception. Every scan line in a bitmap needs to be divisible by 4 bytes (32 bits). So I just mod the width of the image by four and then stick on that many zeros at the end of each line.

This works absolutely perfectly for images whos width is an even number. But as soon as I try and give it an image with an odd numbered width it doesn't work. The image in question is 17 pixels by 9 pixels. So my app sticks a single byte on the end of each row to top it up to 18, which I would imaging was correct. Everything seems to be correct when I read in the converted image in a hex editor. The headers are correct and the data seems correct in that it's exactly the same as the raw data except it has an extra byte after every 17 pixels.

I've spent ages trying to find out what the problem is and in the end I opened the raw data in paint shop pro and saved it out as an 8bpp bitmap with the correct palette and analysed this in my hex editor. Now, it seems that PSP sticks THREE bytes on the end of each row, instead of one. Why on earth does it do this? I've read numerous articles on the BMP file format and I can't find out why this is so but I think this could be part of my problem.

Does anyone have any idea?

The actual file data block has to be a division or multiple of 4.

Originally Posted by kryptkat

The actual file data block has to be a division or multiple of 4.

Really? I haven't read that anywhere.

So, currently the data block in my image is 17 (+1) x 9 pixels which makes it 162 pixels. Does this mean I could get away with just modding 162 by four and then adding the two bytes at the end of the file or (as I imagine) would it have to be a more elegant solution?

Originally Posted by Salem

Each row is padded to align it to a 4-byte boundary.

Yeah, that's what I'm already doing as I mentioned in the original post

Originally Posted by Salem

So what's your question?

I'm asking what I could be missing from my interpretation of the bitmap file format. I've followed the documents I could find on the Internet and I appear to be following them to the T but I'm obviously missing something as if I try to build a bitmap from the raw data of an image whos width is odd it doesn't get built correctly.

As mentioned in the first post, my app converted the raw data of an image whos dimensions were 17x9, so I added a single byte to the end of every line to make it divisible by four but this didn't seem to produce a correct bitmap. When I loaded this raw data into paint shop pro and told it to save the data it stuck three bytes on the end of each line, which doesn't make sense to me.....

Right, I'm going to leave all the above there just so everyone knows what an idiot I am. Please excuse my stupidity but I've had a few whisky's whilst coding tonight and somehow I thought that 18 was divisible by four

Rest assured, the proverbial egg on my face is plentiful.