Calibration of an 8 bit digital component editing system using color bar.

[edDV]

Hey Ed........I'm really impressed with your knowledge of video.
Do you have any helpful links to understanding Vectorscopes and color?

Not an engineers guide, but a layman's understanding of legal luma, chroma, and parade values?
I'm looking to do some more serious color correction, but need to understand the basics first. Thanks.

I'm not sure what you are asking. The waveform monitor analyzes luminance information. For 8bit component digital video (ITU-Rec601 based) black is defined as digital level 16 (0% on the waveform monitor) and white is defined as digital level 235 (100% on the waveform monitor).

The vectorscope plots chroma phase (hue) against saturation. The standard 75% SMPTE color bar is used to set and compare levels. One must first set a bar in the digital domain and calibrate the D/A path to the monitor. If the path is all digital, the monitor is adjusted to the bar.

75% color bar for digital component video.
The markers on the waveform monitor and vector scope correspond to the reference color bar.


Once the system is calibrated to the viewing monitor, input video can be viewed and adjusted to match levels at the waveform monitor and vectorscope. For example, a standard analog color bar (ADVC-100) was recorded to a VHS vcr, then played back and captured (again with the ADVC-100) to the DV format timeline. Although VHS shows noise, the levels were approximately correct. If levels were low or high, internal calibration adjustments would be needed for the VCR.



This verifies the hardware path from VCR to viewing monitor is properly adjusted. Next, arbitrary tapes can be played on the VCR and levels/color correction adjustments can be made in the editor all in reference to the standard color bar.


The 7.5 IRE adjustment is for NTSC only. PAL uses 0.0 IRE for black.

The BelleNuit color bar tests the limits of a 8 bit component digital path including overshoot protection areas above level 235 and below level 16 plus includes linearity sweeps and 100% bars.


http://www.belle-nuit.com/testchart.html

This particular screen cap showed the result of a loop path from Sony Vegas (DV timeline to uncompressed RGB export) to VirtualdubMod and then VirtualdubMod RGB imported back into the Vegas DV project timeline. As can be seen, the overshoot regions were preserved.

Ask more if this didn't cover your question.

[jagabo]

This particular screen cap showed the result of a loop path from Sony Vegas (DV timeline to uncompressed RGB export) to VirtualdubMod and then VirtualdubMod RGB imported back into the Vegas DV project timeline. As can be seen, the overshoot regions were preserved.

What do you mean? You exported from Vegas as uncompressed RGB, opened the uncompressed RGB file with VirtualDubMod and saved as another uncompressed RGB, then opened that uncompressed RGB in Vegas?

Note that Vegas appears very unusual in it's RGB/YUV conversion. Just about every other program will compress luma values when converting RGB to YUV (RGB 0-255 -> luma 16-235), and expand luma values (luma 16-235 -> RGB 0-255) when converting YUV to RGB.

People need to be aware of this if they are going to download an RGB TIF and convert it to DV with VirtualDub (or any program other than Vegas). They need to use a DV encoder like Cedocida that allows you to bypass the luma compression.



The Panasonic DV codec always compresses luma when going from RGB to YUV.

[JohnnyMalaria]

Note that Vegas appears very unusual in it's RGB/YUV conversion. Just about every other program will compress luma values when converting RGB to YUV (RGB 0-255 -> luma 16-235), and expand luma values (luma 16-235 -> RGB 0-255) when converting YUV to RGB.

Vegas isn't that unusual. Other NLEs also give you the choice of "computer" RGB vs. Studio RGB. The key is to know which RGB gamut is being used. For many low-end apps it simply isn't documented.

The luma "compression" - i.e., scaling - applies to the chroma components, too.

For editing purposes, Studio RGB (R'G'B') is recommended because it preserves "illegal" YCrCb values such as the overshoot. When compressed to the final YCrCb-based format, you won't have lost the additional information. Using (computer) RGB on the other hand will cause loss of information.

Computer RGB is fine if RGB is your final destination. It's a poor choice otherwise. Ideally, all editing should be done in the YCrCb colorspace and displayed on YCrCb displays.

[edDV]

Yes, that is why when I need to use Virtualdub filters (e.g. IVTC or sharpening) I export uncompressed (or huffyuv) from Vegas to virturtualdub and always test the loop with the BelleNuit color bar to make sure the 236-255 region is preserved and levels are maintained through the filters. Excursions into 236-255 are perfectly "legal" and supported for DVD or broadcast although many broadcast distribution systems process down to 235.

This allows Virtualdub to be used in native RGB mode with all DV->RGB or RGB->DV conversion done by Vegas.

[jagabo]

VirtualDub will clip HuffYUV (YUY2) sources when it converts to RGB for filtering. Or maybe you're using it in RGB mode.