The current Apple and Promax CODEC limit values to 16 and 235. Values above and below this number are clipped to 16 and 235 respectively. So what you say?

Well, many cameras, including the Canon XL1, can record values above 235. My experience with the Canon XL1 is that it can record up to 245 per color channel. When creating a dissolve or other effect using the footage, the transition between the end of the effect and the next frame of footage "pops." For example we have some footage where the subject is sitting and the sky is blown out behind him. When we dissolve this footage the image detail inside of the dissolve is clipped to 235 and at the end of the disolve, the next frame "pops" back to the full range of the source. (That is all the image detail between 235 and 245 is once again visible).

With regards to the Apple DV Codec clipping signal at 235, the ITU-R 601 Standard provides the lock-step reason for this decision. Nonetheless, it is wrongly implemented by Apple.

This is according to the Quantel Guide "The ADC [analog to digital converter] has only a finite set of numbers (an 8-bit ADC can output 256 unique numbers but no more) with which to describe the signal. The importance of this is such that the ITU-R 601 standard specifies this set-up quite precisely saying that black should correspond to level 16 and white to level 235 - leaving headroom for errors, noise and spikes to avoid overflow or underflow on the ADC."

In traditional terms, a level of 16 would correspond to 7.5 IRE and a level of 235 would correspond to 100 IRE. Apple has implemented these standards rigidly clipping the signal to 235 instead of using the overrun buffer up to 255. Even in the old world of analog, it was always possible to "over-modulate" the signal to a "hotter" level of say 105 to 120 IRE. With DigiBeta and D1, this is easily accomplished. What Apple has done is arbitrarily limit the ability to over modulate and thus use the available "headroom" described by the Quantel Guide. The fact that the Canon XL1 (and I suspect other DV cameras) can record a "hotter" signal speaks to the fact that this number of 235 is an artificial ceiling. Thus when dissolves or effects are rendered with the "hotter" footage, the Apple CODEC clips these values instead of using this extra headroom resulting in the "pop" I mentioned earlier. This headroom translates directly to the color spectrum available to the artists using the NTSC signal as well as contrast range. (Many commercials you see on TV exploit this extra headroom to deliver "hotter", "punchier" colors as well as greater latitude.) Furthermore, for those using DV for eventual output to film, the arbitrary broadcast standards of 7.5 and 100 IRE mean nothing and the full headroom of the signal should be available for use.

Since the 16/235 level corresponds to the technical level perhaps the ideal solution would be to write a CODEC which has selectable options for the 16/235 Standard as well as "full range" or user selectable upper and lower limits (similar to the Broadcast Safe filter in After Effects). Thus we could deliver product that either conforms or exploits the additional headroom available on DV, DigiBeta and other digital formats.

Phil

-- Phil Glau (CircusRedk@aol.com), March 21, 1999

Answers

The "popping" your seeing is caused by the inability of RGB data to be converted back to Y values > 235.

I looked into this issue while developing a M-JPEG codec. I believe my conclusion was the Y and the Cr/Cb values absolutly will/should be clamped to the ranges listed in the ITU-R 601 document. The issue is if you do YCbCr <-->RGB conversion in the codec, like many (most?) computer editing systems need, the color conversion matrix gives RGB values of < 0 or > 255, if your YCbCr values are outside the correct range. What your suggesting is the codec color space conversion should NOT map Y=16 to RGB=0 pixel values. The normal maximum Y value maps to RGB=255. If you adjust the color conversion matrix to make say Y=245 map to RGB=255, then NORMAL whites at Y=235 will be some value less than RGB=255 white. Of course a lot of codec's fumble the color conversion matrix and don't expand the Y in the 16-235 range to RGB in the 0-255 range correctly, they just map Y=16 to RGB=16, which is incorrect if you expect compatability with typical RGB images. The basic problem is video signals can go to > 100%, and computers can't. One fix would be for editing software to work fully in the YCbCr color space. You STILL would have the problem of imported RGB graphics (from say Photoshop) not being able to generate Y > 235.

There is also the little detail of gamma correction. A computer RGB image is generally non-gamma corrected, video data is pretty much always gamma corrected. If you make a RGB color bar chart at say 75% IRE, and feed it through most codec's, and then decompress it with video hardware codec's, and look at the waveform on a waveform monitor, the intensity values are wrong, as things were not gamma corrected. Gamma correction is unfortunatly a very processor intensive operation in software, and to correctly do requires 3 table lookups per pixel.

A lot of codec's also fumble the upsample/downsample filters for YCrCr<-->RGB. RGB is pretty much always 4:4:4 and YCbCr video almost never is. To implement a very high quality filter, potentially on XY for 4:2:0 video, requires a fancy multistage FIR filter. Fortunately newer short vector instructions (MMX or AltiVec) help here.

Software developers come down to the ugly tradoff of fast OR correct. It's only recently that correct functioning of codecs has gotten any attention, and I believe correct ones don't look so good performance wise next to fast ones. Image quality is not very easy to put in marketing ads, percent faster than brand Y is.

Actually your original "popping" problem is a performance issue, if you just recompress every frame, your "popping" will be gone, of course so will your performance for building. So are YOU willing to give up a bunch of performance to get a correct image?

Jan Bottorff, President Paradigm Matrix, Inc.

-- Jan Bottorff (janb@pmatrix.com), December 14, 2000.