Premultiplication
DEAR LORD!!!... there is NOTHING that causes more problems for students of Nuke (and their teachers) than premultiplication. No matter how carefully it is explained, students often dont know how to use it, or use it badly. Several of the items in the script structure page refer to the perils of poorly managed premultiplication. First, here is why premultiplication is needed:
Contents |
What is premultiplication and why it is needed
All images consist of values that extend from black to white (the three color channels being simply grey-scale images) and these values can be expressed as numbers: 1 for white, 0 for black, .5 for mid grey etc. The problem is that there is no natural value in a digital image for transparency. However, with simple maths we can 'fake' it. First of all we need:
A background (BG), a foreground (FG) and an alpha (A)
Now listen...
- 1 X any number = no change
- 0 X any number = 0
From that we can say:
- The white values (1) in A multiplied by the FG will effect no change upon the FG.
- The black values (0) in A multiplied by the FG will turn the FG black.
As below:
Now invert A so that its black values and white values are 'swopped'. Perform the same multiplication over the BG.
Now more maths:
- 0 + any number = no change
So....
- The blacks values (0) in the BG will effect no change upon the FG values.
- The blacks values (0) in the FG will effect no change upon the BG values.
This gives us a FG plus a BG that looks like (voila!):
The example .psd file is in the Assets page (apologies, the alpha is a bit rough).
What happens if premultiplication is not handled well
If premultiplication is not handled well then the maths fails. The following are the main dangers:
- If the black of the premultiplied FG is lightened (for example: as a result of a color adjustment), then it will brighten the BG.
- This is not a good thing. In the image below the ball was lightened but the color correction of the one on the right was not preceded by an unpremultiply (Unpremult). In the process the black premultiplied background was also lightened which affected the color of the composite.
- If (in the process of poorly managed premultiplication workflow) the grey of the soft edges is darkened or lightened then the edges of the composite will be noisy.
- This is not a good thing. In the image below the ball on the right was premultiplied twice. This imparted a dark rim to the edge of the ball (soft edges are very vulnerable to this sort of thing).
The main places this these screw-ups occur is whilst the FG is being color edited or merged:
Merging
The standerd workflow for dealing with premultiplication whist merging is simple:
- Derive an alpha from the FG
- Premultiply FG by A
- Merge (add) FG with BG
This translates as:
|
|---|
| When it is time for the FG and BG to be merged together then the FG MUST be in a premultiplied state. |
| Also... DON'T premultiply the same image twice. |
Color editing
This is wrong:
- Premultiplied image --> Color edit
Such a workflow could badly effect the black values of the premultiplied image. The solution is to unpremultiply before the color edit, like this:
- Premultiplied image --> Unpremultiplied image --> Color edit --> Premultiply
Therefore:
|
|---|
| DONT perform any color edit on the FG if it has been premultiplied. |
Premult and Unpremult and other tools
The Premult and Unpremult are the workhorses of the premultiplaction workflow. Premult wil premultiply an image (asuming it has an alpha), Unpremult will unpremultiply it.
Within many nodes there is a premult parameter. It is there to save on the hassle of top and tailing the color operations with Premult and Unpremult nodes. If ticked it will unpremult and premult entirely within the confines of the node. It is not efficiant to use this parameter on long chains of complex color edits as the premultiplication is always being turned off and on, but for for simple, singular edits it is fine.
See also
Some examples of good and bad premultiplication are in the Assets page.
