Trouble with PSET4: Resize vertical resizing (recopy approach)

Question

So I'm having a bit of trouble implementing the recopy approach to vertical resizing for this PSET. The horizontal resizing seems to work just fine, but the vertical resizing is.. bad. I have a suspicion it has something to do with the padding. Here is the pseudocode I'm trying to follow for this approach:

for each row
  for n-1 times
    write pixels, padding to outfile
    send infile cursor back
  write pixels, padding to outfile
  skip over infile padding

Here is the relevant code:

// iterate over infile's scanlines
for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
{
    // iterate over pixels in scanline
    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
        for (int k = 0; k < scale; k++)
        {
            fwrite(&triple, sizeof(RGBTRIPLE), 1, outptr);
        }
    }

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

    // then add new padding to outfiles
    for (int l = 0; l < new_padding; l++)
    {
        fputc(0x00, outptr);
    }

    // if height for outfile is not completed, go back to previously set position to continue writing
    for (int m = 0; m < scale - 1; m++)
    {
        // iterate over pixels in infile scanline
        for (int n = 0; n < bi.biWidth; n++)
        {
            // temporary storage
            RGBTRIPLE triple;

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

            // write RGB triple to outfile
            for (int o = 0; o < scale; o++)
            {
                fwrite(&triple, sizeof(RGBTRIPLE), 1, outptr);
            }
        }
        // seek to beginning of infile scanline's row
        fseek(inptr, -(bi.biWidth + padding), SEEK_CUR);

        // add new padding to outfile
        for (int p = 0; p < new_padding; p++)
        {
            fputc(0x00, outptr);
        }

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

Answer 1

I'm a physicist, and as such I am used to thinking in units. In

fseek(inptr, -(bi.biWidth + padding), SEEK_CUR);

bi.biWidth is a number of pixels, padding is a number of bytes, the function expects a number of bytes. How much we need to rewind is right, but using different units, we need to convert. We can do this by multiplying the pixels with sizeof(RGBTRIPLE), which I would consider having unit "bytes per pixel". Which makes it

fseek(inptr, -(bi.biWidth * sizeof(RGBTRIPLE) + padding), SEEK_CUR);

(BTW, that's also the reason why you might see malloc((LENGTH + 1) * sizeof(char)), even though sizeof(char) is 1, it brings the product to the right "unit" in some people's mind)

Also, you're actually doing

for each row
  write pixels, padding to outfile
  for n-1 times
    write pixels, padding to outfile
    send infile cursor back
  skip over infile padding

find the difference ;)