# pset 5 resize.cdoes not resize properly. works visually for smiley.bmp but not for small.bmp

Theses are my observations so far:

1. It can resize the smiley.bmp properly without distorting the image. What I'm not sure about is whether or not the contents of its headers are right.
2. It can resize the small.bmp properly, size-wise. However, it distorts the image if the resize factor is not a multiple of 4.
3. When the headers of the small.bmp resized by a factor of 4 is compared to the staff's version, everything but the bfSize is right.
4. Even if I hardcode the right bfSize when the resize factor is 4, check50 still states that it does not resize properly when a 1x1 bmp file is resized by 4.

Now my question is, where did I go wrong? I've been stuck here for weeks, so I'd really appreciate any help. Thank you very much!

• Are you recalculating the padding for the new image size? Because the goal of padding is to make the row width (in bytes) divisible by 4, it is the same when the image is scaled by a multiple of 4 but must be changed when scale not divisible by 4 is chosen. – Paul Nov 16 '14 at 0:15

I could understand what you were trying to do but i was confused by your step :

row[(j * n) + k] = triple;

Understand that in the resized image we have to replicate the same pixels along the Width n times and then along height.

eg. if in original image pixels were 1 2 3 then on resize by 2 the new image will contain

1 1 2 2 3 3

1 1 2 2 3 3

The proposed way to do so will be by writeing the same pixel directly (rather than storing in array) n times.Do this for all pixels along Width. Add new padding and seek forward old padding in the source file.Then check if the number of times the line has been replicated along Height is less than n. If so then seek back to the start of line and again repeat the above procedure.

Function ftell is a functon that tells you the current position in the file.

If this information appeared vague or insufficient then comment . I'll try to clear the doubt.