blend-modes

1 files changed, 53 insertions, 0 deletions

diff --git a/docs/redesign.txt b/docs/redesign.txt
index 3566137a..b31d9672 100644
--- a/docs/redesign.txt
+++ b/docs/redesign.txt
@@ -12,6 +12,48 @@ information:
 	
 - behavior where both are present (blend mode)
 
+To get the existing porter/duff operators, we need three blend modes:
+
+   SOURCE, DEST, ZERO
+
+To get the ADD operator, we need an ADD blend mode.
+
+As long as blend modes satisfy
+
+   Blend (white, white) = white,
+
+we can define their effect on intersection of the alpha channels
+intersection as simply Blend (1, 1) and still get the correct behavior
+for the existing PDF operators. Also the existing Add can be defined
+that way.
+
+Unfortunately, DIFFERENCE and EXCLUSION don't satisfy this, so it may
+be interesting to instead define:
+
+   INV_DIFFERENCE = 1 - |s - d|
+   INV_EXCLUSION = 1 - ((s + d) - 2sd)
+
+These will produce 1 in the alpha channel if the source and
+destination are both 1 as expected. To get the original blend modes,
+the user can do first an INV_DIFFERENCE/INV_EXCLUSION followed by
+another INV_DIFFERENCE/INV_EXLCUSION with a black (1, 0, 0, 0) source.
+
+The LINEAR_DODGE blend mode is similar to ADD, but the alpha channel
+should act like the usual s + d - sa. We can achieve that by defining
+it as LINEAR_DODGE = MIN(s + d, 1).
+
+Divide-by-zero: This is an annoying problem. A way around it might be
+to simply specify that "0" in an alpha channel is defined as epsilon,
+where epsilon is a very very small positive value. This solves
+divide-by-zero and allows formulas to be simplified.
+
+HDR/ Values above [0,1]. Another annoying problem. A lot of the blend
+modes and operators really assume that everything happens within the
+[0,1] interval. Can we specify a transformation that maps
+-infinity,infinity into 0,1, and then call that before and after? The
+answer is likely that HDR images should be converted to some linear
+color space before blending, and then the result should be converted
+back.
 
 
 API notes:
@@ -67,6 +109,17 @@ Compositing transformed polygons is just a nasty problems because they
 have to be rasterized before transforming to get reasonable
 performance. 
 
+This might be a clue that polygons should not be considered
+image. Maybe they should be considered primtives instead. Potential
+primitives:
+
+	- spans
+	- polygons
+	- regions
+	- rectangles
+	- triangles, traps
+
+this is closer to how a GPU operates.
 
 
 Out-of-memory: