New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blending innacuracies (particularly ADD) #172

Closed
processing-bugs opened this Issue Feb 10, 2013 · 7 comments

Comments

Projects
None yet
3 participants
@processing-bugs

processing-bugs commented Feb 10, 2013

Original author: b...@processing.org (June 07, 2010 01:09:30)

This bug automatically added from:
http://dev.processing.org/bugs/show_bug.cgi?id=1008

Comment from davbol, 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

Original issue: http://code.google.com/p/processing/issues/detail?id=133

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:31
Comment from fry, 2008-11-13 16:35

sure, that would be helpful, thanks.

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:31
Comment from fry, 2008-11-13 16:35

sure, that would be helpful, thanks.

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:31
Comment from davbol, 2008-11-14 11:10

Created an attachment (id=248)
alternative ADD blend mode implementation

just the code in question

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:31
Comment from davbol, 2008-11-14 11:10

Created an attachment (id=248)
alternative ADD blend mode implementation

just the code in question

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:32
Comment from davbol, 2008-11-14 11:12

Created an attachment (id=249)
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

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:32
Comment from davbol, 2008-11-14 11:12

Created an attachment (id=249)
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

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:32
Comment 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

processing-bugs commented Feb 10, 2013

From b...@processing.org on June 07, 2010 01:09:32
Comment 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

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 7, 2015

Contributor

Still a problem:

// blends background onto itself again and again
// result: white rectangle fades away after 255 frames

void setup() {
  size(500, 500);
  background(0);
  fill(255);
  rect(100, 100, 300, 300);
}

void draw() {
  PImage img = g.get();
  println("pre: ", hex(get(250, 250)));
  println("img: ", hex(img.get(250, 250)));
  blend(img,
        0, 0, width, height,
        0, 0, width, height,
        BLEND);
  flush();
  println("post:", hex(get(250, 250)));
  println("----");
}

Output:

pre:  FFFFFFFF
img:  FFFFFFFF
post: FFFEFEFE
----
pre:  FFFEFEFE
img:  FFFEFEFE
post: FFFDFDFD
----
pre:  FFFDFDFD
img:  FFFDFDFD
post: FFFCFCFC
----
pre:  FFFCFCFC
img:  FFFCFCFC
post: FFFBFBFB
----
pre:  FFFBFBFB
img:  FFFBFBFB
post: FFFAFAFA
----
pre:  FFFAFAFA
img:  FFFAFAFA
post: FFF9F9F9
Contributor

JakubValtar commented Aug 7, 2015

Still a problem:

// blends background onto itself again and again
// result: white rectangle fades away after 255 frames

void setup() {
  size(500, 500);
  background(0);
  fill(255);
  rect(100, 100, 300, 300);
}

void draw() {
  PImage img = g.get();
  println("pre: ", hex(get(250, 250)));
  println("img: ", hex(img.get(250, 250)));
  blend(img,
        0, 0, width, height,
        0, 0, width, height,
        BLEND);
  flush();
  println("post:", hex(get(250, 250)));
  println("----");
}

Output:

pre:  FFFFFFFF
img:  FFFFFFFF
post: FFFEFEFE
----
pre:  FFFEFEFE
img:  FFFEFEFE
post: FFFDFDFD
----
pre:  FFFDFDFD
img:  FFFDFDFD
post: FFFCFCFC
----
pre:  FFFCFCFC
img:  FFFCFCFC
post: FFFBFBFB
----
pre:  FFFBFBFB
img:  FFFBFBFB
post: FFFAFAFA
----
pre:  FFFAFAFA
img:  FFFAFAFA
post: FFF9F9F9

@JakubValtar JakubValtar added revised and removed revision needed labels Aug 7, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 7, 2015

Member

Is it fixable without just making things impossibly slow?

Member

benfry commented Aug 7, 2015

Is it fixable without just making things impossibly slow?

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Aug 7, 2015

Contributor

See #258 (comment), adding one apparently greatly reduces the error. Will test and get back to you with results.

Contributor

JakubValtar commented Aug 7, 2015

See #258 (comment), adding one apparently greatly reduces the error. Will test and get back to you with results.

@JakubValtar JakubValtar self-assigned this Aug 11, 2015

@JakubValtar JakubValtar removed the revised label Aug 11, 2015

@benfry benfry added the high label Aug 11, 2015

@benfry benfry added this to the 3.0 final milestone Aug 11, 2015

@benfry benfry closed this in #3592 Aug 14, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment