About Keying and Spill Suppression |
This section discusses different strategies for pulling keys by combining nodes in different ways. If you are not familiar with Primatte and Keylight (Shake's primary bundled keyers), you are encouraged to read those tutorials prior to this section.
Keying can be loosely defined as the creation of a new Alpha channel based upon the pixel color (a pure blue pixel, for example), luminance (a very dark pixel) or Z depth (a pixel 300 Z units away, for example) in an image. Keying is discussed as a separate process from masking, which can be loosely defined as the creation of an Alpha channel by hand through the use of painting, rotosplines, or imported Alpha masks from 2D or 3D renders in other software packages. Those techniques are discussed in About Masking.
Pulling a Bluescreen
or Greenscreen
Three nodes are included with Shake to pull blue or greenscreen keys. They are Primatte, Keylight and ColorReplace. There are tutorials devoted to Primatte and Keylight in the Tutorials section. There is also a ChromaKey node in the Key tab, but for some reason, it completely sucks. No kidding. The same model and parameters appear in ColorReplace, but ColorReplace works much better. Go figure.
You should also investigate Ultimatte, a third-party keyer with a long and Oscar-winning history of production use. Contact Ultimatte for more information. It kicks ass in a completely law-abiding, non-violent, politically correct fashion.
Keying in Primatte - see Primatte Tutorial.
Keying in Keylight - see Keylight Tutorial.
Keying with ColorReplace - ColorReplace is not the best keying tool, but it is a quick node for making hacky garbage masks.
![]() |
![]() |
Set the following parameters:
You use the Invert because ColorReplace puts white in the Source Color area of the Alpha channel you have to invert it for the Over node.
You can see there is some crunchiness, particularly in the hair to the right of her mouth. This shows why ColorReplace is usually used to pull a key to mask other operations like color correctors rather than the actual composite. There are examples of using ColorReplace later.
Combining Keyers
You get the most flexibility when you combine keyers. Both Primatte and Keylight allow you to input a holdout matte. There are at least three typical ways of combining keys:
You can combine keys with the holdout matte input. Typically, you pull a basic key for soft edges and reflections. You also pull a second key which is very hard, and then soften it with filters.
The following is an example using the Keylight sample images in doc/pix/keylight. The first image shows the initial key coming out of Keylight. The reflections are good, but there is some transparency near the seatbelt and steering wheel.
Next, a key is pulled with Primatte on the same bluescreen. With just foreground and background operators, the reflection is removed and the transparent areas filled in. This results in a very hard matte:
Then filters are attached to the Primatte node. A DilateErode
is added, and the xPixels is set to 1 this closes up any holes.
You can also use a Median filter to do the same thing. A second DilateErode
is applied, with the xPixels set to -5. This eats away at the matte.
This filtering process cleans up the matte, making it more solid. A Blur
softens it, and is fed into the third input of Keylight. The result is
a solid matte with soft edges:
|
|
The next way to combine keys is specifically for Primatte
using its arithmetic parameter. Normally when you pull a key in Primatte,
it replaces the Alpha mask in the foreground image. When the arithmetic
parameter is switched from replace to add, multiply or
subtract, you can combine the mattes within Primatte. In the following
tree, an initial key is pulled with ColorReplace, inverted, and then
the arithmetic is switched to add in the Primatte node
to combine them:
The last way to combine keys is to use Layer nodes. In
the following tree, a key is pulled with two different nodes and then combined
with a Max node, which takes the greatest pixel value. The elements are
combined with a KeyMix. Note that the KeyMix does not get an Alpha
channel since neither clouds or blonde have one. KeyMix
only mixes the two images through the mask you have pulled:
The following example uses an Over node instead of a KeyMix
node. This generates an Alpha channel out of the tree:
Applying Effects
to Bluescreen Footage
Problems can occur when you with apply effects to bluescreen footage. Suppose you want to blur your foreground but not the background. Your natural instinct is to apply a Blur node and then key and comp with Keylight. This is what we call A Real Bad Idea.
The following tree uses doc/pix/woman.iff and doc/pix/sky.jpg. The
woman image is courtesy of the short film Doppelganger.
When the blur is applied, a blue edge is introduced along her neck line:
![]() |
![]() |
So, being bright kids, maybe you can put the Blur after
the Keylight. Also A Real Bad Idea it blurs the background as
well:
![]() |
![]() |
Being particularly bright kids who always raised their hands
in class and signed up for things like Yearbook, perhaps you can mask the
blur with the key from Keylight. Hmm. Maybe you deserve to be chained
to your desks and your mouse superglued to your hand:
![]() |
![]() |
The problem with the above examples is that the keying node,
in this case Keylight, is asked to do too much it must simultaneously
key, suppress spill and composite. The solution is to use other nodes for
the compositing. In the following example, Keylight's output
parameter can be set to comp or on Black:
![]() |
![]() |
As a general principle, then, you should use Primatte's and Keylight's background inputs as test comps, to be later rewired into a composite with Over or KeyMix. This gives you several advantages:
Blue and Green
Spill Suppression
Once the compositing is pulled from the keyers and performed by KeyMix
or Over nodes, you can start to work with spill suppression. Blue spill
occurs when light is reflected off of the bluescreen and onto the foreground
material. For the following examples, use doc/pix/primatte/woman.iff
and bg.jpg. Notice there is quite a bit of bluespill on her shirt. In
the following tree, Primatte's output is set to Alpha only,
a holdout matte created for the line under her arm (with QuickPaint),
and foreground and background scrubs added. The comp is done with
the Over node, which has preMultiply turned on. You can see the
blue spill that remains:
![]() |
![]() |
You might think that it would look better if you switch Primatte's
output to comp and turn off the preMultiply in Over.
You'd be wrong and ridiculed and, in some countries, forced into hard labor
for 16 years with crazy people, political dissidents, and tv programmers.
This turns your blue edges into black edges, making them more difficult to
get rid of (techniques to help correct this are discussed in a bit...). Plus,
you still have the bluespill.
If you don't want to do bluespill correction in your keyers, here are several sample trees to help you:
Color Replace I:
This technique is nice because it is fast, but often simply
replaces blue spill with a different color. In the following tree, a ColorReplace
is applied to the foreground, replacing the blue with the color of the wall.
As always, increase the satFalloff to around 1. The head looks great,
but spill remains on the shirt, and there is now a horrible yellow edge around
the skirt:
![]() |
![]() |
To correct this, drop the valRange to 0 and the valFalloff
to approximately .4. Add a second ColorReplace to get rid of the bluespill
on her shirt. Carefully select the blue on the shirt, and then replace it
with a beige-white color. Also move all Range parameters to 0 and all
Falloff parameters to around .3. The shirt looks fine, but there is
still a yellow ring around her skirt:
![]() |
![]() |
Color Replace II:
A better technique is to use ColorReplace to mask a color
correction. Replace ColorReplace2 with a Monochrome node and
pipe Primatte directly into it. Then attach the output of ColorReplace1
as Monochrome1's mask, and turn on the affectAlpha parameter
in ColorReplace. This process turns off all saturation in the blue
areas, turning it grey. This is cool because the eye can detect luminance
levels better than saturation. The skirt and the shirt look good:
![]() |
![]() |
As an alternatives to Monochrome, you can use AdjustHSV or Saturation.
SpillSuppress:
This technique mathematically evaluates each pixel and compares
the blue and green strength. If the blue is significantly stronger than the
green, the blue is suppressed. The SpillSuppress node is under the
Key tab. This node tends to work better on bluespill than on greenspill
because of the luminance difference between the two. It also tends to push
your images to a yellow color.
![]() |
![]() |
HueCurves
Another node is HueCurves. This node enables you to perform
boosting of colors or saturaion based on the hue of the pixel you want to
affect. HueCurves works by loading a parameter into the Curve Editor
and tuning it ignore the text fields. The X axis is the hue, and the
Y axis depends on what parameter you are using. For this example, load the
saturation curve into the Curve Editor and grab the knot around .66,
since blue has a hue of 66 percent. Drag it down to decrease the saturation
for the blue pixels:
![]() |
![]() |
Edge Treatment
Another typical problem with keying (OK, well, it is the problem with keying) is edge treatment.
|
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
To correct this, go to the Mask input of DilateErode and select QuickPaint from the Mask pop-up menu. This attaches a mask to the DilateErode. Paint across the electrical wires. This only dilates where the wires are, which the opposite of what you want, so open the Mask sub-parameters in the DilateErode and enable invertMask:
Keying DV footage
First of all, what is wrong with you, trying to key off of DV? Do you actually get paid for that? Now with the obligatory yelling out of the way, let's see what can be done to salvage this dismal situation.
Here, you have shot your no doubt perfect bluescreen with your
shiny brand new DV camera. There is a small portion of an image in doc/pix/primatte
called dv.iff if you want to sing along. Key the image and place it
over a background (here, just a red field). You are no doubt horrified to
find blocky chunks spewed all over your image. That's not lunch, that's 4.1.1
signal, baby!
DV bluescreen | Key pulled on DV bluescreen |
![]() |
![]() |
What is up with this? In RGB colorspace, each pixel is represented with a value of Red, Green and Blue. , which is how Video sees the world in YUV (or YCrCb) color space. Each pixel is represented with a luminance value (Y) and two chrominance values: red/green difference (Cr), and blue/green difference (Cb). This is done because green has a higher luminance value and is therefore more likely to display artifacts if too much information is taken away. (Who knows, this stuff was figured out before WWII.) In the video world, a signal described as 4:4:4 means for every four pixels in a row, you get four pixels each for Y, Cr, Cb. This is equivalent to 8-bit RGB. 4:2:2 means that you get four Y pixels and two each of Cr/Cb for every four pixels in a row. You get less information in a smaller package, giving you a little more speed and a usually acceptable loss of detail. 4:1:1, which is what DV uses, means you get four Y (luminance) pixels and a single each of Cr/Cb (red/green and blue/green difference). This means luminance can change every pixel, but color changes only every four pixels. For example, if you look at the keyed footage, you will see that each of those blocks is four pixels wide. Wow, that saves a lot of data! But, oops, bluescreen keyers pull keys from color, not luminance, thus, you get the chunkiness. Doh!
Since the information in video is transferred from the YUV signal to the digital RGB, examine the original YUV channels. Attach a Color - ColorSpace to the FileIn and declare the outSpace as yuv. Press R/G/B on the Viewer to look at the new YUV channels.
Y (luminance) | U (Cr, or red/green difference) | V (Cb, or blue/green difference) |
![]() |
![]() |
![]() |
The luminance channel gets all of the necessary information, since the human eye is more susceptible to differences in luminance than hue. But the two color channels look like Space Invaders. This is bad.
So, how do you fix the key? You'll like this next trick.
Attach a Blur to the ColorSpace node.
In the channels parameter, blur only the U and V channels by switching the channels from rgba to gb.
Blur it a little bit, maybe 8 pixela, but mostly on the x axis. The y should be minimal, maybe 1 pixel.
Attach a second ColorSpace operator and declare the inSpace as yuv. This converts it back to RGB space.
![]() |
Now check your key out. Golly, it's mathemagical!
Without blur on UV: | With blur on UV: |
![]() |
![]() |
Another way to enhance your keying is to capture the blue/greenscreen DV footage through an analog capture board, or a board that can convert back up to 4:2:2. This significantly enhances the quality of the image and reduces the blockiness associated with 4:1:1 footage.
When you use straight YUV files, you can bypass the RGB -> YUV conversion by turning off yuvDecode in the FileIn. Do the Blur, and then use just one ColorSpace to convert it to RGB space.
You may have better results with greenscreen than bluescreen because of the higher luminance value.
For three helpful links (among thousands), jump to:
http://www.philipwilliams.com/greenscreen.asp
http://www.philipwilliams.com/dvcompression.asp
http://www.neopics.com/bluescreen/