# whodunit : why do slight adjustments have such drastic results?

Just before hitting "submit" I solved my own problem, but I thought I would share my question and answer, in case someone else ends up with the same problem.

As an intro note: I've noted that you don't have to use hex to specify the colors; you can simply use a decimal number between 0 and 255. Correct me if I'm wrong, but when I printf the numbers, separated by a comma, that's what comes out, and if I replace "rgbtRed == 255" with "rgbtRed = 0" in all instances where Blue and Green == 0, it successfully replaces red with blue.

Using the website here: http://www.color-hex.com/color/009f82 (or, even better, this one: http://www.colorschemer.com/online.html)

I have looked at how small manipulations to the RBG scheme should change my colors.

For example, if I start with 0000FF, a blue color, and add 20 green, I should get a very similar blue color.

However, when I actually modify the colors with code, I get a bunch of drastic changes that don't seem to make sense. Red shows back up for no reason, yellow pops in, and all kinds of mayhem ensues.

My code looks like this:

 //code to zero out red redacted to avoid giving too much information to answer the problem

triple.rgbtBlue += 20;
if(triple.rgbtBlue > 255){
triple.rgbtBlue = 255
}

triple.rgbtGreen += 20;
if(triple.rgbtGreen > 255){
triple.rgbtGreen = 255
}


What's really crazy is that even if I only adjust it by ONE, it can have insane results.

What gives?

I am actually glad I screwed this up, because I really like what I did wrong :)

Our triples are stored as hexadecimal numbers (but we could also look at it in binary, with the same results).

R, G, and B are all side by side-- they're not stored in separate variables. In other words, we're taking 0xff0x000x00, as one big number, and then using our struct to "read out" individual "digits" of that number, or bytes of the number, or several bites of that number, to find out the color they represent.

When a number exceeds 255, it's not stored in the code as 256; rather, it becomes 0, and we carry the extra digit over to the next column.

So, 0,0,255 becomes 0,1,0, rather than 0,0,256 (or the equivalent binary representation thereof).

When I check to see

if(triple.rgbtBlue > 255)


Of course it isn't!

So changing the values this way, even by a little, ends up causing unforseen changes to the other color values.

The working version would be

if(triple.rgbtBlue + 20 <= 0xff){
triple.rgbtBlue += 20;
}


(Note, though, that after getting this part right, it will quickly become clear that I am lightening, rather than darkening, the image!)