[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RGB/YUV Color Space Issues



This thread is covering two different, but related, topics:
color space conversion, and headroom. My comments are more
to the headroom issue.

>             Most YUV to RGB color space conversion engines 
> take the D1 standard "as is" and map YUV black (16,0,0) to RGB 
> black (0,0,0) in their calculation.  

Again the point needs to be made that the original CCIR put headroom
in the 601 standard for a reason: to avoid clipping distortion.
0-255 mapping has no headroom, therefore it has the problem.
Sure it's easier to write software for a 0-255 mapping, and it's
computationally more efficient - but it still has the problem.

> The new architecture of the Onyx2 and Octane is now
> much more flexible in remapping how RGB correlates to YUV and we 
> are experimenting with these possibilities, we just want to be 
> careful before we introduce this new approach. 

SGI made it more flexible because their customers were beating
them up about it. Also, this "new" approach has been around in
signal processing for quite some time (allowing for headroom).

> Especially since this is pretty much only happening when
> using an analog source because most A/D converters will also put 
> information in what was designed to be used as headroom..

Digital filters, for example the interpolation filters in your
own software, will overshoot. If you clip the overshoot, you will
create distortion, e.g., hue shifts and mach bands.  Example:
Try expanding in size a black and white crosshatch test pattern - 
say 4 times original size. As the interpolation filters kick in 
they will over/under shoot. If you are using 0-255 levels - there
is no headroom - and the over/under shoot will be hard clipped. 
Result: mach bands.  Now if you repeat the same experiment with 
20%/80% white, instead of 0%/100% white, guess what - no mach 
bands (because you have created headroom).  
So here's the crux of the biscuit: you either allow for headroom 
above 100% white, and below 0%, or, you will distort normal video
in a normal operation, as in the above example.

>                     The [digital] audio 
> industry now know that you can't push a signal out of it's limit 
>to make it sound a bit warmer...

Current digital audio practice allows 20 db headroom (0.0 Vu to 
full scale digital.
 
> -> I also do not totally agree with that. Hue shifts and banding
> artefacts are the results of clipping when a YUV signal ranges 
> outside of what a color space converter is expecting and also 
> possibly the result of a computation not precise enough. 

Hue shifts and banding are the result of clipping, be it from 
level mapping or color space conversion. For example, if a video 
highlight - that exceeds 235 - is hard clipped when 235 is mapped
to 255, it will create mach bands and hue shifts just like color
space conversion.

> With the 36 different flavors of DTV that the FCC has adopted, I
> believe that the post and broadcast industry will have to embrace 
> the new RGB computer-based systems and learn to live with it: the 
> good ones (and we're really proud of them) and the less good ones..

I don't think anyone has a problem embracing RGB based computer
systems - I think Discrete Logic makes some fantastic products. 
But the computer graphics world still has a serious case of 
headroom denial. Overshoot happens. It's Mother Nature. 
And you can't fool Mother Nature with 0-255 mapping.

John Abt

---
thanks to Neil Kempt for support of the TIG in 1998
TIG subscriber count is 910 on Thu Dec 18 18:24:29 PST 1997
complete information on the TIG website http://www.alegria.com/tig3/