I have a padding problem in the resize (pset4). I can resize any image that doesnt need padding in their new version, but when it comes to padding it just doesn't work. I checked the headers with peek and they're not the problem. The program also calculates the values of oldpadding and newpadding correctly. xxd output for small.bmp resized by 2. (xxd output for small.bmp resized by 2.)It also has a weird xxd output. As you see above, it shows 8 pixels as the wiidth of the image despite it says 6 when i peek in the bitmapinfoheader. I would appreciate every little tip. Because this problem is driving me crazy.

//change the size

LONG cbiwidth = bi.biWidth*n;

// determine padding for scanlines
int newpadding =  (4 - (cbiwidth * sizeof(RGBTRIPLE)) % 4) % 4;
int oldpadding =  (4 - (bi.biWidth * sizeof(RGBTRIPLE)) % 4) % 4;    
LONG cbiheight = bi.biHeight*n;

DWORD cbisizeimage = abs(cbiheight)* (abs(cbiwidth)*sizeof(RGBTRIPLE) + newpadding) ;

DWORD cbfsize = cbisizeimage +sizeof(bf)+ sizeof(bi);    

// write outfile's BITMAPFILEHEADER
fwrite(&bf.bfType, sizeof(WORD), 1, outptr);
fwrite(&cbfsize, sizeof(DWORD),1,outptr);
fwrite(&bf.bfReserved1, sizeof(WORD)*2 + sizeof(DWORD),1,outptr);
// write outfile's BITMAPINFOHEADER
fwrite(&bi, sizeof(DWORD),1,outptr);
fwrite(&cbiwidth, sizeof(LONG),1,outptr);
fwrite(&cbiheight, sizeof(LONG),1,outptr);
fwrite(&bi.biPlanes, sizeof(WORD)*2 + sizeof(DWORD)*1,1,outptr);
fwrite(&cbisizeimage, sizeof(DWORD),1, outptr);
fwrite(&bi.biXPelsPerMeter, sizeof(LONG)*2 +sizeof(DWORD)*2, 1, outptr);


// iterate over infile's scanlines
for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
     for(int h=0; h < n; h++)
            fseek(inptr,(-(sizeof(RGBTRIPLE)*(bi.biWidth)+oldpadding))*i, SEEK_CUR);
        // 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 l = 0; l < n ; l++)
                    fwrite(&triple, sizeof(RGBTRIPLE), 1, outptr);

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

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

1 Answer 1


For the strange xxd output, it's because you have given a wrong value for the columns -c flag. Since the small.bmp image has a width of 3 pixels, it has as -c

  • 3 pixels * 3 bytes each pixel == 9 bytes
  • + 3 bytes of padding to be a multiple of 4
  • we have 12 bytes

That's why the command for the xxd on small is

xxd -c 12 -g 3 -s 54 small.bmp

Now If you resize it by 2, you have:

  • 6 pixels * 3 bytes each pixel == 18 bytes
  • + 2 bytes of padding to be a multiple of 4
  • we have 20 bytes

So the xxd command for small2.bmp should be

xxd -c 20 -g 3 -s 54 small2.bmp

Now if you could kindly re-execute the correct command and edit your question with the new output and what is the problem exactly you're facing with the padding.

If this answers your question please accept it by clicking the gray check-mark to the left, so that it becomes green. You can also vote it up by pressing the up arrow above the check-mark. And don't forget to keep coding!

  • 1
    Thanks. That did the trick. Sep 7, 2015 at 19:34

You must log in to answer this question.

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