I understood nothing regarding the YPbPr description and the co-efficients??? But I do appreciarte you taking the time to answer this.

I'm really a shooter, with a smattering of technical understanding so forgive me if I seem dense...

I'm just trying to get my head around much of the technology that is involved with shooting and editing video...

If the spec of the camera matches the editor and the delivery format, then the only thing that having some extra headroom in the "post-edit" stages will buy you is, er, headroom!

read on only if you don't mind wasting a few minutes of your life!:
-------------------------
It is so very much like audio. 44.1kHz 16bit CD-audio has been the delivery format but it isn't usually good enough for the mastering format. For that studios try to employ the best they can afford.

YPbPr is the representation of luminance (Y) with two additional signals from which all (most) colors can be derived entwined within that luminance. Your eyes have rods and cones to determine light and color-registration. This turns out to be a very efficient way of splitting the information up in the signal processing world, particularly in digital signal processing.

The imager in the camera catches red green and blue (sometimes using a prism or a set of fast changing filters) - afaik we haven't built a rods+cones imager into a camcorder yet. So this is then processed into a signal that suits the terminal on the back of the camera (for a set or studio) or for the onboard tape deck and compression circuits. Then we watch the resultant picture on our RGB driven monitors/panels/projectors.

It is easy to say, oh - that picture looks a bit too blue, or red or green. When you start saying it looks a bit purple, you might soon learn that you adjust red and blue to fix that. (secondary color theory stuff). In the RGB approach, if it is too bright/washed - adjust all three signals down a bit. Well, in luma+chroma you'd just dial the luminance down a bit (the equivalent of dialing all three RGB channels). There describes the information differences between the representations. So if you assign 8 digital and voltage weighted bits to the three signals - you actually cover a different range or gamut with the two approaches. Mathematical formulae or lookup-tables (ready-reckoners) allow you to convert between these representations, but there is a difference - so moving between them creates a risk. If you chop and change you might get stuck matching it all up. This would be just one example where you might be glad of headroom, or you could be hunting and constantly rebiasing to get the colorist's production values to make your work look the way you want to throughout the whole work.

MPEG-2 has some extra data beyond the payload that can help with the placement of the 8bit data into a more vast range of values. For example, B&W footage can look a bit contoured or visually crushed if your encoder isn't wise to the full set of opportunities it has to deal with. Very often if you buy back-fill DVD that is B&W it does look this way. However there are some range settings in the MPEG-2 spec that can offer to aid your 8bit payload - these, to my understanding are the co-efficients and are phrased in 8bit, 9bit or 10bit multipliers. (co-efficients are multipliers). I don't fully understand the engineering/informational science behind them. I'd read the TMPGEnc or MainConcept manuals first and then the MPEG-2 recommendations 2nd (if I could afford to have access to them).

I'm of the opinion that if an engineer can explain his science to a layman, then he actually understands it. If he can't he is simply slave to it and apart from having taken the effort to work with this science - he is of no great use as a teacher of that science or a reference. Now I don't begin to claim to be able to teach this stuff but I am almost able to describe it to a layman.

However you did start by saying that you were researching 8bit vs 10bit - so I did associate that with a theoretical and idealistic mindset. Irrespective of any previous learning or foundation. So if everybody who really knows this stuff chimes in - then perhaps you'll be suitably rewarded. If they don't and you get a list of peoples opinions - then you may need to whittle out the emotion from the facts. This could be hit or miss. (alternatively you could ask "what makes this NLE better than Vegas" on all the competitor forums!)

Y'CbCr is a digital encoding system. It applies to digital formats like DV, HDV, MPEG2, etc.
Y'PbPr is an analog encoding system. It is usually found in component analog interfaces in professional equipment (and even in consumer DVD players and TV sets).
Y'UV is also an analog encoding system. NTSC and PAL composite signals encode color into Y'UV.

Y'PbPr is carried over three cables, whereas NTSC and PAL composite signals are carried on one cable.

One confusing thing about this terminology is that many people use the term "YUV" to refer to Y'CbCr. They probably shouldn't be doing it because it can be confused with actual Y'UV.

