finish adding DIFFERENCE, MULTIPLY, SCREEN, OVERLAY, HARD_LIGHT, SOFT_LIGHT
to PImage before 1.0 final.

make sure all the blend modes and their names jive with how they're named
programs like photoshop, illustrator, director, and flash. naming in those
applications will take priority over technical names from the computer
graphics field because our audience will be more familiar with the
applications than the cg research.

quasimondo found this list of functions:
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
HARD_LIGHT: C = A < 128 ? (2*A*B/255) : 255-2*(255-A)*(255-B)/255
SOFT_LIGHT: C = B < 128 ? 2*((A>>1)+64)*B/255 :
255-(2*(255-((A>>1)+64))*(255-B)/255)
in addition to those that were already written into PImage by toxi.

modes for popular applications:


photoshop: normal, dissolve; darken, multiply, color burn,
linear burn; lighten, screen, color dodge, linear
dodge; overlay, soft light, hard light, vivid light,
linear light, pin light, hard mix; difference,
exclusion; hue, saturation, color, luminosity

illustrator: normal; darken, multiply, color burn; lighten,
screen, color dodge; overlay, soft light, hard light;
difference, exclusion; hue, sat, color, luminosity

director: Copy, Transparent, Reverse, Ghost, Not copy,
Not transparent, Not reverse, Not ghost, Matte, Mask;
(below seems more useful:
Blend, Add pin, Add, Subtract pin, Background transparent,
Lightest, Subtract, Darkest, Lighten, Darken

flash: not yet determined (anyone who wants to add, please do so).

discussed in quasimondo's thread here:
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_Software;action=display;num=1082056702

and on the beta board here:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Suggestions;action=display;num=1124112241

useful things to help, even for non-coders:
- if someone could provide a list of the modes for flash, that would be great
- if someone could work out how the naming works across all these
applications (how things are named differently in director vs. photoshop,
for instance) that would also be helpful. this information along with the
blending constants already built into processing (see PConstants.java and
PImage.java) would be invaluable to getting this finally implemented.
essentially a table that includes rows for each blending mode with columns
that contain 1) the math for the function 2) the function name in
processing 3) function name in photoshop 4) the function name in
illustrator 5) and so on...

updated list of modes, with their ordering in their various UIs:

photoshop:
normal, dissolve
darken, multiply, color burn, linear burn
lighten, screen, color dodge, linear dodge
overlay, soft light, hard light, vivid light, linear light, pin light, hard mix
difference, exclusion
hue, saturation, color, luminosity

illustrator:
normal;
darken, multiply, color burn;
lighten, screen, color dodge;
overlay, soft light, hard light;
difference, exclusion;
hue, sat, color, luminosity

director:
Copy, Transparent, Reverse, Ghost, Not
copy, Not transparent, Not reverse, Not ghost, Matte, Mask;
(below seems more useful:
Blend, Add pin, Add, Subtract pin, Background transparent,
Lightest, Subtract, Darkest, Lighten, Darken

flash (don't have the order for these)
add, alpha, darken, difference, erase
hardlight, invert, layer, lighten,
multiply, normal, overlay, screen, subtract
http://livedocs.macromedia.com/labs/as3preview/langref/flash/display/BlendMode.html
(reference also includes math for the very basic versions)

gimp:
normal, dissolve, multiply (burn), divide (dodge),
screen, overlay, difference, addition, subtract,
darken only, lighten only,
hue, saturation, color, value

and to reiterate, to help us with this one:

if someone could work out how the naming works across all these
applications (how things are named differently in director vs. photoshop,
for instance) that would also be helpful. this information along with the
blending constants already built into processing (see PConstants.java and
PImage.java) would be invaluable to getting this finally implemented.

essentially a table that includes rows for each blending mode with columns
that contain 1) the math for the function 2) the function name in
processing 3) function name in photoshop 4) the function name in
illustrator 5) and so on...

edit]
the original Porter-Duff paper

the original porter-duff paper that includes the blending rules for images.
these cover some, but not all, of the blending modes.

the naming is also different, these are "programmer's" names, and i'd prefer
that we avoid them and use the naming from mainstream applications with which
our audience is familiar.

Please feel free to borrow ideas from this unfinished work:
http://www.davebollinger.com/works/compositor/
There are a few scattered comments in the code intended for the P5 team to
(hopefully) help convert from my coding style to what\'s currently in P5.

RE: the Porter-Duff paper
I'd agree to stay away from the P-D modes. (other than a over b, which is "NORMAL"
according to 99% of all mode naming in other products) Those modes are "theory"
as opposed to implementation. It's like consulting an algebra book, when all you
want is the given formula for compound interest.

