[cairo] Blend modes take 3

[Bill Spitzak]

Soeren Sandmann wrote:

> The PDF modes are all based on a modification of the Porter/Duff OVER
> operator. In the Porter/Duff paper alpha is treated as coverage, and
> the operators are characterized by the contribution of source and
> destination in the four areas "Covered by source only", "Covered by
> destination only", "Covered by both" and "Covered by None". Here are
> the characterizations of some of the operators:
> 
>           SRC            DEST              BOTH            NONE
> 
> OVER       S              D                 S               0
> OVER_REV   S              D                 D               0
> IN         0              0                 S               0
> IN_REV     0              0                 D               0
> 
> In this framework, the PDF operators all look like this:
> 
> PDF_OP     S              D               f(D, S)           0
> 
> where f(D, S) depends on the blend mode. For the NORMAL blend mode we
> have f(D, S) = S, which is the same as OVER, so Benjamin doesn't add
> that one. For the MULTIPLY blend mode, f(D, S) = D * S, etc.

Goes on to suggest something like:
   PDF_IN     0              0               f(D, S)           0

This is interesting but a few notes on this:

1. There are nowhere near as many combinations as it first looks. All of 
the f(D, S) only do something useful if both are non-zero, otherwise 
they are equivalent to S+D. This means there is no need for that in any 
column other than "BOTH". There are therefore 4 entries for each f(D,S) 
and a total of 4*N operations, not 4^N as suggested.

All the Porter-Duff operators fit in this, with the following 3 f(D,S) 
functions:

	             00       S0       0D       SD
	f(D,S) = 0 : clear    src_out  dst_out  xor
	f(D,S) = S : src_in   src      src_atop src_over
	f(D,S) = D : dst_in   dst_atop dst      dst_over

Therefore the number of operators is, for N new compositing operations, 
(N+3)*4, not the (N+3)^4 that it first seems.

2. Actual implementation in premultiplied space is done by plugging 
f(D,S) into the following function, where A is source color, a is source 
alpha, B is dest color and b is dest alpha:

   color = ab*f(A/a,B/b) + (1-a)B + (1-b)A
   alpha = a+b-ab

This function is then algebraically simplified, sometimes a lot, before 
being used in the code.

The other 3 functions would be done by removing the (1-a)B and/or the 
(1-b)A and changing the alpha function to the corresponding Porter-Duff 
one from the f(D,S)=S row. I think some of these do not simplify as nicely.

3. Bounded/unbounded decisions would have to be made about all the 
combinations. Only "clear" and "src" are bounded in Cairo now, but these 
are in two different columns and rows of the above table, which means 
the decision may not be obvious.

4. I am not certain these can be emulated exactly on a backend that can 
only do PDF. ((A in B) over B) is not the same as (A atop B): if B has 
an alpha of .5 and A has an alpha of 1, the first is A/2+B/2 while the 
second is A/2. I'm afraid similar mistakes would show up trying to 
emulate these.

5. The current Cairo operator ADD and perhaps SATURATE do not obey this 
scheme. If for ADD you assume f(S,D)=S+D, then the formulas are 
something like this:

   color = f(A,B)
   alpha = f(a,b) (possibly clamped to 0,1?)

If may make sense to add this as a fifth combination. In our software we 
did this due to user demand. The OVER operation (and PDF overlay) are 
unchanged by this so there are 2 less.

-- 
Bill Spitzak, Senior Software Engineer
The Foundry, 618 Hampton Drive, Venice, CA, 90291, USA
Tel: +1 310 399-4555 * Fax: +1 310 450-4516 * Web: www.thefoundry.co.uk
The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027