You're wrongly calculating
binew.biSizeImage and subsequently
bfnew.bfSize. I'm also not sure if
padding is the new padding, but assuming it's the new padding and it's calculated correctly, on a doubly-resized 3x3 bmp,
padding should be 2,
binew.biSizeImage should be 120 and
binew.bfSize should be 174.
You may use the staff's implementation to resize an image by executing this command
~cs50/pset5/resize n original.bmp resized.bmp
n is the factor,
orignal.bmp is the name/path of the original bmp file and
resized.bmp is the name/path of the resized bmp file.
You may also use
peek (a program implemented by the staff to help you compare bmp headers) by executing this command
~cs50/pset5/peek first.bmp second.bmp
first.bmp is the name/path of the first bmp file and
second.bmp is the name/path of the second bmp file.
And lastly, you may use
diff to compare the bytes of two bmp files as denoted by the pset specification page by executing this command
diff resized-0.bmp resized-1.bmp
Recall that this shouldn't output anything if the files (i.e.,
resized-1.bmp) are identical.
Edit 0: the main reason your bmp file couldn't be recognized by peek is that you're not really initializing
biold initially. Therefore, the members of
binew actually contain garbage values.
Edit 1: unfortunately, the logic of your program is wrong. My advice to you is to get a pencil and a paper, draw a 3x3 image and to try to resize that image by any factor (like a computer :) ), writing down the steps that you've done to accomplish the task.
Then compare these steps (the correct ones) with the steps that your program executes. In other words, try to execute your program by yourself (not a computer) see what it does right and wrong and try to fix that.
Here are some useful tips (hopefully):
atoi() multiple times decreases the efficiency of your program as you're executing the code of this function again and again while you could simply store the value it returns in an
int variable and use it.
Second, after reviewing your code, it appears that you've chosen to follow the seeking approach. The idea behind this approach is quite as follows
- for each scanline in the original bmp, store the starting position of the current scanline (involves functions like
- for each
RGBTRIPLE in the current scanline, read the current
RGBTRIPLE and write it n times (to resize horizontally).
- write the newly calculated padding.
- set the file position indicator to the start of the recently read scanline.
- repeat the steps (2-4) n times (to resize vertically).
Hope that helps!