0

biImageSize is 2 bytes larger than expected

The data is from clue.gmb run by copy

Why is biSizeImage and bfSize 2 bytes larger than expected? Is this an inherent property of bitmap images that I'm not aware of, or is something else going on? This would be handy to know before I start manipulating it.

What was expected was biWidth x biHeight x 3

biSizeImage= 921600

+54

bfSize = 921654

Improve this question

1 Answer 1

Reset to default
0

Something else is going on. It's because you've forgotten one thing in your calculation and added another.

First of all, the 54 bytes for the header are not included in bi.SizeImage.

Second, you didn't account for the padding on each line.

Edit: as discussed in comments, this particular case has a padding value of 0. However, you still need to account for padding when not 0. Also, there appears to be an error in the bi.SizeImage value in the file of +2.

If this answers your question, please accept the answer. This removes the question from the unanswered question pool. Let's keep up on forum housekeeping. ;-)

Improve this answer
5
  • But biWidth, biHeight and biSizeImage are divisible by 4 which should negate the need for buffers or padding that are required to meet that condition, no? Is it possible there's extra data in the file not in the first 54 bytes or the bitmap itself or something else I'm missing? Also, I was adding the 54 bytes to biSizeImage to get the bfSize, I didnt want to leave anything out.
    – Gibb Johnson
    Jun 10, 2015 at 21:55
  • No, they are not necesssarily divisible by 4. Both can be any number. bi.Width is the number of pixels in a row. A pixel is 3 bytes. bi.Height is the number of rows in the image. The image size is height * size of rows in bytes. A row is the number of pixels * the size of a pixel (RGBTRIPLE), plus the padding on the end of a row. Remember, the purpose of the padding is to make the length of the row equal to a multiple of 4. (probably something to do with early graphics hardware.) If you still don't understand it, you should really go back and review the class material and assignment.
    – Cliff B
    Jun 10, 2015 at 22:14
  • In this specific instance the row pixel width 640 is a multiple of 4, as is its length in bytes 1920. I know it says that if the items are not a multiple of 4 then a buffer or padding ( between 0 and 3 of them) is required to make It a multiple of 4. I read it over again but I don't see what's missing.
    – Gibb Johnson
    Jun 10, 2015 at 22:29
  • I think you're stuck on comparing/confusing pixels and bytes. The bi.Height and bi.Width are the number of pixels in the image. bi.SizeImage is the measure of bytes in the image portion of the file. So, first, you have to figure out how many bytes per row of pixels. That's the number of pixels (bi.Width) times the size of a pixel ( sizeof(RGBTRIPLE), or 3) and then add the padding, which can be anything from 0 to 3. All that gives you the size of a row in bytes. Now, you just have to multiply by the number of rows, or bi.Height.
    – Cliff B
    Jun 10, 2015 at 22:39
  • Seeing that you were looking at clue.bmp, I just went back and did the manual calculations myself. Guess what. The value stored in the header for bi.SizeImage looks like it is wrong. In fact, it's off by +2. Of course, if anyone can explain this, or prove me wrong, please do. You're right about one thing. In this case, there is no padding. So, it's simply bi.Height * bi.Width * 3. No header of 54, and padding = 0. See edit in my answer.
    – Cliff B
    Jun 10, 2015 at 23:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .