The Vegas 7 disappearing overview

Comments

GlennChan wrote on 8/26/2006, 8:57 PM
The only reason for it's popularity is Macs lacked the CPU grunt to handle professional codecs like Digibetam and HDCAM.
There isn't a system that can handle digital betacam in its native compression (I believe it has a very small amount of compression). FCP however handles 8-bit and 10-bit uncompressed fine... as well as uncompressed HD (well ok, it doesn't have much RT for uncompressed 1080i HD).

The compressed codecs will take a little more CPU grunt than uncompressed codecs, since they don't have to decode DCT compression or whatever form of compression was applied. Decoding "uncompressed" 4:2:2 does take some effort though because of the color subsampling... FCP's uncompressed codecs actually don't bother doing a proper job in smoothing out the chroma, which improves performance and allows for 3rd party plug-ins (i.e. G Nicer) to do it instead.

- Anyways... to get back on topic...
FCP performs fine with DVCPRO HD, uncompressed SD, and uncompressed HD (all about the same speed, ignoring the difference in frame sizes). DVCPRO HD is really nice since it doesn't require a hefty RAID or even a hardware capture device... you still need the deck though (ignoring P2 media).
Native compression makes sense... saves so much hard drive space / you don't need a RAID for high bandwidth.
farss wrote on 8/26/2006, 11:46 PM
Glenn,
you're right. What I keep forgetting is that the data rate coming down SDI off DB is not the same as what's on the tape and it's encoded by whatever receives the data, in the case of Vegas into the Sonu YUV codec.

Well actually isn't doesn't it go through two stage. The deck must decode it into the SMPTE standard for SDI first as well?

Which leads me to the question I've never been able to get answered.

If a DVCPro 50 deck has a SDI connection why can we not capture that straight into Vegas via a Decklink card to the Sony YUV codec? I'm assuming what comes down the SDI feed is the same SMPTE standard as coming off DB.

It's no longer DVCPro 50 that's being edited in Vegas of course but neither is DB.

I'd try this myself however we sold off all our DVCPro gear sometime ago.

Bob.
rmack350 wrote on 8/27/2006, 12:45 AM
Funny you should bring this point up. Funny to me anyway.

At work we shoot DV25 but the DV deck just has SDI output. No DV25 output at all. So it's a similar situation. The signal is converted to whatever goes out SDI and then the system at the other end turns it into files of it's favorite format. Used to be media100 systems and now it's Axio. Still the same SDI and I suppose if we had DVCpro50 source it just wouldn't matter.

On the other hand, conversion to SDI is still conversion. Not quite the same as getting the data more directly.

Rob Mack
Coursedesign wrote on 8/27/2006, 8:37 AM
FCP's uncompressed codecs actually don't bother doing a proper job in smoothing out the chroma, which improves performance and allows for 3rd party plug-ins (i.e. G Nicer) to do it instead.

Why should a codec smooth chroma?

The smoothing is only applicable when you import a lower chroma resolution format such as 4:1:1 (may its inventor rot in a warm place together with the inventor of the Canadian postal codes) into typically a 4:2:2 format. It seems very few people do this. (Too few imho.)

GlennChan wrote on 8/27/2006, 8:57 AM
Why should a codec smooth chroma?
Certain effects like chroma key should have smoothed chroma to operate correctly.

You should also have smoothed chroma when going from 4:1:1 to 4:2:2 or the various flavours of 4:2:0 (i.e. DVD).
Spot|DSE wrote on 8/30/2006, 4:23 PM
Tim,
it might well be possible that the DVCProHD decode is available in Vegas, but not from Panasonic.
With CineForm, Raylight, and now apparently Serious Magic all offering DVCProHD decoders...
I'm looking forward to playing more with the Serious Magic decoder for our Varicam projecs.
fldave wrote on 8/30/2006, 5:06 PM
glennchan, interesting discussion on chroma.

I've avoided HDV intermediates for final renders because I wanted the "best" I could get, but I'm becoming more sold on the cineform intermediate. I just looked on their website and CI is 4:2:2. By the way, I've always used chroma blur for any keying, based on advice on this forum and some tutorials.

So with HDV m2t, which is, I believe, 4:2:0, should I add chroma blur to my intermediate creation step? Or since I am going from the final parameter 0 to 2, it won't matter?

It sounds real critical that everyone knows that going from 4:2:0 to 4:1:1 back to 4:2:0 is not a good idea.

Man, can't we just do 4:4:4 all the way? Cheap?
Coursedesign wrote on 8/30/2006, 5:10 PM
Certain effects like chroma key should have smoothed chroma to operate correctly.

Yes, but nothing happens unless you are rendering to a format with a higher (or technically, different) color sampling frequency. Smoothing 4:1:1 while rendering to 4:1:1 does nothing.

You should also have smoothed chroma when going from 4:1:1 to 4:2:2 or the various flavours of 4:2:0 (i.e. DVD).

That's what I said, it only applies to color sampling conversion.

GlennChan wrote on 8/30/2006, 7:26 PM
It doesn't happen only with color sampling conversion (or it does, depending on what semantics you are using).

For example, take DV footage shot greenscreen and output as DV onto miniDV tape.

The DV footage is 4:1:1 to begin with.

***Key point: The chroma key (as implemented in Vegas) operates in 4:4:4 color space. It looks at each pixel, instead of looking at every fourth pixel (or whatever is appropriate for the color subsampling). This is why you should add the chroma blur filter - to do a better job in upconverting the 4:1:1 to 4:4:4.

Vegas by default does a very simple and low-quality conversion (in terms of chroma) from 4:1:1 Y'CbCr to 4:4:4 R'G'B' color space. You can get better results by applying the chroma blur.

