Attn Doc Mordrid! DV/DVD luma, VERY confusing...

[Flying dutchman]

Hi Doc,

I was hoping you could help me out with this little problem. The literature says digital video has to stay in the 16-235 luminance range for NTSC conformity. A standard called CCIR 601 or something. (My country uses PAL, BTW, I don't know if this applies to PAL too?)

However, when I convert a clip from DVD -> VCD using Flask/bbmpeg and load the output in VirtualDub, I see that the output has the full luminance range from 0-255. I verified this with several DVD's.

This makes me quite a bit uncertain about which "standard" I must make my own VCD's adhere to. So, for my home-made VCD's, should I use the CCIR luminance range, or can I use the full 0-255 ?

The big problem is that I don't know if it is the software (flask) that fiddles with the luminance range or if the DVD's are really encoded that way.

To make matters even more complicated, I have found out that all Mpeg encoders (tmpeg, CCE etc) actually expect their INPUT to be CCIR compliant. If you turn off CCIR in the encoder, and tell it to use 0-255 liminance range, it actually stretches the luminance -everything below 16 and above 235 falls overboard.

This is somewhat paradox. If I create an AVI file with luminance range 0-255, and tell the encoder to also encode it with luminance range 0-255, the resulting output is quite different from the input. Terribly complicated...

[Flying dutchman]

I solved a little part of the riddle already - FlaskMpeg does indeed tweak the luminance levels.
DVD2Avi (in YUV mode) serves the images with a luminance range of 16-235. I'll try and make a VCD of it, just to see if the brightness levels correspond to the original.

[Dr Mordrid]

In most editing software the clipping is done by an NTSC or PAL color filter, which can be switched on or off in the project setups.

ITU Rec. 601 is now the standard as the CCIR no longer exists. ITU-R BT.601 specifies that YUV/YCrCb luma sample values are the same for both the PAL and NTSC TV systems.

YUV/YCrCb luma values from 0-15 are used for footroom (below black) with black being defined at an RGB level of 16. The headroom is limited to a value of 235, as you noted, to prevent overmodulation. 8 bit/channel RGB24's color range has to be mapped into this limited space.

Most editing software, however, will list separate PAL and NTSC filters. This is because the option of using the footroom is "legal" for PAL. NTSC-J (Japanese) can also use the footroom.

Even though 235 is the max "legal" RGB level not all of the RGB channels behave the same within the standard. Red, for example, is often best limited to about 190-210 to prevent bleeding in NTSC.

Video for a computer screen can use the full RGB space of 0-255.

Dr. Mordrid

[Flying dutchman]

Thanks Doc!
Where did you get that info, BTW? And you say it is legal to use the "footroom" in PAL? Won't that be displayed as black then?

I have discovered that FlaskMpeg does a YUV->RGB conversion that stretches luma to the 0-255 range. I am not sure if it compensates for gamma (2.2) as well.
This means that the Premiere plugins such as bbmpeg, LSX,CCE won't be able to produce NTSC/PAL compatible VCD's...

[Dr Mordrid]

The footroom gives a very deep black while using RGB 16 is a bit more towards a dark charcoal, if your eyes can see it. Not everyone can tell the difference without a vectorscope

Got the info long ago from corporate video FAQ pages.

It's not a big deal that the RGB stream is re-converted to a full RGB24 colorspace as long as the levels within the stream remain below the specified maximum.

When creating anything for display on an analog TV you should use the NTSC/PAL filters.

Dr. Mordrid

[Flying dutchman]

One more question; NTSC uses a Gamma of 2.2 and PAL uses 2.8 (officially). Video material on PAL DVD's, however, mostly comes with a gamma of 2.2 but that's probably to make life easier for the DVD producer.
I wonder if some quality could be gained by converting the material to the "correct" gamma value, or would PAL DVD players already take this into account?

[Dr Mordrid]

Here's something I pulled down some time ago regarding NTSC vs. PAL gammas;

======

WHAT IS GAMMA CORRECTION?

In a video system, linear-light intensity is transformed to a nonlinear video signa by gamma correction, which is universally done at the camera. The ITU Rec. 709 transfer function takes linear-light intensity (here R) to a nonlinear component (here Rprime), for example, voltage in a video system:

Rprime = ( R <= 0.018 ?
4.5 * R :
-0.099 + 1.099 * pow(R, 0.45)
);

The linear segment near black minimizes the effect of sensor noise in practical cameras and scanners. Here is a graph of the ITU Rec. 709 transfer function, for a signal range from zero to unity:

An idealized monitor inverts the transform:

R = ( Rprime <= 0.081 ?
Rprime / 4.5 :
pow((Rprime + 0.099) / 1.099, 1. / 0.45)
);

Real monitors are not as exact as this equation suggests, and have no linear segment, but the precise definition is necessary for accurate intermediate processing in the linear-light domain. In a color system, an identical transfer function is applied to each of the three tristimulus (linear-light) RGB components. See Color FAQ.

By the way, the nonlinearity of a CRT is a function of the electrostatics of the cathode and the grid of an electron gun; it has nothing to do with the phosphor. Also, the nonlinearity is a power function (which has the form f(x) = x^a), not an exponential function (which has the form f(x) = a^x). For more detail, read Poynton's article.

DOES NTSC USE A GAMMA OF 2.2?

Television is usually viewed in a dim environment. If an images's correct physical intensity is reproduced in a dim surround, a subjective effect called simultaneous contrast causes the reproduced image to appear lacking in contrast. The effect can be overcome by applying an end-to-end power function whose exponent is about 1.1 or 1.2. Rather than having each receiver provide this correction, the assumed 2.5-power at the CRT is under-corrected at the camera by using an exponent of about 1/2.2 instead of 1/2.5. The assumption of a dim viewing environment is built into video coding.


DOES PAL USE A GAMMA OF 2.8?

Standards for 625/50 systems mention an exponent of 2.8 at the decoder, however this value is unrealistically high to be used in practice. If an exponent different from 0.45 is chosen for a power function with a linear segment near black like ITU Rec. 709, the other parameters need to be changed to maintain function and tangent continuity.

======

I'd say the uppance of all this is that PAL's 2.8 gamma is overkill and just using 2.2 for both suffices nicely, especially given that they use the same ITU Rec. 601 bit encoding. This is why DVD producers don't go to the trouble of correcting to 2.8 for PAL disks.

Had enough?

Dr. Mordrid

[Flying dutchman]

Thanks for your extensive information, Doc! And yes, I think I've had enough.

The bottom line for me is that I can use unmodified YUV straight-through from DV/DVD to encoder.

For my own captures I will from now on calibrate the Marvel so that maximum signal level is slightly below 255, and use the "levels" filter in VirtualDub to compress this so the signal remains in the 16..235 region.

BTW, I have just ordered a firewire card (Dawicontrol DC 1394 PCI, based on TI chipset) that comes with Videostudio 5 SE. I assume/hope the Ligos codec is included, you never now with these "light" versions. Too bad it doesn't use Premiere plugins; I have grown rather fond of Avisynth because it allows me to do some custom filtering with VirtualDub plugins directly before rendering. The second-hand Premiere 5.1 I acquired a few weeks ago is hopelessly unstable, unfortunately.