So, I'm in the midst of PS4 resize, and while I know I'm still figuring out an array of different things, when i currently perform the resize (even if I "resize" it to the same size) it seems to be picking and assigning RANDOM colors to the output file.

This is what it does to "smiley.bmp". I just don't get where it would be pulling these colors FROM.

enter image description here

// iterate over infile's scanlines
for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
    // iterate over multipled rows in new file
    for (int j = (i * n); j < ((i * n) + n); j++)
        fseek(inptr, (i * bi.biWidth), SEEK_SET);

        // iterate over pixels in scanline
        for (int p = 0; p < bi.biWidth; p++)
            // temporary storage
            RGBTRIPLE triple;

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

            // write RGB triple to outfile
            for (int w = (p * n); w < ((p * n) + n); w++)
                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);
  • I'm also curious about the complexity of your two FOR loops. for (int j = (i * n); j < ((i * n) + n); j++) Isn't this the same as saying for (int j = 0 ; j < n ; j++) ? Since j is only used for the loop index, nothing else depends on it.
    – Cliff B
    Oct 6, 2015 at 17:58
  • That loop is INTENDED to handle the vertical expansion. Basically if I'm resizing by a magnitude of 4, I need to print each pixel 4 times horizontal and 4 times vertical. It's clearly not working just now, but that's my first attempt at making that work. Oct 7, 2015 at 15:46
  • The point wasn't that there were two loops, that's absolutely correct. The issue was with the (i*n) complexity. counting from (i * n) to (i * n) +n is the same as counting from 0 to n. Unless there is a dependency within the loop for j starting at i*n, then there's no apparent purpose. There's an old saying in programming - keep it simple.
    – Cliff B
    Oct 7, 2015 at 16:01
  • I see what you're saying. In this case "n" was the resize factor from argv, so if that equals 4, then (i * n) to (i * n) + n on say the second iteration would be going from line 8 to line 12. Or am I lost in my math? Oct 7, 2015 at 16:21
  • I'm thinking this line earlier in my code may also be screwing me up. I've created a second BITMAPINFOHEADER called bi2. And I calculate the biSizeImage with the following line: bi2.biSizeImage = abs(bi2.biHeight) * bi2.biWidth * 3 Yet when I pull the info for this in gdb after that line runs it says that bi2.biSizeImage = 4294966582 What did I do? Oct 7, 2015 at 16:34

1 Answer 1


There are several problems in the code, but the biggest is this:

    fseek(inptr, (i * bi.biWidth), SEEK_SET);

The third parameter is the starting point and the second parameter is the offset. SEEK_SET is the beginning of the file, so starting at the beginning of the file, you are saying to move to i * bi.biWidth. Let's say that i is 0. Then the offset is 0. That means 'move to the start of the file'. So, the code will start processing the header data as image data. You forgot to skip forward past the headers.

Interestingly, if you comment this line out, the file should generate a correct output file for scaling of 1. It did when I put your code into mine to run it.

You need to figure out how to correctly reposition at the start of each line.

Another problem: It appears that you are using the input padding for the output padding. The output padding will change as the scaling changes and must be calculated.

There are other issues, but this will get you going.

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

  • ahhhh RIGHT, I forgot that the header is actually part of the file I'm working with. Thank you. I feel like the other things will (hopefully) just be cleanup once I figure this one out. :) Oct 6, 2015 at 16:31

You must log in to answer this question.

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