0

I am working with a Monochrome Bitmap image, 1 bit per pixel.

When I examine the file with an hexadecimal editor, I notice that each row ends up with the following hexadecimal sequence: f0 00 00 00.

Having studied the problem a little bit, I concluded that the three last bytes 00 00 00 correspond to the row padding.

Question 1:

I would like to know if the following algorithm to determine the number of padding bytes in case of a 1 bbp BMP image is correct:

if(((n_width % 32) == 0) || ((n_width % 32) > 24))
{
  n_nbPaddingBytes = 0;
}
else if((n_width % 32) <= 8)
{
  n_nbPaddingBytes = 3;
}
else if((n_width % 32) <= 16)
{
  n_nbPaddingBytes = 2;
}
else
{
  n_nbPaddingBytes = 1;
}

n_width is the width in pixels of the BMP image.

For example, if n_width = 100 px then n_nbPaddingBytes = 3.

Question 2:

Apart from the padding (00 00 00), I have this F0 byte preceding the three bytes padding on every row. It results in a black vertical line of 4 pixels on the right side of the image.

Note 1: I am manipulating the image prior to printing it on a Zebra printer (I am flipping the image vertically and reverting the colors: basically a black pixel becomes a white one and vice versa).

Note 2: When I open the original BMP image with Paint, it has no such black vertical line on its right side.

Is there any reason why this byte 0xF0 is present at the end of each row?

Thank you for helping. Best regards.

Léa Massiot
  • 1,928
  • 6
  • 25
  • 43

1 Answers1

1

The bits representing the bitmap pixels are packed in rows. The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding.

RowSize = [(BitsPerPixel * ImageWidth + 31) / 32] * 4 (division is integer)

(BMP file format)

Monochrome image with width = 100 has line size 16 bytes (128 bits), so 3.5 bytes serve for padding (second nibble of F0 and 00 00 00). F represents right 4 columns of image (white for usual 0/1 palette).

MBo
  • 77,366
  • 5
  • 53
  • 86
  • Thank you for your answer. Really? The number of bytes for padding can be a float? So I guess the algorithm I am proposing is not correct, is it? – Léa Massiot Apr 02 '15 at 11:03
  • 1
    No, I count effective padding bytes - your 100 pixels occupy 100 bits = 12 1/2 bytes, so I wrote about 3.5 – MBo Apr 02 '15 at 11:09
  • The bytes per row may be calculated like this: `(((biWidth + 31) & ~31) >> 3)` for a monochrome bitmap. Adapted from [here](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapinfoheader#calculating-surface-stride) (see _stride_). – urbanSoft Jan 13 '21 at 09:41
  • @urbanSoft Gives the same result – MBo Jan 13 '21 at 11:39
  • @MBo I have not claimed otherwise. :) Just another function I stumbled across because at the moment I'm dealing with the same subject. – urbanSoft Jan 14 '21 at 14:10