Comments

Grazie wrote on 10/5/2005, 11:26 PM


You've seen the "Y" = Luminance = LIGHT! Thanks for sharing. It's all in the detail - eh? :) G


rs170a wrote on 10/6/2005, 5:54 AM
I've always liked Adam Wilt's site for his explanations and pictures of this issue.
For example:
4:2:2, 4:1:1, 4:2:0;
DV Pix - Sampling Methods (more links at the top right of this page);
DV Pix - Multigeneration test images.
Also, he's written several articles on this and similar issues for DV magazine. You'll need to register but it's free.

Mike
BarryGreen wrote on 10/6/2005, 2:24 PM
>>HDV is 4:2:0. Does this mean the 0 represents zero Blue component (the V)? <<

No... the 4:2:0 doesn't imply that there's no blue component, of course... there has to be.

4:2:0 means that there isn't a color sample on every scanline (like there is in 4:1:1, 4:2:2, and 4:4:4). Instead, 4:2:0 delivers a color sample every other scanline.

Put in numerical grid terms: if you're looking at a 720x480 DV image, you get effective chroma resolution of:
4:4:4 = 720x480
4:2:2 = 360x480
4:1:1 = 180x480
4:2:0 = 360x240

Luma resolution is black & white (well, shades of gray actually). Chroma resolution is what color those pixels are -- the luma is how light or dark they are, chroma is what color they all are.

In 4:2:0 (and 4:1:1), there's one color sample for a block of four pixels. That means that all four of those pixels are the same color, but they're different degrees of bright/dark (depending on what the luminance pixel shows). If you're shooting a strictly black & white image, chroma resolution is irrelevant. If you're shooting a color image, chroma resolution is quite relevant.

In 4:2:0, each chroma sample represents a 2x2 block of pixels. If within that block the upper-left pixel is green, the upper-right is blue, the lower-left is red, and the lower-right is gray, the 4:2:0 chroma compression would have to try to reconcile all four pixels and come up with one color that best describes all four. In that case, all four pixels would be turned to gray (the best compromise between equal parts red, green, blue and gray). If they were different tones, then the luminance value would still be different, so you could distinguish four different pixels, but all pixels would be gray. If they were all the same tone (i.e., 128,0,0; 0,128,0; 0,0,128; and 128,128,128) then in a 4:2:0 system all you'd see would be one big 2x2 block of gray; the luminance and chrominance would all be recorded at the same level.

In a 4:2:2 system, the green & blue on one line would be color-averaged together, and the red & gray on the next line would be averaged together, so you'd get two different color samples.

Of course, in 4:4:4 you'd get exactly what you'd expect from the original: individual red, green, blue and gray pixels.
MH_Stevens wrote on 10/6/2005, 7:33 PM
The reason the 4:X:X notation is confusing is because it is illogical. Unintuitive I believe Adam Wilt calls it. If you try to read meaning into those three numbers you will go mad if you are not lucky enough to realize it just does not stack up.

Instead think of it this way. Forget the number 4, but know that luminance (Y) is always sampled 100%. Now consider the varying percentages of sampling for the color in the horizontal and vertical.

The Notation........% Horizontal sampled.........% Vertical sampled

4:4:4..............................100%............................................100%
4:2:2................................50%............................................100%
4:1:1................................25%..............................................50%
4:2:0................................50%..............................................50%

Mike S
farss wrote on 10/6/2005, 8:39 PM
Could this explain why HDV and mpeg-2 for DVD uses 4:2:0, from those figures given the wider AR of 16:9 used in both those formats the 4:2:0 sampling holds up better than 4:1:1?
Another question though, I've seen sampling quoted with an extra digit, does that refer to the alpha channel?
Thankfully one day soon it'll all be RGB and this YUV fudge will be behind us.
Bob.
Coursedesign wrote on 10/6/2005, 10:03 PM
The fourth digit, when present, refers to the alpha channel.

To add confusion, the 4:2:0 of PAL is not the same 4:2:0 as that of MPEG-2...

Holding up better? You mean that HDV MPEG-2 4:2:0 holds up better when converted to an SD DVD which is also 4:2:0?

Going 4:1:1 to 4:2:0 you lose even more color information, this is certainly true.

Long live 4:2:2!

