After digging to implement resize, I don't get it if issues come from resize vertical, horizontal or even padding. By running my program on peek, this is what display (* highlighted difference between student and staff solution):

offset  type   name              argv[1]   argv[2]
0       WORD   bfType               4d42      4d42
*2       DWORD  bfSize           0000005a  000001e6
6       WORD   bfReserved1          0000      0000
8       WORD   bfReserved2          0000      0000
10      DWORD  bfOffBits        00000036  00000036
14      DWORD  biSize           00000028  00000028
*18      LONG   biWidth          00000003  0000000c
*22      LONG   biHeight         fffffffd  fffffff4
26      WORD   biPlanes             0001      0001
28      WORD   biBitCount           0018      0018
30      DWORD  biCompression    00000000  00000000
*34      DWORD  biSizeImage      00000024  000001b0
38      LONG   biXPelsPerMeter  00000b12  00000b12
42      LONG   biYPelsPerMeter  00000b12  00000b12
46      DWORD  biClrUsed        00000000  00000000
50      DWORD  biClrImportant   00000000  00000000

See my program below:

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

    // new image size
    new_bi.biSizeImage = ((new_bi.biWidth * sizeof(RGBTRIPLE)) + new_padding)    * (abs(new_bi.biHeight));
    new_bf.bfSize = new_bi.biSizeImage + bf.bfSize - bi.biSizeImage;

Any help will be appreciated.


You have two problems, one with the header and one with image processing.

In the header, you have calculated all the values correctly. (BTW, that was the most unique way I've seen to date to add the size of the headers to the image size to get bfSize. ;-) It's correct, but I'd find a simpler way to do it that isn't so confusing to anyone that would have to read it later. ) Unfortunately, the code is writing the original headers out to the output file, not the new ones with the newly calculated values. Easy error to make with an easy fix.

On the image processing side, it's mostly correct, but one critical part is left out completely. After processing a line of pixels from the input file and writing one scaled up line to the output file, it needs to fseek back to the beginning of the current line in the input file until you've produced the correct number of copies of each line for the vertical scaling. As written, here's what's happening: it copies and scales the first line of the input to the output. Then it scales the second line from input and writes it out where it should be writing a second copy of the first line, and so on.

This should get you going again.

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


Please don't post your full code here, as it may give away solutions to people still working.

One problem I noticed is that~~, when you set biSizeImage, you don't multiply the new padding, even though that padding is going to show up on each line of the new file.

I'm also not sure why you subtracted bi.biSizeImage on the next line, although I haven't looked at this problem set in so long that I might have just forgotten something.

Edit: I misunderstood some things, so the above comments are mistaken.

  • Ok I edited my code above. For biSizeImage, my logic is that the new padding adds up to the scanline and then multiply by the height of the new file. For the next line, bi.biSizeImage was subtracted because the new biSizeImage replace it. – cocobongo Mar 8 '16 at 19:09
  • Sorry, I completely misread those lines. Go with Cliff B's answer. – Levi Roth Mar 8 '16 at 19:18

You must log in to answer this question.

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