According to Vegas' scope, the black of Vegas' timeline is lower than our DVCAM ftg captured via firewire. Why would the black level be different and how do you work regarding this issue?
No. If you have a cross dissolve on the tracks above, it will cross-dissolve with whatever is below it. (Or rather, the opacity drops to less than 100%, revealing what's underneath it. Effectively the same thing.)
Glenn? But WHY is set like that? I can understand - kinda - What is setting our capture like that - but why? Why do it? Why then go through the bother of resetting when it is possible to have it set correctly IN the first place?
.. or have I missed the plot here? Wouldn't be the first time!
Along the lines of what Bob said, the capture process will record the digital video (and maybe all the flags, user bits, stuff in the vertical interval if dealing with SDI, etc.).
ideally, Vegas would handle video levels for you... converting everything into a single color space (i.e. studio RGB).
Computer RGB is intuitive and most filters work best with computer RGB input. Most codecs and 3rd party filters want to see computer RGB levels (i.e. Magic Bullet).
Studio RGB has leeway for headroom and footage, so you don't clip superwhites and superblacks right off the bat. You can also generate color bars.
Um... I guess the answer right now is that everything is sort of a mess. Because you have to manually handle levels conversions, and not all filters have controls appropriate for studio RGB levels.
The trouble you have with me, Glenn, is that I don't KNOW enough. Maybe that's a virtue?
But when I feel something IS hurting I kinda keep mentioning it. And, yes I hear you when you say it is a mess. My problem, again, is that at this level I'm always thinking that it HAS been thought through, and we mere mortals are harvesting the the bountiful crop of "clear-blue" water programming. Yes I AM that naive - well sometimes.
Just look at BK's post! Another poor soul meandering the lanes of "Digitdom".
Yes although that's not quite how I'd describe it.
Think of it as an invisible track always sitting at the bottom of the timeline. Any transparency that exposes that hidden bottom layer will expose a value of 0,0,0. Perhaps technically it's not black, just nothing.
The way to avoid this part of the problem is to add a bottom track of legal black that's 16,16,16. I just have a black preset called Legal Black for this purpose.
I only use Vegas default (Sony) DV codec for decoding DV. If I use files with 0-255 range Vegas does not change this range when decoding.
Most DV cameras produces maximum ranges from 16 to 255 - and that is what Vegas decodes it. If I have a dv source with a range lower than 16 Vegas will decode it just like it is.
At least on my systems.
So I think the reason the Vegas timeline black is "blacker" than the DVCAM captured footage is just because that black of the footage actually isn't RGB 0.
So I think the reason the Vegas timeline black is "blacker" than the DVCAM captured footage is just because that black of the footage actually isn't RGB 0.
Well the black from the footage is correct, the specs set black to 16,16,16. One might argue that the spec is perhaps a bit outdated I think but not something I'd imagine anyone wanting to change lightly.
Yes, it's in the way black is defined to be black.
Though same DV cameras usually records highlights up to RGB 255 (254) using the headroom given by the same specs (and Vegas will decode it to 255 then - right as it actually is).
So...if using the Sony codec, the "proper" way to arrange the timeline is with a 16,16,16 track beneath everything? BTW, if there are these differennces between codecs, It would be more sensible if Vegas' background could be chosen.
Related question; does the above discussion impact NTSC only systems, or PAL too, and does this have any bearing on the 7.5 IRE level of black, and "blacker than black" at 0 IRE?
In which case, what would be the recommended range of levels (for the footage itself) when adjusting using the histogram, 16 to 255, or 0 to 255, and does that differ from PAL to NTSC?
Ok DV records Y' Cb Cr values. The standard legal range for the Y' values is always 16-235. Stuff outside that range are for footroom and headroom.
When you convert from Y'CbCr to R'G'B', there are different ways to convert the levels. Microsoft's DV codec will take the 16-235(Y') values and expand them out to 0-255 R'G'B'.
Vegas' codec will take the Y' values and convert them to 16-235 R'G'B', maintaining (pretty much most of) the footroom and headroom.
If you decode still images like PNG, Photoshop, GIF, JPEG, etc. in Vegas, they will usually decode to 0-255 R'G'B' levels. Which is kind of whacked, since your DV footage will decode to 16-235 levels. So if you want all your source material in a single color space, you have to manually convert your source material.
2- And yes, the background in Vegas does seem to default to 0 0 0 RGB (though I think the alpha of the "background" is 0).
Hmmm...doesn't it seem that there should be a way to have all elements (DV, GRX) working in the same color space and with a background black of 16 16 16. i.e. there should be a setting for the environment and decoding should follow that.
I guess I am still not sure if teh correct way to edit for output to DVD is to have a track of 16 16 16 behind all ftg for fades. Oh..and some conversion protocol for GRX to keep them legal. Seems like a mess.
What about dropping a Broadcast filter on the preview window with the Studio to RGB box checked? Does that do the same as putting a 16 16 16 generated media on the bottom most track?
Seems that would also keep all footage and generated media within bounds?
A crossfade to black will generate values under 16 16 16 RGB... the Broadcast Colors filter will clip those values off.
Not the same (numerically) as fading to 16 16 16 RGB.
As Glenn rightly says the BC legaliser FX in Vegas is a clamp, the result is legal but no entirely desirable at both ends of the curve.
Putting a track of legal black and watching the values used for black and white in generated media is the best approach. You should also use PS to legalise any stills from a DSC or scanner or graphics that you bring onto the timeline.
The other approach that I've used to to put media that needs differing correction on it's own tracks and then apply the correction FX in the track header. Works very easily when I've had 100s of stills and video in the one project. Since then though I've got a bit better at using PS automation.
Here is an example of what the BC FX will do. It's not terribly bad and might be better than nothing but a fairly simple CC FX with the appropriate curve does the trick for me. The only downside is you need to watch the scopes to set it up correctly as the CC FX doesn't accept numeric values.
Is it true that using MS DV codec would negate the need for this "track of black" workaround? If so, is there real benefit to using the Sony codec? I think we have been using the Sony codec simply because the program defaulted to it.