Bug 1008 : Blending innacuracies (particularly ADD)
Last modified: 2009-02-20 10:59



Assigned To:

Attachment Type Created Size Actions
alternative ADD blend mode implementation text/plain 2008-11-14 11:10 812 bytes
a testbed sketch with addional esoterica text/plain 2008-11-14 11:12 4.69 KB

Description:   Opened: 2008-11-13 09:22
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
Additional Comment #1 From fry 2008-11-13 16:35
sure, that would be helpful, thanks.
Additional Comment #2 From davbol 2008-11-14 11:10
alternative ADD blend mode implementation

just the code in question
Additional Comment #3 From davbol 2008-11-14 11:12
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
Additional Comment #4 From davbol 2008-11-14 11:16
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
Additional Comment #5 From fry 2009-02-20 10:59
*** Bug 1146 has been marked as a duplicate of this bug. ***
This bug is now being tracked here.