I’m working on scanning application at a low level where I’m not very comfortable already 🙂
Anyway, I’m trying to make sense out of numbers I’m getting.
Here we go:
- Scanning Letter size document with 200 DPI, B/W
- Resolutions comes up to 1700×2200
- I calculate 1700×2200 = 3740000 bits OR 467500 bytes
- When I get BITMAPINFOHEADER it says biSizeImage = 475200. WHY?
- Code snippet that I use to return byte array with BITMAP returns 475248 bytes which is 48 bytes more. But biSize says 40, so if header is 40, than why 48 bytes in front of image data?
Basically, I do not understand why difference between calculated 467500 and 475200 that’s in BITMAPHEADER?
I also do not understand why header says it is 40 bytes but in reality it is 48? I’m just guessing it’s 8 bytes for color infor? Because image is 2 color (B/W) – it uses 4 bytes per each color?
EDIT
Here is info:

I think I get it. When scanned line saved in memory it have to be in pack of 4 bytes.
So, according to my calculations 1700 bits is 212.5 bytes and according to what I see – it uses 216 bytes. So, it kind of makes sense.
BITMAPINFOHEADERreally is 40 bytes in size. Keep in mind that a bitmap is represented by aBITMAPINFOstruct, not aBITMAPINFOHEADERstruct by itself.BITMAPINFOcontains an optionalRGBQUADcolor palette immediately after theBITMAPINFOHEADERstruct.1700×2200 would be 3740000 pixels, which would take up 467500 bytes as the bitmap is using 1-bit pixels, ie it is a monochrome bitmap. Your bitmap has an extra 8 bytes in between the header and pixel data, with is consistent with a monochrome bitmap as the color palette would contain 2
RGBQUADvalues. You have to take theBITMAPINFOHEADER::biBitCountfield into account, as it tells you how many bits are actually used per pixel and how the color palette is used.The additional bytes are accounted for by each scanline being padded at the end to align on
DWORDboundaries.biSizeImageis calculated in this situation as: