Hi Guys,
I don't know how many ppl here would have bothered with making their own routines
to manipulate or display bitmaps, but I've been doing a bit of it recently with
8 bit, 16 bit (RGB565), and 24 bit images, and conversion from one to another.

Aside from the fact that information for each pixel is stored in a way that requires
you to read the file from the end to rotate it 180 degrees, and then flip the
image horizontally to arrange it how it's meant to be viewed, I've noticed a
peculiarity with images of some dimensions which I think I've narrowed down
to being any case where one of the dimensions is an odd number.

take 146x133 for example.

Create a black bitmap image of those dimensions, and you'd think every byte
after the header would be 0x00. This is not the case though.
The last two bytes in the file are 0xFF, and every 138 bytes from there will
be another pair of 0xFF bytes that have nothing to do with the image.

If the image dimensions are different again, there may only be single bytes scattered throughout.
I've solved this for my application. Since it works with expected image dimensions,
I can copy from one buffer to another, skipping the locations containing the 0xFF bytes.

I wondered if anyone can explain this though?
Cheers, Art.

 

Are they just padding it to be a multiple of 32-bits? This might make moving to/from memory easier (faster) than having to keep track of half-word pointers.

 

Check the specification for Microsoft .BMP formats, they pad the end of each pixel LINE to the 4byte boundary as it was standard for microsoft to use 32bit variables in their apps.

It's a real annoyance reading bitmaps, best to do it looping in pixel lines. The header gives the pixel line width so you have to allow the modulus4 to pad. Just another example of bad microsoft judgement.