I don't understand what is going on my resize? Actually probably resize too

Question

I have tried many days on resize. I take a break 1-2 week because of external reasons. I Watched zamyla many times and read many articles on stackexchange. but I could not understand. Here is my code. What is going on with me?

 /**
  * resize.c
  *
  * Computer Science 50
  * Problem Set 4
  *
  * Copies a BMP and resize bmp, just because.
  */

  #include <stdio.h>
  #include <stdlib.h>

  #include "bmp.h"

  int main(int argc, char* argv[])
 {
     // ensure proper usage
     if (argc != 4)
     {
         printf("Usage: ./copy resize infile outfile\n");
         return 1;
     }

     // remember filenames
     char* infile = argv[2];
     char* outfile = argv[3];

     //Getting resize value
     char* s = argv[1];
     int resize = atoi(s);

     //Check resize value whether positive and less than or equal to 100
     if (!resize < 0 || resize > 100)
     {
         printf("resize must be 0 < resize <= 100");
         return 1;
     } 
     // open input file 
     FILE* inptr = fopen(infile, "r");
     if (inptr == NULL)
     {
         printf("Could not open %s.\n", infile);
         return 2;
     }

     // open output file
     FILE* outptr = fopen(outfile, "w");
     if (outptr == NULL)
     {
         fclose(inptr);
         fprintf(stderr, "Could not create %s.\n", outfile);
         return 3;
     }

     // read infile's BITMAPFILEHEADER
     BITMAPFILEHEADER bf;
     fread(&bf, sizeof(BITMAPFILEHEADER), 1, inptr);

     // read infile's BITMAPINFOHEADER
     BITMAPINFOHEADER bi;
     fread(&bi, sizeof(BITMAPINFOHEADER), 1, inptr);

     // ensure infile is (likely) a 24-bit uncompressed BMP 4.0
     if (bf.bfType != 0x4d42 || bf.bfOffBits != 54 || bi.biSize != 40 || 
         bi.biBitCount != 24 || bi.biCompression != 0)
     {
         fclose(outptr);
         fclose(inptr);
         fprintf(stderr, "Unsupported file format.\n");
         return 4;
     }

    //Out header info
     BITMAPFILEHEADER out_bf;
     BITMAPINFOHEADER out_bi;

//Updating header info
out_bi.biWidth = bi.biWidth * resize;
out_bi.biHeight = bi.biHeight * resize;

// write outfile's BITMAPFILEHEADER
fwrite(&bf, sizeof(BITMAPFILEHEADER), 1, outptr);

// write outfile's BITMAPINFOHEADER
fwrite(&bi, sizeof(BITMAPINFOHEADER), resize*1, outptr);

// determine padding for scanlines    
int out_padding = (4 - (out_bi.biWidth * sizeof(RGBTRIPLE)) % 4) % 4;

out_bi.biSizeImage = bi.biSizeImage * resize + out_padding;
out_bf.bfSize = out_bi.biSizeImage + out_bf.bfOffBits;

// iterate over infile's scanlines
for (int i = 0, biHeight = abs(out_bi.biHeight); i < biHeight; i++)
{
    // iterate over pixels in scanline
    for (int j = 0; j < out_bi.biWidth; j++)
    {
        // temporary storage
        RGBTRIPLE triple;

        // read RGB triple from infile
        fread(&triple, sizeof(RGBTRIPLE), 1, inptr);

        // write RGB triple to outfile
        fwrite(&triple, sizeof(RGBTRIPLE), resize*1, outptr);
    }

    // skip over padding, if any
    fseek(inptr, out_padding, SEEK_CUR);

    // then add it back (to demonstrate how)
    for (int k = 0; k < out_padding; k++)
    {
        fputc(0x00, outptr);
    }
}

// close infile
fclose(inptr);

// close outfile
fclose(outptr);

// that's all folks
return 0;

}

Answer 1

You have a number of problems. First, look at the following:

    // write RGB triple to outfile
    fwrite(&triple, sizeof(RGBTRIPLE), resize*1, outptr);

For purposes of explanation, let's say that resize = 3. This code does not write out the contents of triple 3 times. It actually writes out 3 blocks of data that are the size of RGBTRIPLE, starting from the address &triple. So, you are actually writing out the RDBTRIPLE plus two more blocks from the memory that follows.

You need to wrap the fwrite( ) in a for loop and execute it as many times as needed.

Next, you're using the padding for the output file to fseek over the padding of the infile. The padding of the infile and the outfile are not necessarily the same. They may be the same simply by coincidence, but you absolutely have to calculate both!

Third, you haven't dealt with scaling vertically at all.

There are probably other issues, but these are so significant that you need to resolve them first. Other issues may disappear or be added, depending on what you do, so there's little point to dig deeper until you make these changes.

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