This could very well hinge on the fact that I know little about color math, but there are so many things confusing me about this example that I thought I'd take it to the forum for some explanation.

My main question: Why doesn't the red circle ever become completely opaque?  It seems to come to a resting state of varying opacities, depending on the value of opacityStep.

Which leads to the additional questions: Why does the red obscure the magenta and but not the green?  And why is the intersection of red and green darker than the intersection of all three?

Furthermore: Why does increasing the opacityStep value to >= 4 nullify the difference between the R+G and the R+G+M sections?  And why does increasing it to greater values (eg. 40) allow the red circle to converge to a more opaque resting state?

I apologize for asking so many questions, but if any piece of this could be explained, I'd be greatly appreciative.

Thanks,
Andy

Quote:

Thanks for the response, davbol.  If it just comes down to a rounding error, I guess I don't really understand how alpha works.  It seems intuitive that stacking an infinite number of objects of _any_ opacity should ultimately yield opaque.

Your corrections to my test-case program work well, and that method would work well for any instance where the program is keeping track of the geometry displayed.  I probably should have explained, though, that I'm trying to apply this to a drawing type program, where I basically want transparent brushstrokes to stack into opaque ones.  In this case it would be arbitrarily complex to keep track of all the geometry and redraw it each frame.  Therefore, I've kinda just been counting on Processing to work everything out on the pixel level.

Here's a new test case:
Quote:



As you can see in this screencap, even when the mouse button is held indefinitely (and even when the stroke has an opacity of 40, instead of 2) the red value never reaches 255, indicating that it never reaches fully opaque.  This is a problem in a drawing program, because you can never fully block things out by painting over them.  (Furthermore, when the stroke opacity is set at a lower value, the stacked opacity of the resulting stroke is maxed out at an even lower value, like the original test case.)

Anyway, sorry for being so long winded, but does anyone have any insight on this revised scenario?  How can I make my brushstrokes stack to be fully opaque?

Thanks again,
Andy

Long answer...

If you were to print out *each* of the red values after each frame what you'd find is a non-linear rate of change.

In other words, on the first frame, red will jump from 0 to 40, thus delta red (dr) = 40.

On the second frame, red will jump from 40 to 74, dr = 34.  If at this point you wonder why it's 74 and not 80, and if so, then you may misunderstand how alpha works.

But let's keep going a few more frames...

On the third frame, red will jump from 74 to 102, dr = 28.

On the 1000th frame, you'll probably notice it "stuck" at 252 (or 251 or 253, whatever the exact value was, at any rate short of 255).

Why?

Let's look at some math.  First, you've asked for an alpha of 40, and what does that mean?  It's really a fraction: 40/255ths. That's how much of the "new" color you want blended into the "old" color.

How much of the old color remains?  The inverse of your alpha, (255-40)/255 or 215/255ths.  So that your alpha, plus the inverse, equals exactly 255/255 or 1.0 - that's important.

So, on the first frame:  0 (existing red) * 215/255 (inverse alpha) + 255 (requested red) * 40/255 (alpha) = 40.

On the second frame:  40 (existing red) * 215/255 (inverse alpha) + 255 (requested red) * 40/255 = 73.7

Et cetera.  In short, at each frame you'll effectively get a "fraction of the fraction" - you are definately NOT simply adding 40 to red each frame.  (which is called additive blending, not alpha blending)

Eventually you'll reach a point where the difference in the calculation is < 1 (integer) - at which point you can add that number forever and the integer rgb values will never increment - in other words it gets "stuck".

So, yes, *in theory* infinitely stacking those alpha reds would give you 255, but *in practice* it won't.  You end up with hundreds of accumulated frames of integer rounding error by the time you get close enough to get stuck.

This is compounded, though only slightly, by the common practice amongst programmers to use /256 (which can be optimized with shift operations) instead of /255 in things like alpha calculations.  The difference there though is slight and would probably only change whether it gets stuck at 251 or 252. (for example)

There are workarounds, but they can be complicated and/or performance drags.  Like building your own intermediate floating or fixed point buffers to handle fractional rgb values and then converting down to integers only when needed for display.  But that's a huge long topic in itself, and I've rambled long enough.  

Hope that helps,

Using colorMode(RGB, 1.,1.,1.,1.) would help.  I find that way more intuitive anyway.  And seems to have less rounding issues because you're using floats.