fread/fwrite issues

Ok so I am having trouble editing a bitmap image file. I have successfully copied the header of the bitmap from one file to the other, but now I want to copy the pixel data also. However I want to invert the colours of the image as I do this, therefore i want to have 255-value for each pixel.

So basically what I want is a loop that reads in one byte at a time, somehow does 255-x, be it through converting to decimal or bits etc. Then write it to the new file.

I had tried using a for loop like this but it did not work.

Code:

fileA=fopen(strng1, "rb");
fileB=fopen(strng2, "wb");
fread(fileheader, 1, 52, fileA);
fwrite(bmaptype, 1, 2, fileB);
fwrite(fileheader, 52, 1, fileB);

char pixel[12287];
char pixnew[12287];

for (i=0; i<12287; i++)
    {
        fread(pixel[i], 1, 1, fileA);
        pixnew[i]=(255-atoi(pixel[i]));
        fwrite(pixnew[i], 1, 1, fileB);
}

fclose(fileA);
fclose(fileB);

P.s. The array size is down to the image being 64x64 and 3 bytes for each pixel (RGB)

Any help would be greatly appreciated. Thank you.

Wouldn't you invert the bits instead of subtracting from some magic number?

You would do something like

pixel[i] = atoi(pixel[i]);
pixel[i] = ~pixel[i];
fwrite(pixel[i] , 1 , 1 , fileB);

Also, arrays start at zero, not one.

You could even skip an instruction

Code:

// pixel[i] = ~pixel[i];
fwrite(~pixel[i] , 1 , 1 , fileB);

Also, what's the point of having an char array 12287 bytes long if you are going to read and write a character at a time?

I hadn't originally been using an array, I had just changed that to try it out to see if it would work but it didn't.

I'm not sure what you mean by '~', i've never seen this used, is it some sort of inversion operator?

So would you suggest somethin along the lines of

Code:

fread(pixel, 1, 1, fileA);
pixel=atoi(pixel);
fwrite(~pixel, 1, 1, fileB);

Yes, tilde is the inverse operator. It will flip all bits, same as subtracting 255.

I don't see the point of the atoi() function either. You should be reading and writing at the binary level, so there are no ascii characters to take into consideration. Lose the atoi() function too.

What about pixel, i had been defining that as char because it was one byte long, but it could be defined as BYTE couldn't it? I just remembered that its in one of the header files. I had been using that atoi and such, because i thought it would be reading in a character.

But no, I think i get how it should be working now. This is the loop i'm trying to use at the minute and it won't work, there are no errors, but it crashes when it runs.

Code:

BYTE pixel;

for (i=0; i<12287; i++)
    {
        fread(pixel, 1, 1, fileA);
        fwrite(~pixel, 1, 1, fileB);
}

I'm assuming it is something to do with this loop as I had it running before when I had been using fprintf in the loop, and haven't really changed anything else. I can show you the rest of the program if you wish? Thank you very much for the help so far, its greatly appreciated. I hope you can continue to help


EDIT: Ok so I'm just realising that I could actually read in the entire image data and flip it that way without the loop. I'll give it a go now.

Don't get the mistaken impression that you can always perform a value reflection by a bit inverse. That only works for certain values, specifically, (2^N)-1 for any positive N. 255 works. But if the range of pixel values was, say, [0,1000] then simply inverting the bits doesn't work.

I wouldn't muddy the waters by "optimizing" with a bit flip. I think explicitly subtracting from 255 is clearer and less mysterious. The compiler will figure it out anyway.

Aside from all the other issues mentioned, these need to be addresses.

fread(&pixel[i], 1, 1, fileA);

Likewise for the fwrite.

Hmm well I have it running now and working with this code:

Code:

BYTE image[imagesize1];
fread(image, 1, imagesize1, fileA);
for(i=0; i<imagesize1; i++)
    {
        image[i]=~image[i];
    }
fwrite(image, imagesize1, 1, fileB);

Where imagesize1 is the size of the image data as read from the header of the image.

However it crashes when the image is more than 832x832, any idea why this could be? I'm guessing it's some sort of memory allocation problem. I'm happy enough with it as it is, but would like to be able to make it work with larger images.

> However it crashes when the image is more than 832x832, any idea why this could be?
832*832 is nearly 700KB of memory (your default stack is likely to be 1MB).

Also, declaring arrays inline (like you appear to do) is only supported in the latest C standard.

Since all you're doing is reading, modifying and writing, there seems little need to store the whole thing in memory for what is a very short moment of time.