It would also help greatly if you stated what TV format your tests are designed for, either PAL or NTSC.

@ fausseplanete

Sorry but I’m not entirely sure what you’re after...

If you’re trying to learn or understand, perhaps it might be more useful reading up a bit on the original specs, how/why they came about, manipulating the analog signal, wave theory, things of that nature.

If you’re trying to document the effects of various software conversions your basic idea might help, but I’m not sure you’ll be able to detect changes precisely enough to work as you might want. I’m not sure you’ll be able to display your patterns accurately to measure them. You might find some useful info at Adam Wilt’s site, & might also check the MSU (Moscow) video site (I think that MSU had some measurement software available).

If you’re ultimately trying to counter the effects of conversions I’d suggest reading up on the different methods of color data storage used and the relative weaknesses of different conversions; there’s been a bit of discussion on this re: Avisynth so might check related forums.

If you simply want to make video, worry about meeting the requirements for your intended audience... If you’re handing off to a broadcast facility you might have a lot more to worry about then say putting video on a DVD.

As far as Vegas’ scopes go, I’ve never seen claims that they do more than Sony’s stated purpose – to basically aid in matching video across a project. If your scope readings seem way off, make sure you haven’t introduced a pixel or two wide black border.

Thanks a lot for those suggestions which I will investigate. The Vegas ramp/scopes -based experiments are part-done and while not exact are nevertheless serving well to illustrate the gross levels effects of codecs (and their different settings). Also the experiments have nicely clarified the exact function of various levels-related Vegas FX & plugins and their settings - highly recommended therefore. I will in a week or so link to a webpage showing the results. I intend to follow up this work with more precise experiments and provide links to any tools etc. found to be useful.

@Stuart: the test-project is PAL 720x576 25fps (though there is only one frame!) progressive.

@MPM: The goal of this investigation is to achieve a work procedure where no unexpected contrast changes happen - so they either become expected or (preferably) avoided. That should make the production process more efficient and/or less stressful and, if the number of level-stretchings etc. can be reduced, produce higher technical quality. Just trying to get this one link in the chain right (for the time being).

Following Vegas and VirtualDub experiments, here is some simple practical advice to avoid clipping and contrast changes. Much better than messing with S-curves!

In VirtualDub, a Waveform Monitor with broadly similar behaviour to the one in Vegas can be obtained by the free VirtualDub plugin/filter ColorTools (v1.4), from http://trevlac.us/colorCorrection, configured with StdDef, 16-235, PAL (since that is my project), Luma (only), "Wafe Form Monitor". The only difference is the scale values, 0..255 instead of 0..100%. Now one can experiment with things like codec Decoding settings without having to import to Vegas (though in practice I did that as well). Just press VDub's F2 to reload.

VirtualDub uses VfW codecs. in my system, the VfW codec for DV is MainConcept DV Codec. It has separate Encoder and Decoder settings and attention to these is vital.

Decoder settings: Assert the "16..235" flag. This preserves the full dynamic range of the test pattern in a DV file saved from Vegas (encoded by its embedded Sony DV codec), this pattern having been generated in Vegas with RGB in the range 0,0,0 to 255,255,255. I phrase that carefully! If this flag is not asserted then the extreme blacks and whites (0..15, 236..255) get clipped.

Encoder Settings: Assert the "16..235" flag. This allows the full available dynamic range to be used (0..100 in Vegas's waveform monitor). Otherwise the range is essentially shrunk, not using the full possible range (whites not fully white and blacks not fully black), hence reducing the contrast.

That's the advice done, but can anyone help explain what's going on "under the hood"? The generic process of YCbCr-RGB (or Y'CbCr?) mapping is debated at http://www.fourcc.org/fccyvrgb.php and stated more certainly and simply at http://msdn2.microsoft.com/en-us/library/ms893078.aspx but am not sure what the flags in ColorTools and MainConcept do in a mathematical sense (despite having read the documentations for these tools). From the explanations I have so far seen I get the sense that the Y component of YCbCr might be mathematically incapable of representing values outside 16..235. In that case I guess that the "16..235" config flags (for ColorTools and MainConcept) mean "pre map to and post map from YCbCr16-235, in relation to RGB0-255" (or RGB 1-254 ?), thereby reducing the resolution in number of levels. But it doesn't make sense to me that designers of the data format would waste bitstring space given that Y is stored in its own 8 bits - surely the Y range of values would be mapped (offset and scaled) to use up *all* bit combinations (thus creating a new variable "Ybyte"?). In that case the levels resolution would not change, there would only be the quantization (levels approximation) effect. Anyone know the answer to what is going on?

As regards the stated VirtualDub waveform monitor being comparable to Vegas's waveform monitor, in the latter I have both of the "Video Scopes Settings" flags deasserted.

But it doesn't make sense to me that designers of the data format would waste bitstring space given that Y is stored in its own 8 bits - surely the Y range of values would be mapped (offset and scaled) to use up *all* bit combinations (thus creating a new variable "Ybyte"?)
The Y' component in Y'CbCr encoding has legal luma values from 16-235 (assuming 8-bit). Codes 1-15 and 236-254 handle superblack and superwhite values. For example, if you convert analog to digital and your analog levels are slightly off (and hence are illegal), the headroom and footroom in Y'CbCr will capture that information without clipping.

With RGB, most systems are generally designed without footroom and headroom. Legal values span 0-255. (Except for studio RGB.)

2- AFAIK, my article already (mostly) has the information you're looking for.
http://glennchan.info/articles/vegas/colorspaces/colorspaces.html

Glenn,

I did read your informative article before but was initially confused, possibly because historically I come from the whole-range world rather than the (TV-) legal one. It can be hard for an outlaw to integrate...

For example where in your article you say "The Vegas 6+ default codecs will decode Y'CbCr signals to studio R'G'B'.", I at first automatically assumed that meant the whole representable range (1..254?) of Y'CbCr was mapped to RGB 16-235. But I now think you mean that just the *legal* range (16..235) of Y'CbCr is mapped to similar levels (16..235) in RGB, with the headroom and footroom thereby also being preserved. An approximate 1:1 mapping of representable (legal and illegal) values in other words. Isomorphism even!

I hope I have it right now - but if not then please let me know!

Many thanks again for your help.