1

I used my implementation of 'resize.c' to recreate 'large.bmp' in a file called 'test.bmp' using 'small.bmp'. I used ./resize 4 small.bmp test.bmp. It looks as it should when viewed, but then I tried diff large.bmp test.bmp and the files differ.

So I opened them with a hexadecimal file editor, and I saw the bytes that differ where the value of "biSizeImage", member of "BITMAPINFOHEADER" is.

Since 'large.bmp' (and 'test.bmp') has dimensions 12x12, this value should be 12x12 = 144, so 0x90 in hexadecimal. That is true in 'test.bmp', but not in 'large.bmp', where it is 0x01b0, 432 in decimal. Which is weird since 432 doesn't mean anything...

Here's a screenshot, it's easier to understand what I mean.

weird large BMP

So I don't know, is there something I didn't understand here?

Improve this question

1 Answer 1

Reset to default
2

biSizeImage
Specifies the size, in bytes, of the image. This can be set to 0 for uncompressed RGB bitmaps. source: MSDN

So it's the size in bytes, not pixels. An hence 144*3 == 432 (since each pixel in 3 bytes and we have no padding because 12 is a multiple of 4).

Improve this answer
1
  • 1
    Great, got it, thank you :)
    – Aizen
    Commented Aug 21, 2016 at 18:29

You must log in to answer this question.

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