Sorry if my question overlaps with BUG 132 (Finish Blending modes)-it wasn't clear to me.

BLEND mode seems to work differently than the other blending modes (ADD, SUBTRACT, DARKEST and LIGHTEST). This issue seems to be consistent across blend(), PImage.blend() and blendColor()].

Based on my very unscientific testing, I needed (at least) to have the alpha value of the 2nd (color/image)arg below 255 to see any changes using BLEND mode. The other modes work fine when the alpha for both colors/images is kept at 255. Here are 2 examples illustrating this.

alpha at 255
Code:

size(300, 500);
noStroke();
int [] modes = {
  BLEND, ADD, SUBTRACT, DARKEST, LIGHTEST};
color c1 = color(200, 200, 0);
color c2 = color(200, 0, 200);
for (int i=0; i<5; i++){
  for (int j=0; j<3; j++){
    switch(j){
    case 0:
	fill(c1);
	break;
    case 1:
	fill(blendColor(c1, c2, modes[i]));
	break;
    case 2:
	fill(c2);
    }
    rect(100*j, 100*i, 100, 100);
  }
}
 

Same code with alpha of 2nd arg set below 255
Code:

size(300, 500);
noStroke();
int [] modes = {
  BLEND, ADD, SUBTRACT, DARKEST, LIGHTEST};
color c1 = color(200, 200, 0);
color c2 = color(200, 0, 200, 150);
for (int i=0; i<5; i++){
  for (int j=0; j<3; j++){
    switch(j){
    case 0:
	fill(c1);
	break;
    case 1:
	fill(blendColor(c1, c2, modes[i]));
	break;
    case 2:
	fill(c2);
    }
    rect(100*j, 100*i, 100, 100);
  }
}
 

I guess what I'm not getting is why isn't BLEND mode just a simple averaging of color components (including alpha)–something like this:

Code:

size(300, 100);
noStroke();
color c1 = color(200, 200, 0);
color c2 = color(200, 0, 200);

// average components w ugly bitwise ops
int a = ((c1 >> 24 & 0xFF) + (c2 >> 24 & 0xFF)) >> 1;
int r = ((c1 >> 16 & 0xFF) + (c2 >> 16 & 0xFF)) >> 1;
int g = ((c1 >> 8 & 0xFF) + (c2 >> 8 & 0xFF)) >> 1;
int b = ((c1 & 0xFF) + (c2 & 0xFF)) >> 1;
color cBlend = (a << 24) | (r << 16) | (g << 8) | b;

fill(c1);
rect(0, 0, 100, 100);
fill(cBlend);
rect(100, 0, 100, 100);
fill(c2);
rect(200, 0, 100, 100);

 

I suspect many people (especially beginners) would initially think of blending as averaging.

for the exact specifics, hopefully toxi will chime in, who wrote those blending modes. my understanding was that this is the "standard" math as per the porter-duff rules. but yes, the alpha of the second image is the control, which as davbol points out, makes sense for images, not so much for individual pixels.

lerpColor() is what you'd want to just mix colors.

i think one confusion might be that BLEND is actually MULTIPLY, and should maybe be named that instead. that part is perhaps more along the lines of bug #132, in which i'd prefer the naming to be consistent with what illustrator, photoshop, and flash use since those are what people will be familiar with.

the general thing of bug #132 is just straightening all these things out.. i haven't had a chance to look into how these map to more standard software, and/or other blending modes that we're missing. **if anyone wants to pitch in on this, it would be most appreciated**

this has been really helpful to have you working on your book, ira (i assume you're still doing so) so that we can get these inconsistencies ironed out. keep posting!

edit - yes, starting with the gimp code might be useful for things that aren't covered.

here's the bug report/feature request:
http://dev.processing.org/bugs/show_bug.cgi?id=132
i've added more information there, let's follow up from that, so it can be tracked properly.