RBG value editing problem/question

[Ganado]

In my C++ book, there is an example program that will invert the colors of a .bmp (24-bit Bitmap) image. I don't think I need to copypaste the whole program for my problem, but here's the part I'm concerned with:

void process_invert(int& blue, int& green, int& red)
{
    blue  = 255 - blue;
    green = 255 - green;
    red   = 255 - red;
}

This part of the code assigns the RBG values to each pixel.
It successfully inverts each pixel correctly, just like Ctrl + I does on MS Paint.

What I don't quite understand is how bitmap images themselves deal with values that are over 255 or negative. Here's code from the same program, except I changed the function around a bit:

void process_test_negative(int& blue, int& green, int& red)
{
    blue  = 0 - blue;
    green = 0 - green;
    red   = 0 - red;
}

When this code is processed, it does the same thing as the previous code, except:

1. Each RBG value is +1 compared to the correctly-inverted image.
For example, this is the RBG info for a pixel on the correct image:

Red:   88
Green: 89
Blue: 109

This is the info for the incorrect one:

Red:   89
Green: 90
Blue: 110

2. Certain parts of the image do not correctly invert, making "static"-like color. You'll see this in my third picture.

Here's an example, using an image of a walrus:
Note that photobucket converts the file to a .png, but the colors should still be the same.

This first image is the original picture:
http://i1093.photobucket.com/albums/i434/GanadoFO/test_original.png?t=1374353034

Second image is the correctly inverted picture using the "255 - color" code:
http://i1093.photobucket.com/albums/i434/GanadoFO/test.png?t=1374357366

Third image is the incorrectly inverted picture using the "0 - color" code:
http://i1093.photobucket.com/albums/i434/GanadoFO/test_negative_1.png
Notice the glitchy areas, especially around the hair and blubber creases.

I can't figure out why there is there a difference in those particular areas, can someone tell me what's happening? If the whole code is needed, I'll post it, though I think the problem is understanding how bitmap images are processed and not the code itself. Thanks for reading.

[Stauricus]

it seems that it just happens on the darkest areas of the original image.
i don't know also how it deals with colours that are less than zero. why don't you try absolute values instead?

[tntxtnt]

RGB values = [ 0, 1, 2, 3,...,254,255]

255 - [ 0, 1, 2, 3,...,254,255] == [255,254,253,252,..., 1, 0] (1)

-1 value of signed byte is value 255 in unsigned byte.
-2 value of signed byte is value 254 in unsigned byte.
-3 value of signed byte is value 253 in unsigned byte.
...
I believe RGB value is treated as unsigned byte. Therefore:

0 - [ 0, 1, 2, 3,...,254,255] == [ 0,255,254,253,..., 2, 1] (2)

[255,254,253,252,...,  1,  0] (1) (correct one)
[  0,255,254,253,...,  2,  1] (2) (incorrect)

compare the values in the 2 arrays, you can see why "Each RBG value is +1 compared to the correctly-inverted image." And there is one value that is greatly different from the correct value, which resulted in glichy areas, where the pixels has RGB values = (1,0,0) (0,1,0), (0,0,1), (1,1,0)...

For example:
- (1,1,0) ~ black after invert should be (254,254,255) ~ white. But the value 255 is 0 if you use "0 - color" method, which resulted in (255,255,0) -> yellow
- (1,0,0) ~ black after invert should be (254,255,255) ~ white. But the value 255 is 0 if you use "0 - color" method, which resulted in (255,0,0) -> red

to fix this, either +255 or -1 to the rgb values... which is the same as "255 - color" method ~.~

//same as 255 - blue...
blue  = 0 - blue + 255;
green = 0 - green + 255;
red   = 0 - red + 255;  

//-1 - blue, which is also the same as 255 - blue...
blue  = 0 - blue - 1;
green = 0 - green - 1;
red   = 0 - red - 1;

[Ganado]

Thanks for the replies, Stauricus and tntxtnt.
Absolute value wouldn't work the same, I don't think so at least, which can be seen by tntxtnt's explanation.

tntxtnt, thanks for the explanation on the RBG values, it makes much more sense now.

I also realized that, for example, 300 value becomes 44 on the .bmp image, since 300 - 256 = 44.

These questions popped up when I first noticed some glitchy stuff when using rand() to slightly change the RBG values of an image. When I get the chance I'll be sure to apply what you said to prevent it from glitching like that, thanks again.