The YUV fudge was probably inspired a long time ago by b&w compatibility, then found to reduce bandwidth needs.

BarryGreen wrote on 10/6/2005, 10:25 PM
Mike S, that chart is quite good, but there needs to be one correction: it doesn't accurately represent 4:1:1. 4:1:1 is sampled 100% on the vertical.

And yes, as Coursedesign says, there are two different 4:2:0 systems. So 4:2:0 doesn't necessarily mean 4:2:0...
Edward wrote on 10/7/2005, 2:35 AM
dang coursedesign, if you didn't say that, i'd be content right now. 'not all 4.2.0's are alike...' lol

isn't there some drug reference to 4:20? i'm just asking... i wouldn't know about this stuff.... hmmm, got the munchies....

Barry, you've helped out even more. Thanks guys for your 4.2.2 'input'... now from what i've learned, will my 'output' be 4.1.1 or 4.2.0?
Grazie wrote on 10/7/2005, 3:05 AM
. . luv it! Yah gotta luv it! - I AM listening to this, very closely .. G
farss wrote on 10/7/2005, 5:11 AM
That depends. If you render to NTSC DV then it's 4:1:1, if PAL DV then 4:2:0, if you use the Sony YUV codec then 4:2:2 which is a better way to go.
Another consideration though is no matter which one you choose it's only 8 bit.
Bob.
Coursedesign wrote on 10/7/2005, 8:29 AM
Another consideration though is no matter which one you choose it's only 8 bit.

I would take 8-bit 4:2:2 over 10-bit 4:1:1 anytime though.

The color sampling makes a much more fundamental difference than 8-bit vs. 10-bit (although I do like 10-bit for the improved tonal range and added flexibility in post).

MH_Stevens wrote on 10/7/2005, 9:52 AM
If Sony wants to keep Vegas as a leading edge and pro package version 7 MUST be 16 bit (in my book).

Spot|DSE wrote on 10/7/2005, 10:14 AM
If Sony wants to keep Vegas as a leading edge and pro package version 7 MUST be 16 bit (in my book).

K, you lost me here. Who has a 16bit video editor in the sub 50k price bracket?

Who has a 12bit in a sub 50K price bracket?
Coursedesign wrote on 10/7/2005, 11:00 AM
I think MH is thinking of After Effects Pro, this handles 16-bit color (although it is not an editor, but a compositing and motion graphics package).

Perhaps because of Vegas' great strengths in compositing it is tempting to ask for the same capability.

AE Pro uses a lot of extra disk space (and memory) dealing with 16-bit color. This is still useful if you are dealing with chained effects that can create banding if you don't go to a higher color space (note that some other packages go to 32-bit and even float precision).

For editing, it would be nice to support 10-bit video, stored as 10-bit for efficiency reasons. This will come, it's only a question of which year.

Spot|DSE wrote on 10/7/2005, 11:19 AM
10 bit, I can agree with wholeheartedly. 10 bit holds a bit of benefit when working with 8-bit originated video as well, but not enough to justify the extra cost, IMO. But you're right, it will come.
GlennChan wrote on 10/7/2005, 8:22 PM
FCP I believe can render in 32-bit float with its high definition rendering mode or whatever it's called. It is off by default, because it makes render time go up significantly.

2- 8-bit versus 10-bit:
There's not much point rendering to 10 bit unless your target format supports it. Let's suppose it does.

Take a look at the following image:



Take a look at boxes 15 and 17. There should be an inner box with RGB values of 15 15 15 and 17 17 17 (the surrounding box is 16 16 16). If you can barely see the box (or can't see it at all), then you're like me. If the boxes become smaller, they get much much harder if not impossible to see.

Note: You're viewing an 8-bit image on a computer monitor (which may be incorrectly calibrated, so bring up the brightness setting if you can't see box 09).
If you are on a LCD, some of them only support 6-bit color depth (quite a bit of the new LCDs do this). So, you can't see this test correctly. This also suggests that 8 bit is pretty darn good if 6 bit is acceptable.

3- As far as rendering goes, it's better to render at a higher bit depth and then squeeze things down for the output format. Certainly in Vegas you can create banding if you are running a series of filters and letting rounding error accumulate.
Some filters create banding by themselves (i.e. gradient map).