I'd vote to use photoshop's names whenever possible. And in many cases avoiding
Director's names, as some are just weird, sounds like it was written by programmers
for programmers. (I don't use it, so I don't know) "Not Copy"?! WTF?

Add/Subtract (clipped to 0..255) photoshop calls these linear dodge/burn. Director
calls them add/subtract pin. Why you'd ever want the "un-pinned" (aka modulo)
version is beyond me. Unless you want to accomplish a subtraction with the addition
operator, or vice versa, (yea binary math!) or just have some burning desire to
implement it for completeness sake without regard to artisitic usefulness.

Director's darken/lighten (as opposed to darkest/lightest) are probably dodge/burn.
So then Director's darkest/lightest is what everyone else would call darken/lighten
(where you pick min/max channel values)

Difference and Multiply ought to be slam dunks. Not only is it painfully obvious what
the implied operation is, but they're also symmetric operations - order of inputs
doesn't matter.

My hunch is that screen/overlay/exclusion are also pretty standard in name/function.

Here's as good as I can do, hope its helpful.

I couldn't figure out how to do an attachment, so if you could grab this file:

http://www.davebollinger.com/works/compositor/PImage_WithNewBlendModes.txt

Then review, copy and paste, revise as appropriate.

hm, to do the attachment, you click \

edit]
sample code changes to PImage for new blend modes

edit]
real working code for the new blend modes, plus example .pdf, plus jpgs of
results

Finally got a build environment set up to compile this. Pulled from 0124 Beta
cvs on 2006-12-18, added new blend modes Compiles clean, sample sketch works.
Obsoletes the prior sample code.

k, thanks.. i'm checking in with casey to see what our plan is for these.

(fwiw, don't mark things as a 'patch' unless they're an actual patch file,
which is a plain text file of the diffs to be used by the unix 'patch'
command.)

edit]
Proposed DODGE/BLEND modes, code & diff, example sketch, sample jpg

Purely for your consideration since not in the original list of blend modes to
be implemented, but a couple other "common" ones are dodge and burn. In
Photoshop-speak these would be "Color Dodge" and "Color Burn" because they
apply per-channel (fe, you could burn just red, or dodge just blue, given the
proper overlay image) as opposed to dodg/burn-ing based on luminance or alpha
or some other all-channel value.

..and if you chose to implement it, one performance issue..

In the code as submitted above, there are calls to peg() within the "formula" section
of blend_dodge() and blend_burn(). Despite the comments there, those calls should
not be necessary within the p5 framework. They are remnants of being pulled from
code where rgb is pre-scaled by alpha, and with those 16-bit values overflow during
the subsequent alpha calc was a concern. Overflow should never occur in the 8-bit p5
alpha blend, so "pre-peg()-ing" the divisions will be an unnecessary performance
hit. So just remove "peg(" and ")" from each of the three lines in the "formula"
section of each blend function. Feel free to ask for further clarification if needed.

thanks for looking into all of this. i've been swamped and haven't been
able to go through everything and get it implemented, but it will certainly
be happening soon.

now implemented for 0125. thanks for your help, these turned out to be
important to have finished up for 1.0.

also added EXCLUSION, though i'm not sure if the implementation is correct.

Exclusion looks correct, typically given as A+B-2AB, functionally equivalent.

Glad I could be of some help. Am looking forware to 0125. :)

BTW, i stumbed across the SVG 1.2 spec, if you'd like an "official" document to
reference: http://www.w3.org/TR/SVG12/rendering.html (skip all the duplicated
porter-duff stuff, find blend modes following, though note that even they put "not yet
verified" type wording on some equations!)

Finally, Aside, FWIW: the disclaimer should be that p5 uses "fast" code, not
necessarily "correct" code. No biggie, it seems most software does. A nitpicker would
find numerous "off by 1 division" problems in the blend code (including toxi's original
alpha blend and the new blend modes as i submitted) where >>8 or >>7 is used
when strictly speaking /255 or /127 should have been used. For instance, my own
version of exclusion (not intended for real-time use) reads "r1 + r2 - ((2 * r1 * r2) /
255);" because 255==1.0 not 256==1.0. In other words: (255*255)>>8 !=
(255*255)/255. But for real-time use the shifts are preferrable, and I doubt the
difference is significant for any practical application.

good point. i've added your comments to the javadoc reference for blend(),
which is where we bury those sort of technical details. i'd never bothered
with the /255 vs /256 thing anywhere, so may as well start now.