My code, like many others', seems to do the re-sizing ok. However, it seems that the bisizeimage and the bfsize are never correct, even after taking suggestions from other posts. Please refer to the next comment for the display from peek.

//Create header files for output file
BITMAPFILEHEADER bf_out = bf;   

//Update the output file headers
bi_out.biWidth= bi.biWidth*rf;
bi_out.biHeight= bi.biHeight*rf;

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

bi_out.biSizeImage = (bi_out.biWidth* sizeof(RGBTRIPLE) + outpadding)*bi_out.biHeight;
bf_out.bfSize = bi_out.biSizeImage + 54;

// write outfile's BITMAPFILEHEADER
fwrite(&bf_out, sizeof(BITMAPFILEHEADER), 1, outptr);
// write outfile's BITMAPINFOHEADER
fwrite(&bi_out, sizeof(BITMAPINFOHEADER), 1, outptr);

// iterate over infile's scanlines
for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
    for (int y=0; y<rf; y++)
        // 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);

            for (int z=0; z<rf; z++)
                // 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 < outpadding; k++)
            fputc(0x00, outptr);
        if (y<rf-1)
            fseek(inptr, - (abs(bi.biWidth) * sizeof(RGBTRIPLE) + padding), SEEK_CUR); 
  • '2 DWORD bfSize 000001e6 fffffe86' '34 DWORD biSizeImage 000001b0 fffffe50' these two are the comparisons between the large.bmp and my output file when using a factor of 4 for re-sizing. Everything else is the same except for these two. I have been banging my head on this one for a long time. I am not sure if I missed anything. Any help is greatly appreciated! Thanks.. Sep 20 '15 at 0:11

I'm going to make you beat your head against the wall just a little bit more. ;-)

Look at the numbers you gave in the comparison of biSizeImage:

DWORD biSizeImage 000001b0 fffffe50

Did you notice that 000001b0 * (-1) = fffffe50 ? The ffffffe50 number is how a negative number is stored in the computer in two's complement form. With that in mind, go back and look carefully at the specification for biHeight and then look at your code carefully! You should soon realize the problem. ;-)

Next, bfSize is based on biSizeImage, so any problem with the latter produces a problem with the former. However, I'm wondering if the numbers you posted above are a typo or if they are a result from different source code. Along with the same negative vs. positive number issue, they have a difference of 108. This is conspicuous in that it is exactly 2 * 54. (You'll see why it's significant when you review your code.) This error of 108 doesn't make any sense.

Anyways, this should get you going. ;-)

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

  • Oh god, I totally forgot that there is an orientation for each image where they can have their first pixel at top or bottom depending on the sign of the height....This was even in the question list that I answered... So by taking abs of the height, I was able to get everything correct..Thank you so much Cliff! Sep 20 '15 at 1:50
  • Don't feel bad. This is one of the most common errors with this program. ;-)
    – Cliff B
    Sep 20 '15 at 2:36

You must log in to answer this question.

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