0

I'm doing recover on pset4. The program creates 50 images with their proper names but their contents turn out weird, misaligned and corrupted. Looking at my code and the images, I suspect the problem has something to do with my loops and also, the pictures don't fill their frames entirely as there are still grey coloured strips at the bottom. Could anyone please explain the reason behind this issue? Thank you.Here is my code and images: enter image description here enter image description here

//Opens input file
FILE *inptr = fopen(infile, "r");
if(inptr == NULL)
{
    fprintf(stderr, "Could not open %s\n", infile);
    return 2;
}

int counter = 0;
//Allocates memory for storage array
BYTE *temp_arr = malloc(BLOCK);
//Create an array of char to store name of outfile
char name[8];

//Find infile's size(in byte)
fseek(inptr, 0, SEEK_END);
int size_infile = ftell(inptr);
fseek(inptr, 0, SEEK_SET);

//Iterates from start block to end block of infile
for(int i = 0; i < (size_infile / BLOCK); i++)
{
    //Reads 512 bytes from infile then store in temp array
    fread(temp_arr, BLOCK * sizeof(BYTE), 1, inptr);
    FILE *img;
    for(int j = 0; j < BLOCK; j++)
    {
        if(temp_arr[0] == 0xff && temp_arr[1] == 0xd8 && temp_arr[2] == 0xff && (temp_arr[3] & 0xf0) == 0xe0)
        {
            if(counter == 0)
            {
                counter++;
                sprintf(name, "%03d.jpg", 0);
                img = fopen(name, "w");
                fwrite(temp_arr, BLOCK * sizeof(BYTE), 1, img);
            }
            else if(counter > 0)
            {
                fclose(img);
                counter++;
                sprintf(name, "%03d.jpg", counter - 1);
                img = fopen(name, "w");
                fwrite(temp_arr, BLOCK * sizeof(BYTE), 1, img);
            }
        }
        else if((temp_arr[0] != 0xff && temp_arr[1] != 0xd8 && temp_arr[2] != 0xff && (temp_arr[3] & 0xf0) != 0xe0) && counter > 0)
        {
            fwrite(temp_arr, BLOCK * sizeof(BYTE), 1, img);
        }
        if(!fread(temp_arr, BLOCK * sizeof(BYTE), 1, inptr))
        {
            fwrite(temp_arr, BLOCK * sizeof(BYTE), 1, img);
            fclose(img);
            fclose(inptr);
            free(temp_arr);
            return 0;
        }
    }
}

}

2 Answers 2

0

First, to properly format the code: edit the question, select the code, click the {} icon in the format bar.

One major problem is: This program will write each block of a jpeg BLOCK times. Each block in the raw file should either be discarded (if it hasn't encountered the first sig) or written to a jpg. The j loop is unnecessary (read: wrong).

There are other problems like:

  • if(!fread(temp_arr, BLOCK * sizeof(BYTE), 1, inptr)). This actually does the read, so it could be skipping blocks. It seems to be a test for EOF, but the i loop will terminate after it reads the size_infileth block.
  • this (temp_arr[0] != 0xff && temp_arr[1] != 0xd8 && temp_arr[2] != 0xff && (temp_arr[3] & 0xf0) != 0xe0) is not the "opposite" of a jpg signature. If one of the values matches, the whole expression is false. But since you already know it's not a jpg sig when control reaches the else, counter > 0 (should be?) a sufficient test.
1
  • Thank you very much! After altering the code, I get back proper images except the last one, but it's certainly much better than before . But now I get this error "killed by server" when using check50. When I run the program, it does take quite a bit of time and after printing out all the images, it also gives "file size limit exceeded". This should be the reason that leads to said error. I guess I have to find a way to condition EOF to avoid this error. Apr 19, 2017 at 14:36
-1

Please ensure that file fix permissions, file location, filename, file extension, and relative file path are correct. How about trying a JPEG Repair Software? I am suggesting this since many of them are available for free online.

1
  • Please take the time to review the problem set before providing an answer. That way, you would have seen that what you wrote is irrelevant in this case.
    – Blauelf
    May 16, 2017 at 14:22

You must log in to answer this question.

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