0

Hello and thanks for reading.

I'm having the following problem with resize.c:

The resized image looks OK (compared to staff.bmp)

The headers are OK:

~/workspace/pset4/resize/ $ ./resize 4 small.bmp student.bmp                
~/workspace/pset4/resize/ $ ~cs50/pset4/resize 4 small.bmp staff.bmp                
~/workspace/pset4/resize/ $ ~cs50/pset4/peek student.bmp staff.bmp        
offset  type   name              argv[1]   argv[2]
0       WORD   bfType               4d42      4d42
2       DWORD  bfSize           000001e6  000001e6
6       WORD   bfReserved1          0000      0000
8       WORD   bfReserved2          0000      0000
10      DWORD  bfOffBits        00000036  00000036
14      DWORD  biSize           00000028  00000028
18      LONG   biWidth          0000000c  0000000c
22      LONG   biHeight         fffffff4  fffffff4
26      WORD   biPlanes             0001      0001
28      WORD   biBitCount           0018      0018
30      DWORD  biCompression    00000000  00000000
34      DWORD  biSizeImage      000001b0  000001b0
38      LONG   biXPelsPerMeter  00000b12  00000b12
42      LONG   biYPelsPerMeter  00000b12  00000b12
46      DWORD  biClrUsed        00000000  00000000
50      DWORD  biClrImportant   00000000  00000000

valgrind says no leaks:

~/workspace/pset4/resize/ $ valgrind ./resize 3 small.bmp larg.bmp
==5754== Memcheck, a memory error detector
==5754== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5754== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==5754== Command: ./resize 3 small.bmp larshh.bmp
==5754== 
==5754== 
==5754== HEAP SUMMARY:
==5754==     in use at exit: 0 bytes in 0 blocks
==5754==   total heap usage: 3 allocs, 3 frees, 1,145 bytes allocated
==5754== 
==5754== All heap blocks were freed -- no leaks are possible
==5754== 
==5754== For counts of detected and suppressed errors, rerun with: -v
==5754== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

But, almost no one check50 test is working: https://sandbox.cs50.net/checks/852232b214f445eba0b331824d6c4518

This is the main logic of the program

SPOILER

for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
    {
        // iterate over pixels in scanline
        for (int j = 0; j < oldWidth; j++)
        {
            // temporary storage
            RGBTRIPLE triple;

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

            // write RGB triple to *colors
            colors[j].rgbtBlue = triple.rgbtBlue;
            colors[j].rgbtGreen = triple.rgbtGreen;
            colors[j].rgbtRed = triple.rgbtRed;
        }

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

        for(int s = 0; s < n; s++)
        {
            for(int h = 0; h < oldWidth; h++)
            {
                for(int x = 0; x < n; x++)
                {
                    fwrite(&colors[h], sizeof(RGBTRIPLE), 1, outptr);
                }
            }
            // add padding, if any
            for (int k = 0; k < newPadding; k++)
            {
                fputc(0x00, outptr);
            }
        }
    }

Let me know if I'm missing any info.

Thanks in advance.

3
  • In for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++), does bi.biHeight refer to the old or the new height?
    – Blauelf
    Jun 28 '17 at 7:45
  • 1
    Just asking because if it were the new height, you'd write extra data after your bitmap is already complete. So image would look correct, but file is larger than required. One could consider this an opportunity for Steganography :)
    – Blauelf
    Jun 28 '17 at 12:25
  • @Blauelf thanks a lot :) ! Nice to also get the concept of Steganography! Now the problem is 0.5 resizes, gonna take a look on that bug. Jun 28 '17 at 17:40

You must log in to answer this question.

Browse other questions tagged .