Bitmaps (without api support)

I have some functions that read, write, and display bitmaps. My problem is that I can't seem to get the padding right for 16 color bitmaps. I first tried calculating with (4-width%4) & 3. However, this fails sometimes. I'm not sure whether my algorithm is wrong or what else it could be. Suggestions?

I would guess a single byte encodes two pixels, where the lower 4 bits represent a pixel, and the higher 4 bits represent a neighbour pixel. I would guess neighbouring pixels would scan horizontally, rather than vertically. A 4 bit pixel value is likely to reference a 16 colour pallete, rather than an RGB value.

Of course I'm just guessing, but I would suggest the following in order:

1. See what you can dig out on 16 colour bitmap formats from a google search.

2. Create a tiny two pixel 16 colour bitmap using Paintshop Pro or something, where one pixel is black and the other is white. Open the file using a binary viewer and see if you can make sense of the numbers. TextPad (www.textpad.com) will do this for you.

3. Create a small 4 x 4 pixel bitmap, where each pixel is a different colour. Test your code this.

For the record you are pretty accurate about the format. I'm not sure if lower nibble holds data for the next scan line. I'm pretty sure the format is:

scanline 1:
[hibyte][lobyte][hibyte][lobyte][hibyte][lobyte][offset]
scanline 2:
[hibyte][lobyte][hibyte][lobyte][hibyte][lobyte][offset]
...

And it is safe to assume that I am correct since I can decode most bitmaps. It seems that my offsets are usually off when the width is 5 less than a power of 2. In this situation I have found that if the offset is 5 the bitmap displays correctly. Of course I have an if statement to take care of this situation however, I was wondering if I was calculating the offset incorrectly.

paddedwidth = ((bytewidth>>2)+((bytewidth&3)?1:0))<<2;

how's that for fun and exciting code?

Yeah that code is pretty exciting. But it still doesn't work for the situation where the width is 5 less than a power of 2. Right now I have a for loop in my code that checks for for this situation. It isn't that expensive an operation it would just be nice if I can have a small algorithm take care of this exception without looping through powers of 2.

Originally posted by master5001
Yeah that code is pretty exciting. But it still doesn't work for the situation where the width is 5 less than a power of 2. Right now I have a for loop in my code that checks for for this situation. It isn't that expensive an operation it would just be nice if I can have a small algorithm take care of this exception without looping through powers of 2.

yes it does. perhaps your bytewidth is not correct? Let's test it shall we? a power of 2... how about 64. 5 less = 59

paddedwidth = ((59>>2)+((59&3)?1:0))<<2;

paddedwidth = (14+(1))<<2;

paddedwidth = 15<<2;

paddedwidth = 60;

bytewidth % 4 = 3
paddedwidth % 4 = 0

see? It is clearly correct. something else is wrong

davros makes a good point about the 4 bit per pixel possibility. You should try both ways. bytewidth could be width/2 in 16 color. I would suspect that is not the case but see what happens.

Hershlag, I totally agree with your logic. This is why it is in fact a problem. I'm not just making up the exception to the rule. Beside I'm reading bitmaps, not writing them. If someone's calculations aren't right then it has to be paint brush's, gimp's, and photoshop's. If you don't believe me then make your own 4bit bitmap reader and you will find the same problem.

Master5001, I took the liberty of creating a 16 color bmp in ms paint and opened it in a hex editor. It is just as we suspected. padded edge as the others are. So that part is correct. The pixels are each 4 bits so we were right about that too. I want to take a wild guess on this. There is a possibility that would screw up your "bytewidth". Imagine your width is 5.

bytewidth = width / 2

would be wrong. integer math would knock off a byte. I bet you anything that's it!

try bytewidth = width/2 + (width&1)

if that's not it, something is really screwed up cause my tour of the format shows nothing unusual

Try this formula

pitch = (( width * bpp + (bpp-1) ) & ~(bpp-1) ) >> 3;

I guess the original algorithm that I had tried was just missing something For those interested I'm using offset = (4-((w>>1)+(w&1))%4) & 3. And Hershlag, I'm sorry for saying you were wrong when you were right from the beginning, we just overlooked the 16bit padding issue. Thanks for the help everyone!

don't apologize to me. you're one of the first civilized people I've had dialog with on this board. Glad you got your problem fixed.