The ' symbol denotes gamma correction applied before forming luma.. many people drop the ' symbol and are not aware of the differences between luma (Y') and luminance (Y).

see YUV and luminance considered harmful:

If you're shooting HDV then a 10 bit pipline doesn't gain you much unless you're doing heavy grading in post. Bear in mind that most display device today can't even do 8 bit justice it seems.

If you're working with analogue video source such as BetaSP then an 8 bit pipeline can certainly cause you grief.

Most of the new digital film cameras work at more than 8 bit and the price of them is coming down.

Well, in luma+chroma you'd just dial the luminance down a bit (the equivalent of dialing all three RGB channels).
If only this were true, Vegas' 3-way color corrector would be a little better.

If you do the math, you realize that dialing the luma down will shift the hue and saturation. You can also get negative values for the r/g/b channels (although computer algorithms may clip these values instead of producing negative values; the sony vegas codec may do this).

The formula for Rec. 601 luma is:
Rec. 601: Luma (Y’) = 0.299 R’ + 0.587 G’ + 0.114 B’
Cb = B' - Y'
Cr = R' - Y'

If you work out the formulas, you realize that negative R'G'B' colors can occur if you multiply Y' by something like 0.5.

Nitty gritty details:
*Rec. 709 is more complicated.... the luma co-efficients are different, and the transfer function is different.
**Cb and Cr have scale factors on them.

Is this as a suitable place to introduce the RGB+L quad imagers? No - me thinks.

Black stretch, gamma, companding, pedestal/setup.... yucky but a purists pleasure - again no, wrong forum thread.

Digitization methods, and linearity (or lack of) are also difficult concepts for the "shooter".

I agree we should use precise terminology too. This then saves having to accurately define them every time they drop their ugly faces into a conversation.

I do understand those who (including me) rather casually squash the language up rather. YUV mode is a lot quicker to say, hence the common use however slang it comes across. Many of the ITU/EBU/ANSI/IEEE/SMPTE/SI-unit definitions don't have corresponding or common definitions or units. They ought to though.

BTW - I'll add that by "c.f." I meant this to apply the latin abbreviation for compares-with. Or is it Greek.... ;-)

The 8bit vs 10bit discussion needn't become Greek to the majority though. So let's discuss onwards.....

10bit is a luxury, so if you can have it, why not? If you can capture without sub-sampling the color signals - then why not have that too? At some point you have to budget though - but he who waits or shops around has everything. Yet after all this nobody might notice - especially if the end product isn't worth the trouble.

The HSL adjust gives me access to luminance hue and saturation but lets me adjust them independently. So are these control handles badly programmed (not to have a shift in accordance with another)? Or does this tool follow the same approach that I was describing before the ITU-R bits reminded me of a lecture theatre from my old polytechnic.

Glennchan - going back on-topic - may I ask - would you worry about Vegas not having anything more flexible than an 8bit RGB pipeline (when dealing with anything other than untouched DV)? I'm intrigued if there are any views on or about to go on this thread that differ from mine or Bob's (farss)?

I suspect that my first post and much of what has come after has been techno-twaddle to the avid shooters and artists who frequent this establishment. ;-)

Not unlike chemists talking about viscosity, surface tension and fluid dynamics with a painter... :-P

Ok another post, to avoid mega-posts.

How much bit depth do we need in display devices?

The answer is a little slippery, since it depends on a few factors.

If you are after the best quality, then about 11-12 bits (at a gamma of 2.6) is necessary. This is assuming that this following CML discussion is accurate: see Matt Cowan's post

However, this was in a test environment with no noise (in source or display) and with ideal environment conditions.

WIth real world imagery, 3 bits is *almost* sufficient (at a non-ideal gamma of about ~2.2) in Adelson et al's companding scheme. Read the PDF at
http://web.mit.edu/persci/people/adelson/documents/Li_ACM_24-3.pdf
(my theory) The scheme works because the bit depth is lowered for fine detail, but broader detail/areas are still fairly close. For fine 1-pixel detail, not much bit depth is necessary.

(In my opinion) In practical environments, 8-bit display is pretty much good enough. You can't see artifacts that are objectionable, or inaccuracies in the image.

