# Why does painting with 1% opacity not always do something?

I tried this with Adobe Photoshop Elements 9. When I have a black background, and a white brush with an opacity of 1%, the color should get brighter if I click onto the same spot over and over again. It does that, but only until the color is #d5d5d5. No matter how often I click onto an area with that color (or a brighter one), it won't get any brighter. Is this just a rounding error or is it intended?

Limits:

• Adobe Photoshop Elements 9 or Photoshop CS2: #d5d5d5
• javascript with processing.js (rounded to ~ 1.17%): #d4d4d4
• GIMP 2.6.11: #c0c0c0
-
I think it would be good to fill this question out a bit with test results from Photoshop etc, I will try to do this. – e100 Aug 17 '12 at 12:42
I've added a few – Jake Aug 17 '12 at 13:53
Thinking about it, it seems a bit odd that RGB uses 8 bit (0-255) values, whereas most apps use % opacity...? – e100 Aug 17 '12 at 14:01
Indeed. Though I think I've used an 8-bit value for javascript, so I'm gonna adjust that real quick – Jake Aug 17 '12 at 14:03

The ceiling is indeed a rounding issue -- it's a limitation of storing pixel values as 8-bit integers.

In Photoshop CS2, using decimal values rather than hex and looking at one channel for simplicity:

The value of the pixel appears to be given by:

NewValue = RoundToInteger(
(CurrentValue * (1 - InkOpacity)) + (InkValue * InkOpacity)
)

When InkOpacity = 1%, InkValue = 255,

NewValue = RoundToInteger(
(CurrentValue * 0.99) + 2.55
)
• For CurrentValue < 44, this gives you an increment of 3 per click

• For CurrentValue >= 45 and < 129 this gives you an increment of 2 per click

• For CurrentValue >= 129 and < 213 this gives you an increment of 1 per click

• For CurrentValue >= 213, there is no increment at all.

Note that with higher bit depths, InkValue would be greater. The effect of each click still diminishes, but the ceiling would be closer to pure white.

Assuming the same formula (I haven't tested in Photoshop yet), 16 bit channel values (for which InkValue = 65535) should eventually get you to 65486/65535 which is greater than 99.9% pure white. It'll take you 703 clicks though!

-
Okay, I did some maths, and after noticing that my very first equation was wrong, I did it again, but something's still wrong, I think. I started with d4, to see how you could get to d5. d4 is 212, so my equation is like this: (212 * 0.99) + (255 * 0.01) = 212.43 ~ 212. So you wouldn't get to d5. If you round while calculating, you'll get 213, but if you do the same with 213, you'll get 214 after that. Also, I have no idea how it's supposed to work in GIMP. I'm gonna do some experimenting. – Jake Aug 17 '12 at 14:42
Looks like you only get +2 in the beginning for gimp. – Jake Aug 17 '12 at 14:50
Ah - I completely missed the point that you need to reduce the value of the existing colour before you add to it... – e100 Aug 17 '12 at 15:03
interesting fact: white on black produces 213 = 255-42, black on white produces 42 = 255-213 – Jake Aug 17 '12 at 15:15

It's intended and more of a math concept than anything else. Think about when you multiply 1% x 1% x 1% etc., you will always get a number that is infinitely smaller. The same concept can be applied to colors / opacity. Meaning there will be a limit, which, in "color" or "hex", is your #d5d5d5

-
I have to say I do not understand this answer. Why is #d5d5d5 the limit? – e100 Aug 16 '12 at 8:24
I'm not so sure that it is...I tried to duplicate this in Photoshop and while I saw that the same thing happened, I got different limits based on different brush settings. – Brendan Aug 16 '12 at 13:10
Thanks... So it is sort of a rounding error, isn't it? If we would use decimal places for the hex values, the limit would be brighter, if I'm not mistaken. Now I'm just wondering why there are different limits. I just tried it with GIMP as well, and I also got a different limit. I suppose that depends on the actual implementation details. – Jake Aug 16 '12 at 13:29
This answer isn't quite right - while the diminishing effect per click will always happen, having a limit < 255 is indeed a rounding-to-integer issue. – e100 Aug 17 '12 at 18:55