So, I think I finally managed to get the right headers for resize.c

But now, when I look at the output, I get this random colored bmp file and it's driving me nuts, as I have no idea why it does that. I have modified my code tons of times, but ultimately decided to recopy paste the original from copy.c, but I'm still getting the color thing. Can anyone clarify what's going on? Here's (a bit of) my code:

// Saving original width and height
int oriwidth = bi.biWidth;
int oriheight = bi.biHeight;

// Modifying to new width and height
bi.biWidth = bi.biWidth * n;
bi.biHeight = bi.biHeight * n;

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

// Modifying sizes
bi.biSizeImage = ((bi.biWidth * abs(bi.biHeight)) * sizeof(RGBTRIPLE)) + (padding * abs(bi.biHeight));
bf.bfSize = bi.biSizeImage + 54;

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

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

// iterate over infile's scanlines
for (int i = 0; i < abs(oriheight); i++)
    // iterate over pixels in scanline
    for (int j = 0; j < oriwidth; 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), 1, outptr);

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

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

What happens is that you create a bmp file of the resized size, but you don't actually resize the image. If the original one was, say 1x1 and the resize factor is 3, you're now creating a 3x3 image but only writing 1x1, which means that you will only write the first 3 bytes of the current file (that is 27 bytes). All the other bytes exist there though, and are filled with garbage. Since your file is a bmp, all the garbage is interpreted as some color.

  • I see. So if I were to implement the fwrite function correctly (with who knows how many for loops), the coloring would be gone? Ah man... I was thinking I'll solve this and then move on to the loops, and now it turns out that is the problem... Thanks, that was helpful! – Bubi Oct 31 '15 at 21:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .