1

is the check50 report for my code :

jharvard@appliance (~/Dropbox/pset5/bmp): check50 2014/x/pset5/resize bmp.h resize.c
:) resize.c and bmp.h exist
:) resize.c compiles
:( doesn't resize 1x1-pixel BMP when n is 1
:( resizes 1x1-pixel BMP to 2x2 correctly when n is 2
:( resizes 1x1-pixel BMP to 3x3 correctly when n is 3
:) resizes 1x1-pixel BMP to 4x4 correctly when n is 4
:( resizes 1x1-pixel BMP to 5x5 correctly when n is 5
:) resizes 2x2-pixel BMP to 4x4 correctly when n is 2

Strangely, check50 displays a frown despite saying that images have been resized correctly. I thought there might be something wrong with my padding. So I ran a test on small.bmp to see if my output was being padded correctly for images where no. of scanline bytes were indivisible by 4 :

./resize 5 small.bmp enlarged.bmp
xxd -c 48 -g 3 -s 54 enlarged.bmp

Output :

http://pastebin.com/ciZzCwR1

The 000000 at the beginning of every other line is the padding and hence removes any doubts about it.

Here is my code : http://pastebin.com/kFuM2eMU

Please tell me what is going wrong!

1
  • I have exact same problem (not looking into your code). Thank you for raising the concern. Oct 8 '15 at 5:00
4

It's the fact that your biSizeImage calculation is not correct, so whenever there is padding, you get the wrong value in your header

bi.biSizeImage = ((bi.biWidth)* abs(bi.biHeight) * sizeof(RGBTRIPLE)) + paddingOutfile;

For example, a 5x5 bitmap should have 1 byte of padding, using your calculation:

(5*5*3) + 1 =  76

But biSizeImage should be the number of pixels+padding per line times the number of lines.

each line has 5 pixels = 15 bytes + 1 byte of padding = 16
5 lines of 16 = 80 bytes, so biSizeImage is 80.
1
  • Thanks a lot! I had been running the ~cs50/pset5/peek command on smiley.bmp which never had any padding and so never displayed any discrepancy in header details output.
    – user1580
    Sep 28 '14 at 9:13

You must log in to answer this question.

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