0

I have been through my code a few times aloud and on paper and have hit a brick wall. I'd rather get a hold on the re-copy method before bottling it and trying the re-write method.

// iterate over infile's scanlines
for i = 0 to input bitmap height
{
    //vertical copies
    for q = 0 to n 
    {
        //iterate over pixels in scanline
        for j = 0 to input bitmap width
        {
            //read RGB triple from infile

            //horizontal copies of pixels                           
            for p = 0 to n
            {
                // write RGB triple to outfile
            }
        }           

        // add padding at the end of each row
        for k = 0 to padding
        {
            // write NUL character to outfile
        }

        // "stream" back to start of row 
    }

    // skip padding in input file and move to next line of code
}

Values of constants before the nested loops are:

abs(bi.biHeight) = 3
bi.biWidth = 3
paddinginput = 1
padding = 2

The output picture is mainly black, I'm sure the problem is in this part of the code, potentially to do with the vertical iterations as the top band of the output is green (as per small.bmp)

1
  • Adam, I redacted a bunch of code so that the question can still be useful to others, without them being guilty of breaching the honour code. The remaining pseudo code still shows the problem. Aug 6 '14 at 21:53
1

The code is almost correct. The error lies in the logic in seeking back to the start of the row, and not necessarily how it's implemented, but where. Technically it's correct and does what it's supposed to, but the location of where it is in the code has unintended side-effects.

To understand what's happening, try to imagine where the file pointer is at the end of the q loop. Supposedly it's at the start of the row in the input bitmap, ready for the next iteration.

When the q loop exits, the very next line of code moves the file pointer ahead by the padding amount. So the file pointer is moved ahead from the start of the input row, which is not correct. It should actually seek to the end of the input row.

Suppose you were to move the seek operation from being the last operation in the q loop, to instead be the first operation. The implementation would need to change because the initial condition would be different. However, when the q loop completes the file pointer will be near the end of the input row. The subsequent seek operation will then move the file pointer to the end of the row as expected.

4
  • Answer makes complete sense and I was massively overexcited to implement your suggestion, but unfortunately apparently my program is still buggy. I essentially initialised the stream to be at the end of the first row before my loop construct allowing for having the fseek() at the start of q loop - alas no luck. Aug 7 '14 at 11:54
  • My code doesn't seem to be writing multiple lines of pixels for each row. I thought the header file only allowed for a certain number of pixels per row but am I missing something, is there a way to make fwrite() begin printing on the next line? Aug 7 '14 at 12:03
  • I found another bug: my fseek() was seeking back by a factor of n (in the original image). Rookie error Aug 7 '14 at 12:18
  • It was an error with my operation of fseek() all sorted now your help was greatly appreciated Aug 7 '14 at 12:36

You must log in to answer this question.

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