PSET3 - Resize (Less) : Random colours being printed?

Question

Going through the walkthrough of 'Resize (less)' and currently trying to resize horizontally. When running resize, only a few pixels have the correct colour and others have completely random colours.

output file of small.bmp with a factor of 2 = https://snag.gy/4J72L9.jpg

Any ideas/suggestions on how to fix/improve my code to fix this bug?

Thanks, everyone.

// resizes a BMP file by n (factor) 

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

#include "bmp.h"

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

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

    // convert user's given number to integer
    int n = atoi(argv[1]);

    // open input file
    FILE *inptr = fopen(infile, "r");
    if (inptr == NULL)
    {
        fprintf(stderr, "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);

    // multiply bi.biWidth/bi.biHeight by n
    bi.biWidth *= n;

    // 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;
    }

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

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

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

    // determine bi.biSizeImage
    bi.biSizeImage = ((sizeof(RGBTRIPLE) * bi.biWidth) + padding) * abs(bi.biHeight);

    // determine bf.bfSize
    bf.bfSize = bi.biSizeImage + sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER);

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

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

            // write RGB triple to outfile n times
            for (int k = 0; k < n; k++)
            {
                fwrite(&triple, sizeof(RGBTRIPLE), 1, outptr);
            }
        }

        // write outfile's padding, if any
        int outfilePadding = (4 - (bi.biWidth * sizeof(RGBTRIPLE)) % 4) % 4;

        for (int l = 0; l < outfilePadding; l++)
        {
            fputc(0x00, outptr);
        }

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

    // close infile
    fclose(inptr);

    // close outfile
    fclose(outptr);

    // success
    return 0;
}

Answer 1

Did you notice that the first line is ok and everything after that is bad?

Remember that there's padding at the end of each line in the input file. The code needs to skip over that padding before starting to process the next line. There's nothing in the code to do that.

Side note: Your code calculates the output padding inside the for loop that processes the image data. There are two problems with that. First, it means that it wasn't used in calculating header data fields, so the header data of the output file will be wrong unless the scaling factor is 1. Second, since it's inside the for loop, this calculation will be done on every loop when it only needs to be done once. It should have been done before any looping that uses it.

Finally, the code only copies the headers to the output file. It doesn't recalculate any of the header fields that need to be updated. When the scaling factor is anything but 1, it will fail.

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