Problem Set 3 (Resize) Help

Question

I have been working for a while now, and I have a few questions regarding the Resize problem set. My code makes sense to me intuitively, but I am sure I went wrong somewhere, as my output is clearly not as intended.

Here is a main question I have (along with a few others that I can't identify

What is the point of using the fread function and the old infile pointer rather than just using the new one and multiplying by the factor (resize scale)?

Here is an example of what I mean:

// Why do this:

BITMAPINFOHEADER bi, bi_new;
fread(&bi, sizeof(BITMAPINFOHEADER), 1, inptr);

bi_new = bf;

bi_new.biWidth *= n;
bi_new.biHeight *= n;

// Rather than just this:

BITMAPINFOHEADER bi;
fread(&bi, sizeof(BITMAPINFOHEADER), 1, inptr);

bi.biWidth *= n;
bi.biHeight *= n;

Also, I believe I have this problem later when I only have one line for "padding". I am not sure what the purpose of having the old infile padding is, but I see many helpful solution advice that seem to incorporate it.

Aside from these questions, I would appreciate if you could check out my code here: https://gist.github.com/debner5/95a2b8d624e08609218f8c82ee9732c5

Thank you for the help!

Answer 1

Not exactly clear what you're asking in your first question, but I know what you should be asking, so here goes. ;-)

The file can't simply be multiplied by some scaling factor. Each line of pixels (excluding the padding) needs to be scaled up. Then, the appropriate number of bytes need to be added to the end of the scaled up line.

That last part explains why you need two padding calculations. The padding for the input file and the padding for the output file are frequently different. There may be a complex formula to determine the new padding from the old, but it's far simpler to just calculate the new padding for the new file directly, as explained in the videos.

The headers for both files contain the same header structures at the beginning of the file. However, some of these fields MUST be updated to reflect new sizes of the image. You need to make sure that the headers that are written out to the output file are correct.

Why have two versions of bi and bf? Well, two different methods are used for solutions. One saves the input file header data before its changed and then updates the input file's headers to write them out. The other method is to duplicate the input file's headers as output file header structs and then update the fields that need to be changed.

Which way is better? That's a matter of opinion. The first method saves a little memory, but requires knowing what's been updated and what hasn't. The second method explicitly makes it clear which header is for the input file and the output file.

I prefer the latter method. Unless it's absolutely necessary to minimize memory usage, I prefer to use the extra 54 bytes to clearly preserve the two versions of the headers so that I'm using only the input header elements to control reading the input file and related for loops, and only the output header elements to control the output file writes and for loops.

I looked at your code and it seems on track, but will require incorporating these concepts to get it working. Before that happens, an in-depth analysis isn't warranted. But keep going, you're on the right path.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)