0

In my solution biSize and biSizeImage are correct. Checking the headers and the data in the BMP shows correct re-sizing for n = 1, 2, 3, 4, ... Check50 returns:

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

Also images display correctly in Image Viewer and in the application Pixelformer.

I think check50 is broken. Happy to shar my code if I knew how to do it :(

    jharvard@appliance (~/Dropbox/pset4/bmp): ./resize 2 2by2.bmp staff.bmp
    jharvard@appliance (~/Dropbox/pset4/bmp): ./resize 2 2by2.bmp student.bmp
    jharvard@appliance (~/Dropbox/pset4/bmp): ./bmpinsp staff.bmp

BITMAPFILEHEADER  <--> Filename = staff.bmp
bfType = 19778, bfSize = 102,  bfReserved1 = 0,  bfReserved2 = 0,  bfOffBits = 54

BITMAPINFOHEADER  <--> Filename = staff.bmp
biSize = 40, biWidth = 4,  biHeight = -4,  biPlanes = 1,  biBitCount = 24, biCompression = 0
biSizeImage = 48,  biXPelsPerMeter = 2834, biYPelsPerMeter = 2834
biClrUsed = 0,  biClrImportant = 0

jharvard@appliance (~/Dropbox/pset4/bmp): ./bmpinsp student.bmp

BITMAPFILEHEADER  <--> Filename = student.bmp
bfType = 19778, bfSize = 102,  bfReserved1 = 0,  bfReserved2 = 0,  bfOffBits = 54

BITMAPINFOHEADER  <--> Filename = student.bmp
biSize = 40, biWidth = 4,  biHeight = -4,  biPlanes = 1,  biBitCount = 24, biCompression = 0
biSizeImage = 48,  biXPelsPerMeter = 2834, biYPelsPerMeter = 2834
biClrUsed = 0,  biClrImportant = 0

jharvard@appliance (~/Dropbox/pset4/bmp): make resize
clang -ggdb3 -O0 -std=c99 -Wall -Werror    resize.c  -lcs50 -lm -o resize
jharvard@appliance (~/Dropbox/pset4/bmp): check50 2014.fall.pset4.resize bmp.h resize.c
jharvard@appliance (~/Dropbox/pset4/bmp): ./bmpinsp 2by2.bmp

BITMAPFILEHEADER  <--> Filename = 2by2.bmp
bfType = 19778, bfSize = 70,  bfReserved1 = 0,  bfReserved2 = 0,  bfOffBits = 54

BITMAPINFOHEADER  <--> Filename = 2by2.bmp
biSize = 40, biWidth = 2,  biHeight = -2,  biPlanes = 1,  biBitCount = 24, biCompression = 0
biSizeImage = 16,  biXPelsPerMeter = 2834, biYPelsPerMeter = 2834
biClrUsed = 0,  biClrImportant = 0

jharvard@appliance (~/Dropbox/pset4/bmp): ^C
jharvard@appliance (~/Dropbox/pset4/bmp): xxd -c 24 -g 3 -s 54 2by2.bmp
0000036: ff00ee ff00ee 0000ff 00eeff 00ee00 00                    ................
jharvard@appliance (~/Dropbox/pset4/bmp): xxd -c 24 -g 3 -s 54 staff.bmp
0000036: ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee  ........................
000004e: ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee  ........................
jharvard@appliance (~/Dropbox/pset4/bmp): xxd -c 24 -g 3 -s 54 student.bmp
0000036: ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee  ........................
000004e: ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee ff00ee  ........................

2 Answers 2

0
jharvard@appliance (~/Dropbox/pset4/bmp): ./resize 2 2by2.bmp staff.bmp
jharvard@appliance (~/Dropbox/pset4/bmp): ./resize 2 2by2.bmp student.bmp

Of course these will be identical because you created them both using the same resize program.

Make sure your staff version is actually using the staff version

~cs50/pset4/resize 2 2by2.bmp staff.bmp

If these are the bytes of the original:

ff00ee ff00ee 0000ff 00eeff 00ee00 00 

then resizing it by 2 should give you:

ff00ee ff00ee ff00ee ff00ee 0000ff 0000ff 00eeff 00eeff 00ee00 00ee00 00 00
ff00ee ff00ee ff00ee ff00ee 0000ff 0000ff 00eeff 00eeff 00ee00 00ee00 00 00

which is not what you get with your resize.

Looks like you are writing the same pixel ff00ee over and over. Check your loops.

Also, it's a good idea to test with the small.bmp that was given to you as well.

4
  • So from your last comment my resize program should include any padding from in the original image file I am re-sizing even though it would then not comply to the padding rule for BMPs which adds padding according to the rule that the sum of the pixels per line must be divisible by 4. Feb 20, 2015 at 21:52
  • No, your padding shouldn't simply be resized. It just happened that the example bmp you were using was 5 pixels by 1 row, which requires 1 byte of padding. Resizing that by 2 gives 10 pixels per row (ie, 30 bytes which then need 2 bytes of padding). It was just coincidence. This is why I suggested testing with small.bmp. As for the staff version, the instructions are in the pset. Run ~cs50/pset4/resize 2 small.bmp staff.bmp for example to resize the small bmp by 2 using the staff version.
    – curiouskiwi
    Feb 20, 2015 at 22:03
  • Just downloaded a fresh version of the pset4.zip and it does not have a copy of the staff.bmp or the resize program. I used: (wget cdn.cs50.net/2014/fall/psets/4/pset4/pset4.zip) as suggested in the pdf for pset4. Feb 20, 2015 at 22:13
  • No, they aren't in there. As I said, you need to run ~cs50/pset4/resize in order to run the staff version. With that, you create your own "staff.bmp" or whatever you want to call it, so that you can use it to compare to the output of your own resize program.
    – curiouskiwi
    Feb 20, 2015 at 22:14
0

The problem has been solved using the modulus function to determine when and either the input file pointer should be moved for BMP re-sizing or to output input line padding. An example of the type of coding would be:

if((m%resizeby == (resizeby - 1))&&(resizeby > 1)&&(bi.biWidth > 1)) fseek(inptr, inpadding, SEEK_CUR);

Could be used to skip padding for a XbyX BMP with a resize setting of n where: 1 >= n <= 100.

and/or for backing up the input file pointer:

if((m%resizeby == 0)&&(m == 0)&&(resizeby > 1)&&(bi.biWidth > 1)) fseek(inptr, -(bi.biWidth * (sizeof(RGBTRIPLE))), SEEK_CUR);

You must log in to answer this question.

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