1

I'm having a bit of an issue here.. I wrote the resize.c function for pset5 and it is working - I am getting the expected results - I can see my file being resized and it looks alright in image viewers .. and the information seems correct (resizing with a scale of 2 gives me a file that is 2x2 and has the same color). However, when submitting or checking with check50, it says my result is wrong. I have rewritten the program twice, also I found somebody else that wrote it and tried their implementation. The result is always the same - the file looks right and the output is the same, but my work is still not accepted. Here is my original file that I'm trying to resize (pixel.bmp):

xxd -c 4 -g 3 -s 54 infile.bmp
0000036: ffffff 00  ....

And this is the entire file:

xxd -c 2 -g 3 infile.bmp
0000000: 424d  BM
0000002: 3a00  :.
0000004: 0000  ..
0000006: 0000  ..
0000008: 0000  ..
000000a: 3600  6.
000000c: 0000  ..
000000e: 2800  (.
0000010: 0000  ..
0000012: 0100  ..
0000014: 0000  ..
0000016: 0100  ..
0000018: 0000  ..
000001a: 0100  ..
000001c: 1800  ..
000001e: 0000  ..
0000020: 0000  ..
0000022: 0400  ..
0000024: 0000  ..
0000026: 0000  ..
0000028: 0000  ..
000002a: 0000  ..
000002c: 0000  ..
000002e: 0000  ..
0000030: 0000  ..
0000032: 0000  ..
0000034: 0000  ..
0000036: ffff  ..
0000038: ff00  ..

When I run resize with a scale of 2, it works and is opened by image viewers, as expected. This is the outfile:

xxd -c 8 -g 3 -s54 outfile.bmp
0000036: ffffff ffffff 0000  ........
000003e: ffffff ffffff 0000  ........

And this is the entire outfile.bmp:

xxd -c 2 -g 3 outfile.bmp
0000000: 424d  BM
0000002: 4600  F.
0000004: 0000  ..
0000006: 0000  ..
0000008: 0000  ..
000000a: 3600  6.
000000c: 0000  ..
000000e: 2800  (.
0000010: 0000  ..
0000012: 0200  ..
0000014: 0000  ..
0000016: 0200  ..
0000018: 0000  ..
000001a: 0100  ..
000001c: 1800  ..
000001e: 0000  ..
0000020: 0000  ..
0000022: 1000  ..
0000024: 0000  ..
0000026: 0000  ..
0000028: 0000  ..
000002a: 0000  ..
000002c: 0000  ..
000002e: 0000  ..
0000030: 0000  ..
0000032: 0000  ..
0000034: 0000  ..
0000036: ffff  ..
0000038: ffff  ..
000003a: ffff  ..
000003c: 0000  ..
000003e: ffff  ..
0000040: ffff  ..
0000042: ffff  ..
0000044: 0000  ..

Everything looks right (to me) - the size seems to be correct, the BM is being sent and the padding looks right. Yet, check50 says it's not.

Here is check50:

    check50 2014/x/pset5/resize bmp.h resize.c
:) resize.c and bmp.h exist
:) resize.c compiles
:) doesn't resize 1x1-pixel BMP when n is 1
:( resizes 1x1-pixel BMP to 2x2 correctly when n is 2
:( resizes 1x1-pixel BMP to 3x3 correctly when n is 3
:( resizes 1x1-pixel BMP to 4x4 correctly when n is 4
:( resizes 1x1-pixel BMP to 5x5 correctly when n is 5
:( resizes 2x2-pixel BMP to 4x4 correctly when n is 2
https://sandbox.cs50.net/checks/f14add13bf6548bf87e0f711af2869ae

Can someone give me a hint of what is wrong here? Thanks in advance!

  • Hi @DreamWave! maybe you could post your check50 results, just in case it could provide a hint... – abelinux Dec 7 '14 at 13:48
  • Thanks for the fast reply, @abelinux . I've updated my question. – DreamWave Dec 7 '14 at 13:53
  • 1
    I wonder why is the frowning here? :( resizes 1x1-pixel BMP to 2x2 correctly when n is 2 ;) – abelinux Dec 7 '14 at 14:00
  • well.. obvious question, perhaps, but it seems your only trouble is when n = 1. Did you check such special test case? – abelinux Dec 7 '14 at 14:02
  • 1
    Did you try comparing something like ./resize 4 small.bmp student.bmp (\n) ~cs50/pset5/resize 4 small.bmp staff.bmp (\n) ~cs50/pset5/peek student.bmp staff.bmp for n = 1? – abelinux Dec 7 '14 at 14:39
0

The conversion from 1x1 pixel to larger files worked fine, but by comparing the conversion for larger files to cs50s with other files it was obvious that there were differences. Checks should be made with i.e. small.bmp in order to see problems.

| improve this answer | |
0

This is what small.bmp with a resize of 2 should look like:

./resize 2 small.bmp s-out.bmp

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

0000036: 00ff00 00ff00 00ff00 00ff00 00ff00 00ff00 0000  ....................
000004a: 00ff00 00ff00 00ff00 00ff00 00ff00 00ff00 0000  ....................
000005e: 00ff00 00ff00 ffffff ffffff 00ff00 00ff00 0000  ....................
0000072: 00ff00 00ff00 ffffff ffffff 00ff00 00ff00 0000  ....................
0000086: 00ff00 00ff00 00ff00 00ff00 00ff00 00ff00 0000  ....................
000009a: 00ff00 00ff00 00ff00 00ff00 00ff00 00ff00 0000  ....................

Yours looks quite different judging from above.

| improve this answer | |
0

Maybe you're not updating biSizeImage and bfSize correctly. Those are probably the things that check50 actually checks. I had the same problem.

| improve this answer | |

You must log in to answer this question.

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