LCDs range in performance from 6-bit dithered, to a little under 8-bits. They lose some of the bits since they have to counteract non-linearities in the display. Or if they don't counteract the non-linearities, then grayscale tracking and colors will be off.

How much bit depth do we need in acquisition?
This will depend on what you want to do with the image in terms of color grading. Color grading can increase the amount of noise in the final image. Higher bit depth will reduce the quantization noise (which comes from rounding numbers into integers). An easy formula to estimation this is:
final noise = gain/slope * original noise

Original noise is compromised of sensor noise, digital signal processing noise, compression noise, and quantization noise (information you lose when you make a number an integer). Quantization noise can be swamped out by the other forms of noise.

Gain/slope is the slope of the function that you're applying to the image. i.e. If you multiply all values by 2, then the slope is 2. So multiplying the values by 2 will effectively double the noise.

Higher bit depths lower the amount of quantization noise in the original image.

Quantization noise (from the bit depth) is usually +-0.5. If you capture 10-bit for 8-bit output, then the quantization noise will be +-0.5 / 4.

If a color space is perceptually uniform, then a change of 1 will be just noticeable (this is by definition). Let's assume that R'G'B' space is perceptually uniform (which it isn't, but is close enough).

So if you have a color grading function with a maximum slope of 2, and the quantization noise is 0.5... then the quantization noise will be 1... i.e. barely visible. But remember that noise hides quantization noise... so in practice, this may not be visible.

With some s-shaped contrast functions, you might want to really push the contrast so the maximum slope can be a lot higher. In that case, 10-bit acquisition would be more desireable. If you want to capture high dynamic range (the buzzword is HDR) and then later re-map the contrast, you would encounter a situation like this.

Unfortunately, I haven't tested everything I say here so I could be wrong on some points.

What's RGB+L? Is that like Sony's RGB+E sensor?

The HSL adjust gives me access to luminance hue and saturation but lets me adjust them independently. So are these control handles badly programmed (not to have a shift in accordance with another)?
HSL uses a different formula... it's not the same as the Y'CbCr formula.

Multiplying the L channel in HSL is effectively the same as multiplying Y' Cb AND Cr by equal amounts, or multiplying the R'G'B' channels by equal amounts.
If you look at the math, it's all effectively the same.

Notice that if you are working in Y'CbCr color space, there is a difference between:
A- Multiplying just the Y' channel.
B- Multiplying all the channels- Y', Cb, Cr.

In Vegas terms: Just use the levels filter. :D Seriously, it's the least complicated. Unfortunately it isn't 100% accurate since it doesn't round numbers. Visually it looks fine though.
If you really want to use the Color Corrector, remember that it operates in Y'CbCr.
"Saturation" controls Cb and Cr.
Gain controls Y'.

Glennchan - going back on-topic - may I ask - would you worry about Vegas not having anything more flexible than an 8bit RGB pipeline (when dealing with anything other than untouched DV)? I'm intrigued if there are any views on or about to go on this thread that differ from mine or Bob's (farss)?
Vegas does incur errors in its pipeline that builds up.

For Y'CbCr formats, it has to convert them into 8-bit R'G'B'. There is some quantization noise here, since Y'CbCr has some not-so-nice numbers.

From filter to filter, Vegas keeps everything in 8-bit. This clips values, and again introduces a little more quantization error.

In most 8-bit workflows, you won't notice this. Some high-end systems also have similar problems I believe.

It would be nice if Vegas could handle 10-bit in/out, and if the pipeline internally is 32-bit float. With 32-bit float, you don't really need to worry about quantization error building up. You also don't get clipping when things go out of range. And your filters can operate without needing color space conversions (except between linear light and gamma-corrected)... so filter writers don't need to handle color space conversions themselves. Linear light RGB would seem to be a common denominator, so that would likely be the ideal internal color space.
What that approach would avoid is some of the buginess you see in FCP.... 10-bit in FCP is buggy, and is superblack/out of range handling and maybe some other things.

However, the downside to working with 32-bit float internally is that filter designers would have to re-program their plug-ins. Linear light might be a little bit of a curveball, as I expect most filter designers won't expect that. Ultimately however, Vegas might also want to adopt a more standard filter plug-in architecture like after effects or OFX.

Vegas could also be designed to be backwards compatible with vfw plug-ins, although there will be a performance hit as it would need to convert from 32-bit float linear light to 8-bit gamma corrected R'G'B' and back.

-Bob: Do you think that the reason why 10-bit performs better is due to some implementation reasons? i.e. the 10-bit equipment happens to be better designed, or that capturing 10-bit forces the signal into a different processing path in the NLE.

Clearly capturing 10 bit gives you more head room than 8 bit and from some discussion with other Vegas users trying to handle BetaSP camera tape through Vegas, Vegas's 8bit pipeline does cause issues. This could be avoided by using procamps to grade the footage prior to ingest at 8 bit I guess but seems a funny way to have to work.

My only work with BetaSP is from already cut and graded tapes so I've personally never faced this issue. I have worked with DB camera tapes and a) it was shot well lit enough not to need serious posy work and b) it seems DB cameras only record 8 bit anyway.

My main interest in 10bit comes from our interest in the SI camera, if we plonk down the cash for one or two of those I have little choice but to at least get one leg in another camp. No doubt the 'benefactor' paying for all this largess will also be funding some other high end tools, a Lustre suite could be on the horizon. All just kite flying at the moment but I'd like as many of those kites to have Vagus on them as possible. Main aim is to support local indie production and make a buck too.

In general I've found that even in 8 bit land better gear does a better job. I've ingested from DB via Sony's J30 decks 1394 output. One day only had J30 with SDI and didn't want to chew up disk space so fed that into the SD Connect to do the 1394 conversion. Quite noticeable improvement in image quality. Convergent Design say they're using 14 bit processing, I'd imagine the J30s internal conversion wasn't designed to do the best job possible, it's more than passable but misses that 14th coat of wax.

b) it seems DB cameras only record 8 bit anyway.
Hmm I thought that digibeta was a 10-bit format.