When the chroma key happens, chroma information affects luma information. So suddenly, you have low-resolution chroma information affecting the entire picture.

2- There are different ways to resample/blur/smooth the chroma. Marco Solario's website has examples from available codecs.
http://codecs.onerivermedia.com/

Actually I'm working on something now (a proof of concept / out of academic interest) which does a better job than traditional methods. If you throw extra processing at resampling the chroma, you can get better results.

You can see a sneak preview at:
http://www.glennchan.info/articles/technical/chromata/chromata.html

Compare this image with those on Marco Solario's site <-- I wouldn't read the article, just do this first.

There is a major error in my article in that you can get results similar to the luminance-chromaticity method demonstrated, while maintaining compatibility with chroma-based formats (ignore the stuff about the chromaticity of black problem; it's not a problem). But to summarize:
A- Different "uncompressed" codecs differ in performance, since the chroma is essentially compressed.
B- With more+better processing, it is possible to yield better resampling of the compressed chroma information.

GlennChan wrote on 8/30/2006, 7:35 PM
Man, can't we just do 4:4:4 all the way? Cheap?

A- Acquisition in 4:4:4 would be nice for chroma key work. With RED coming out, the flexibility of recording 4:4:4 or 4:2:2 compressed seems to make a lot of sense.

In the majority of scenarios, 4:2:2 (or even 4:1:1 or 4:2:0) quality is fine and *desireable* (lower cost, faster). But being able to switch to 4:4:4 for those chroma key shots helps.

B- A lot of image processing is done in 4:4:4 / without color subsampling. In Vegas, all processing is done at 4:4:4.

C- Unfortunately in Vegas, the Y'CbCr conversion to studio R'G'B' can sometimes clip important chroma information. What happens when you use the more basic chroma resampling techniques is that you can get negative colors. If the original image has 1-pixel red lines on black, the decompressed image will have negative green and negative blue values where the black pixels are/were. When these values go outside the 0-255 range, there is clipping of information and you can't get this information back. Whether or not this is a big idea I haven't tested. Vegas is good in that it decodes to 16-235 studio RGB, so there's headroom and footroom for wacky values like the negative colors. But certain legitimate colors will still clip.

A solution would be a better DV codec (although it may not necessarily be better since it'd be slower), or just live with the error (which only happens in extreme cases) and have a better plug-in that resamples the chroma better.
fldave wrote on 8/30/2006, 8:08 PM
Wow. Thanks, glennchan, for the sneak peak. About two months worth of reading, thinking and experimenting. Or should I call you "Dr. Chan"?
Coursedesign wrote on 8/30/2006, 10:19 PM
Interesting work on your website!

The chroma key (as implemented in Vegas) operates in 4:4:4 color space...This is why you should add the chroma blur filter - to do a better job in upconverting the 4:1:1 to 4:4:4. Vegas by default does a very simple and low-quality conversion (in terms of chroma) from 4:1:1 Y'CbCr to 4:4:4 R'G'B' color space. You can get better results by applying the chroma blur.

So this seems to be more an issue for the chroma key code than for the codec itself.

It's not hard for Vegas to work with 4:4:4 on a frame-by-frame basis, but it's not exactly trivial for any computer to store say an hour or two of 1920x1080 of 4:4:4 footage, and to shuffle it fast enough...
GlennChan wrote on 8/31/2006, 10:55 AM
"Dr. Chan"
Naw, don't do that. Just because I was using a lot of big words there doesn't mean that I have a phD. And really, sometimes big words means that other people don't understand what you're saying and therefore think that you're smart. But really, anyone (even people with phDs) can be wrong- heck, my article is wrong!! (I should get around to fixing it).



You can have the chroma resampling code in the chroma key, or in the codec itself. Each approach has its advantages.

If you implement it in the codec, it provides good quality all-around and it is simple for the user. The user doesn't have to do anthing special.
However, it hurts you in that you don't have the flexibility to choose a better resampling method (especially when the resampling can interact with other aspects, like in chroma keying). An alternative approach is to let you disable the chroma resampling so that the filter can implement a better method.

Implementing chroma resampling in the codec has a performance penalty... it may not be that big.
Jay Gladwell wrote on 8/31/2006, 2:28 PM

So, Glenn, how or what does one do in Vegas to achieve the results you show on your web site, or did I totally miss something?


GlennChan wrote on 8/31/2006, 4:17 PM
I think I went off on a tangent... the best you can do in Vegas is to apply the chroma blur (which gives you reasonable quality, although titles in DV are still a little difficult).

Better quality chroma resampling would require something like a better DV codec, or a Vegas plug-in.
mvb wrote on 9/23/2006, 8:00 PM
it might well be possible that the DVCProHD decode is available in Vegas, but not from Panasonic. With CineForm, Raylight, and now apparently Serious Magic all offering DVCProHD decoders... 'm looking forward to playing more with the Serious Magic decoder for our Varicam projecs.

Cineform and SM use the same decoder for DVCPROHD, that is
the free decoder that installs with the P2 Viewer from Pansonic.

The Raylight decoder was built from scratch.





Spot|DSE wrote on 9/23/2006, 8:14 PM
Nice to know, Marcus, thanks for the info. If I'm using DV Rack, I'm finding I like the DVCProHD decode there, but if I'm using footage imported from cards, I'm using Raylight.
Overall, it's great that there are third party options for DVCProHD so that the non-HVX users of Vegas aren't footing the bill for DVCProHD support.
mvb wrote on 9/24/2006, 10:07 AM
Soon there will be an option to convert DVCrack to Raylight
so you can use the Raylight P2 Authoring tool. Try the beta version
at dvfilm.com/customer/P2Maker.zip