 |
Author |
Topic: More blend() modes (Read 1977 times) |
|
Quasimondo
 
|
More blend() modes
« on: Apr 15th, 2004, 9:18pm » |
|
I would love to see some more Photoshop-alike blending modes for the blend() function. As I don't know how to change the processing sourcecode myself here's the formulas:
DIFFERENCE: C = abs(A-B);
MULTIPLY: C = (A * B ) / 255
SCREEN: C= 255 - ( (255-A) * (255-B) / 255 )
OVERLAY: C = B < 128 ? (2*A*B/255) : 255-2*(255-A)*(255-B)/255
HARDLIGHT: C = A < 128 ? (2*A*B/255) : 255-2*(255-A)*(255-B)/255
SOFTLIGHT: C = B < 128 ? 2*((A>>1)+64)*B/255 : 255-(2*(255-((A>>1)+64))*(255-B)/255)
|
Mario Klingemann | Quasimondo | Incubator | côdeazur
|
|
|
toxi_
Guest
|
Re: More blend() modes
« Reply #1 on: Apr 16th, 2004, 4:57pm » |
|
to prevent feature creep and give people more control, there was an idea to only implement a mechanism for custom blend modes, the actual functions for which would be part of your main sketch though. it could work something like this:
Code:void draw() {
blend(img,0,0,10,10,0,0,width,height,BLEND_CUSTOM1);
}
// example: custom dissolve blend function
int blend_custom1(int a, int b, int f) {
return (Math.random()*0xff>f) ? a : b;
} |
|
if there'd be say 10 "slots" for custom blend modes, would that make you happy? 
|
|
|
|
|
Quasimondo
|
Re: More blend() modes
« Reply #2 on: Apr 16th, 2004, 5:20pm » |
|
That sounds perfect.
Is there a reason why this is limited to 10? Couldn't I simply use any function as an argument? Or is that something that's not allowed in Java?
|
Mario Klingemann | Quasimondo | Incubator | côdeazur
|
|
|
fry
|
Re: More blend() modes
« Reply #3 on: Apr 16th, 2004, 5:49pm » |
|
you can sorta use a function as an argument in java, but it requires reflection, which sadly would be prohibitively slow for something like a blending mode whcih operates per pixel.
a tiny internal class could also do it, but we're hesitant to add classes to the main api except for things used very heavily.
|
|
|
|
|
Quasimondo
|
Re: More blend() modes
« Reply #4 on: Apr 16th, 2004, 8:29pm » |
|
Oh now I see - of course - the overhead for the function call would sent the performance down into the cellar.
So does this work like a kind of compiler macro then (in java??)? Maybe you can point me to some java documentation how you think of handling this instead? Or at least soem google keywords?
|
Mario Klingemann | Quasimondo | Incubator | côdeazur
|
|
|
REAS
|
Re: More blend() modes
« Reply #5 on: Apr 16th, 2004, 10:14pm » |
|
I don't think add a few more blending modes (in addition to the custom function) would hurt. Keeping in mind that many Processing users are very much beginners and many are familar with Director or Photoshop, we could support about 9 basic modes in addition to the custom option.
I can't remember, what is keeping us from moving to:
Code:
|
|
|
|
|
toxi_
Guest
|
Re: More blend() modes
« Reply #6 on: Apr 16th, 2004, 11:39pm » |
|
...only ourselves and the lack of any final word really, casey 
the blendMode() function was my original proposal, though then i hoped this setting would apply to all drawing functions, also shapes etc. but even if we don't support that (yet) - the change to use blendMode() as global setting for all blend() calls would be quite trivial to do.
in any way, thanks mario for the digging out the equations!
|
|
|
|
|
fry
|
Re: More blend() modes
« Reply #7 on: Apr 17th, 2004, 1:18am » |
|
if we can figure out the proper set of blend modes & their names--prolly the 'useful' ones from photoshop or director--that would be a good start for the target. and we can start by getting them into the image api as toxi has done, since that's a constrained & useful chunk of it.
as for the whole graphics engine, there are currently several spots in the engine that touch pixels, so we'd have to tweak each one to get proper blending in there.. not undoable, and some of that code is due for a cleanup to improve its speed (and avoid a situation where lots of functions that uh.. deal with pixels), but it would prolly be a lower priority than some of the basics like getting thick strokes to work on lines, or fixing how images or lights work, or getting the new graphics engine in there, or ..
re: how do you make things quick in java.. if a function is private and/or final, it can be inlined by the compiler (at its discretion), so that can often help. another is with the hotspot compiler, supposedly there is some real time inlining of this sort of thing, and it uses private/final as the cue for it (though this comes at the expense of many compilers no longer bothering to inline..) other than that, you're kinda out of luck, and just have to work around/avoid it.
|
|
|
|
|
kevinP
|
Re: More blend() modes
« Reply #8 on: Apr 17th, 2004, 7:05pm » |
|
on Apr 16th, 2004, 4:57pm, toxi_ wrote:to prevent feature creep and give people more control, there was an idea to only implement a mechanism for custom blend modes, the actual functions for which would be part of your main sketch though. it could work something like this:
Code:void draw() {
blend(img,0,0,10,10,0,0,width,height,BLEND_CUSTOM1);
}
// example: custom dissolve blend function
int blend_custom1(int a, int b, int f) {
return (Math.random()*0xff>f) ? a : b;
} |
|
if there'd be say 10 "slots" for custom blend modes, would that make you happy |
|
Is this what is known as a callback Where you pass a reference to a function to another function
-K
|
Kevin Pfeiffer
|
|
|
TomC
|
Re: More blend() modes
« Reply #9 on: Apr 17th, 2004, 9:01pm » |
|
on Apr 17th, 2004, 7:05pm, K wrote:
Is this what is known as a callback Where you pass a reference to a function to another function
-K |
|
I don't think so. The blend mode parameter is just an int which is used to choose which function to call. I think that the custom blend functions would be defined in BApplet, but they wouldn't do anything. You could then override them in your own applet (since it is a subclass of BApplet) and provide whatever functionality you needed.
You can see the same technique in this code...
Code:
static final int PLUS = 1;
static final int MINUS = 2;
static final int CUSTOM = 3;
class IntCalc {
int calculate(int a, int b, int type) {
int result = 0;
if (type == PLUS) {
result = plus(a,b);
}
else if (type == MINUS) {
result = minus(a,b);
}
else if (type == CUSTOM) {
result = custom(a,b);
}
return result;
}
int plus(int a, int b) {
return a+b;
}
int minus(int a, int b) {
return a-b;
}
// does nothing, should be overridden
int custom(int a, int b) {
return 0;
}
}
class CustomIntCalc extends IntCalc {
// overrides custom from IntCalc to do something useful
int custom(int a, int b) {
return a*b;
}
}
void setup() {
int a = 5;
int b = 10;
IntCalc intCalc = new IntCalc();
println("using IntCalc:");
println( "a + b = " + intCalc.calculate(a,b,PLUS) );
println( "a - b = " + intCalc.calculate(a,b,MINUS) );
println( "a custom b = " + intCalc.calculate(a,b,CUSTOM) );
CustomIntCalc customIntCalc = new CustomIntCalc();
println("using CustomIntCalc:");
println( "a + b = " + customIntCalc.calculate(a,b,PLUS) );
println( "a - b = " + customIntCalc.calculate(a,b,MINUS) );
println( "a custom b = " + customIntCalc.calculate(a,b,CUSTOM) );
}
|
|
|
| « Last Edit: Apr 17th, 2004, 9:04pm by TomC » |
|
|
|
|
|