Digibeta is a 10-bit format, but a long time ago (early 90s I think) there was ye olde 8-bit camera head that fed a Digibeta deck with the last two bits zeroed.

I guess it was the Cadillac Cimarron of its day... (think Mercedes A-Class for the Europeans, although it's actually coming to the U.S. in 2008, I just saw one here in L.A.).

This 8-bit DB bastard lives on in urban legend to this day, and has made many people think that DB is always a 10-bit format with 2 bits hardwired at "00".

Thank you for clearing that up. If you are right then that legend sure lives on and I've been caught in the crossfire over that one, I'm talking engineers working in broadcast who still swear it's only 8 bit out of the cameras, with as you said two dummy bits.

Bob.

...and in SD, DigiBeta is not the the only 10-bit game in town.

The camera head I'm using (Sony DXC-D50WS) is virtually identical to that in the top-of-the-line $85,000 DigiBeta camera. Identical megapixel native 16:9 2/3" CCDs, identical A/Ds, identical DSPs, identical knobs, etc., and identical 10 bits of video coming out, except I don't sin by bastardizing it with compression, and the list price for my camera is less than $20K (of course I got a great great deal on it thanks to a dealer screwup). Of course I don't have to, ahem, worry about any stinky tape dropouts either...

(To be fair, DB compression is quite mild and it won't generally lift anyone's skirt.)

For next time, I got my eyes on XDCAM HD. Yes, it is 8-bit, but I will still process it in 10-bit and higher, because for what I like to do it makes a difference. Love the cameras!

RED may turn out to be eminently practically useable, but I'd like somebody else to carve that trail first.

And for drama, I still have a weak spot for chemically coated light sensitive sprocketed celluloid running at 24 frames per second with a rotating shutter. It's amazing how hard it is to replicate this with a computer.

I am going to print out this discussion and read in in depth - I think I just received a crash course on this topic and once again, the Vegas Forums provide more real world information than from any other forum I lurk in - You guys are the best!!!

Does anybody have any "real world" examples of 8 versus 10 bit processing. Start with DV or HDV, do some typical image tweaking, then show the results in a split screen?...

This link might or might not be relevant to this thread. According to cineform, working in 10 bit is preferred even if you start with an 8 bit source.

Juan