cs50x pset4 resize

Question

Something's wrong here. Check50 doesn't like files that look fine to me.

Here's my command line:

jharvard@appliance (~/cs50x/pset4/bmp): ./resize 5 singleton.bmp qw.bmp

Here's what check50 says:

:) 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

There's no single pixel file available, as far as I can tell, so I built myself a single pixel file.

Here's what xxd says about my single pixel file:
(The pixel is 0x30, 0x40, and 0xff so I can see what's going on.)

jharvard@appliance (~/cs50x/pset4/bmp): xxd -c 16 -g 3 -s 54 singleton.bmp
0000036: 3040ff 00 0@..

Here's what xxd says about my resize's resize to 5:

jharvard@appliance (~/cs50x/pset4/bmp): xxd -c 16 -g 3 -s 54 qw.bmp
0000036: 3040ff 3040ff 3040ff 3040ff 3040ff 00 [email protected]@[email protected]@.0@..
0000046: 3040ff 3040ff 3040ff 3040ff 3040ff 00 [email protected]@[email protected]@.0@..
0000056: 3040ff 3040ff 3040ff 3040ff 3040ff 00 [email protected]@[email protected]@.0@..
0000066: 3040ff 3040ff 3040ff 3040ff 3040ff 00 [email protected]@[email protected]@.0@..
0000076: 3040ff 3040ff 3040ff 3040ff 3040ff 00 [email protected]@[email protected]@.0@..

Here are the structs I built just to keep everything in one place:
(With hints to myself.)

inFile at line 272:
InOutFile:
filePtr: 0x8cfe018 - never NULL
File name: singleton.bmp
Padding: 1 - (0..3 - bytes)
LineLength: 4
ResizeFactor: 5

BITMAPFILEHEADER:
     bfType: 19778 - always 'BM' or 'MB'
     bfSize: 58 - File size in bytes
bfReserved1: 0 - always zero
bfReserved2: 0 - see above
  bfOffBits: 54 - offset to pixels (54 in CS50)

BITMAPINFOHEADER:
         biSize: 40 - bytes in this header
        biWidth: 1 - image width in pixels
       biHeight: 1 - image height in pixels (aka 'lines')
       biPlanes: 1 - always 1
     biBitCount: 24 - bits per pixel
  biCompression: 0 - no compression -- always zero
    biSizeImage: 4 - size of image in bytes (including padding)
biXPelsPerMeter: 2834 - unreliable
biYPelsPerMeter: 2834 - unreliable
      biClrUsed: 0 - dunno, always zero.
 biClrImportant: 0 - see above

outFile at line 274:
InOutFile:
filePtr: 0x8cfe180 - never NULL
File name: qw.bmp
Padding: 1 - (0..3 - bytes)
LineLength: 16
ResizeFactor: 5

BITMAPFILEHEADER:
     bfType: 19778 - always 'BM' or 'MB'
     bfSize: 134 - File size in bytes
bfReserved1: 0 - always zero
bfReserved2: 0 - see above
  bfOffBits: 54 - offset to pixels (54 in CS50)

BITMAPINFOHEADER:
         biSize: 40 - bytes in this header
        biWidth: 5 - image width in pixels
       biHeight: 5 - image height in pixels (aka 'lines')
       biPlanes: 1 - always 1
     biBitCount: 24 - bits per pixel
  biCompression: 0 - no compression -- always zero
    biSizeImage: 80 - size of image in bytes (including padding)
biXPelsPerMeter: 2834 - unreliable
biYPelsPerMeter: 2834 - unreliable
      biClrUsed: 0 - dunno, always zero.
 biClrImportant: 0 - see above

Here are the file sizes, according to Ubuntu:

jharvard@appliance (~/cs50x/pset4/bmp): ls -lh singleton.bmp
-rw------- 1 jharvard students 58 Apr 2 14:27 singleton.bmp
jharvard@appliance (~/cs50x/pset4/bmp): ls -lh qw.bmp
-rw------- 1 jharvard students 134 Apr 2 15:17 qw.bmp

I can see nothing wrong in anything. Id sure appreciate it if someone could tell me what's wrong...

Answer 1

I had a very similar problem, and it looks like you have two issues. The big problem is with all of the results where n>1. I discovered that when the generated bitmap is correct but the header info generated is wrong, you get the results you have here. Run the staff version of the program and compare your headers to theirs for the same value of n. BTW, they plan to improve the results generated by CHECK50 at a later date. For more, check my previous question at

check50 gives confusing results for pset4 resize

The other issue is that the output says you're not resizing correctly when n is 1. In other words, you're supposed to be generating an output file identical to the original. It may be the same issue, a bad header.

Without seeing any of the code you use to generate the headers though, it's a bit difficult to see exactly what the problem is. I suspect that since you say the n=1 output file generates a correct image that you likely also have header issues there.

Fix your header generating code and most, if not all of the bad results should disappear.

Answer 2

Answer--

It is vital to skip over padding when reading the inFile.

Thanks for the suggestion, but things that looked the same to me and a few debugging tools, weren't...

My resize was making bad images because it wasn't handling inFile padding correctly. Check50 is happy now.

A possibly useful test:
Resize small.bmp 4 times, diff the output file and large.bmp, and keep futzing until diff says they're identical.