DV, Color Sampling, and Chroma-Key

[ This article was first published in the February, 2004, issue of
Larry’s Monthly Final Cut Studio Newsletter. Click here to subscribe.
It has also been published in the May, 2004, issue of Videography.]

 

I was called to a production studio client recently that was having a problem with one of their clients — a producer.

Here’s the situation. The producer rented their stage to shoot a green screen sequence using Beta SP equipment. The producer then complained about the quality of their cameras and lighting because he was not able to get a clean key from the footage. The production company wanted to know what the problem was and whether it was their fault.

After I got there, I learned that the producer was editing the footage in Final Cut Pro. However, he had dubbed the Beta SP footage to DVCAM in order to save money, instead of renting a Beta deck and the necessary capture cards and video RAIDs to allow FCP to capture the Beta footage.

I told my client that the problem began when the producer dubbed the footage to DV. And the reason is that while DV footage looks great, one of the reasons the files are so small is that the chroma information is significantly compressed.

In broad strokes, here’s what happens. When a video picture is created, each pixel is defined using three numbers for each pixel — one for the luminance (called the “Y” value), and two to describe the color (the “U” and “V” numbers). These three numbers make up what’s called YUV color space.

This table (using made-up numbers) illustrates this:

	Column 1	Column 2	Column 3	Column 4
Row 1	Y = 40 U = 20 V = 100	Y = 40 U = 20 V = 100	Y = 40 U = 20 V = 100	Y = 70 U = 60 V = 200
Row 2	Y = 40 U = 20 V = 100	Y = 40 U = 20 V = 100	Y = 70 U = 60 V = 200	Y = 70 U = 60 V = 200
Row 3	Y = 40 U = 20 V = 100	Y = 70 U = 60 V = 200	Y = 70 U = 60 V = 200	Y = 70 U = 60 V = 200

Here’s what these colors look like visually:

This illustrates that each pixel is uniquely defined using these three YUV numbers.

Let’s assume this picture shows the edge between a green screen and the blonde hair of an actor. Given the value differences between the pixels, pulling a key is easy. This uncompressed format is given the short-hand name of 4:4:4; which means that every four pixels across are described by three numbers per pixel.

This is the compression format for CGI animation and some Hi-Def.

The problem is that each video picture has about 350,000 pixels (349,920 pixels for you Beta SP purists) per frame, times 3 numbers per pixel, times 30 frames a second, which creates a data stream of about 31.5 MILLION numbers per second. In other words, a lot.

So many, in fact, that a way needed to be found to reduce this amount of data, because it was way too much to broadcast.

The human eye is very sensitive to changes in luminance. We quickly spot differences between light and dark. So, the “Y” value couldn’t be changed without seriously damaging the clarity of the picture.

However, the human eye is much less sensitive to color information. So, rather than describing each pixel using 3 discreet numbers, when Beta video was invented, it was decided to average the values of two adjacent “U” values and two adjacent “V” values; thus creating 4:2:2 color space. This instantly cut files sizes and data rates by 33%.

Here’s what these revised numbers look like. The pink areas indicate which cells now have average values:

	Column 1	Column 2	Column 3	Column 4
Row 1	Y = 40 U = 20 V = 100	Y = 40 U = 20 V = 100	Y = 40 U = 40 V = 150	Y = 70 U = 40 V = 150
Row 2	Y = 40 U = 20 V = 100	Y = 40 U = 20 V = 100	Y = 70 U = 60 V = 200	Y = 70 U = 60 V = 200
Row 3	Y = 40 U = 40 V = 150	Y = 70 U = 40 V = 150	Y = 70 U = 60 V = 200	Y = 70 U = 60 V = 200

Notice that here, the color values for every two pixels on the same row are averaged. The color is “close” to the original, but it definitely isn’t the same. In fact, only one row accurately represents the original image. This color compression is given the name of 4:2:2; which means that every four pixels across are described by four “Y” values, two “U” values, and two “V” values.

This is the compression format for Beta video.

When the compression format for DV was finalized, the decision was made to keep cutting down the color information. So, now, instead of averaging color across two pixels, it was averaged across four, creating 4:1:1 color compression and reducing file size and data rates another 50%. This, combined with other compression, allowed DV footage to be about one-seventh the size of Beta SP.

And here’s the result of all this compression. The pink areas indicate which pixels are now using average color values, (again, remember, I am using made-up numbers in this illustration):

	Column 1	Column 2	Column 3	Column 4
Row 1	Y = 40 U = 30 V = 125	Y = 40 U = 30 V = 125	Y = 40 U = 30 V = 125	Y = 70 U = 30 V = 125
Row 2	Y = 40 U = 40 V = 150	Y = 40 U = 40 V = 150	Y = 70 U = 40 V = 150	Y = 70 U = 40 V = 150
Row 3	Y = 40 U = 50 V = 175	Y = 70 U = 50 V = 175	Y = 70 U = 50 V = 175	Y = 70 U = 50 V = 175

Now, the color values of all four pixels in a row are averaged. No row accurately represents the original color values. This color compression scheme is called 4:1:1; which means that every four pixels are defined by four “Y” values, one “U” value and one “V” value.

This is the compression format for MiniDV, DVCAM and DVCPRO-25.

The colors in our example all seem close to the original, which to our eye is fine. But not to the chroma-keyer in the computer. The problem is that so much color information has been lost, it is impossible to precisely determine where the edge between green and gold is.

When that producer dubbed his footage to DV, he seriously compromised his ability to get a clean key. In other words, he saved money, but spoiled the shot. I fixed the problem, by using FCP to key his original Beta SP footage, and the final results looked great.

---

Bookmark the permalink.