I'm aware of the caveat that the blend operations are "fast not accurate" - primarily
due to "255/256" type round-down issues caused by ">>8" type equations, but for
some blend ops the error results in more severely impaired functionality.

Case is point is ADD, and I guess I'm wondering if a hint mode for toggling accurate
blend math should be added, or something like that - I'm not quite sure exactly
what to suggest, just starting a discussion for ya...

One likely use of ADD blending would be to accumulate many small color values,
eventually pinning at white 255. Problem is, the round-down occurs at *each* add,
and the rounding errors accumulate quite dramatically.

For example, 16 sequential ADDs of the color(16) do not == 256 pinned to 255.
Rather they round down by 1 on each step, giving only 240 at the end:

color gray = color(16);
color accum = color(0);
for (int i=0; i<16; i++) {
accum = blendColor(accum, gray, ADD);
println("i = " + i + " accum = " + red(accum)); // 15,30,45,60..240
}

And of course, the smaller the color value and greater number of accumulation steps,
the greater the error. (32 adds of color(8) gives only 224)

(in contrast, note that this problem does NOT occur in reverse with the SUBTRACT
blend mode (255 - 16 does == 239) because the rounding occurs in the "right"
direction - though really just coincidentally, not by design per se)

I could probably volunteer to write the "slower but accurate" version of blend_add_pin
() if ur interested

sure, that would be helpful, thanks.

edit]
alternative ADD blend mode implementation

just the code in question

edit]
a testbed sketch with addional esoterica

contains some random musings and ramblings that might be of interest when
you're otherwise bored or faced with wanting to correct other blend mode
implementations, otherwise discard

regarding the testbed sketch attachment...

you can safely ignore it unless you want to also worry about such issues as:

color c = blendColor(color(255), color(254), SUBTRACT);
println(red(c) + ", " + green(c) + ", " + blue(c)); // 1.0, 1.0, 2.0!

at which point it might help address the other modes too. also contains some
thoughts on performance. cheers

*** Bug 1146 has been marked as a duplicate of this bug. ***