[opendtv] Re: RGB mania

  • From: Craig Birkmaier <craig@xxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Fri, 14 Jan 2005 12:08:03 -0500

At 12:51 PM +0100 1/14/05, jeroen.stessen@xxxxxxxxxxx wrote:
>I can think of 3 _potential_ disadvantages of an RGB link:


>Joe Kane mentioned this one in 1997: with analog RGB there is the
>risk of offset or linearity errors that would affect the greyscale
>tracking. With YUV you know at least that the greyscale is
>carried by only the Y signal. But an offset error (clamp error)
>on the U&V signals is at least as destructive to the greyscale
>tracking, so this is not a very valid argument for YUV either.

Yup. The FIRST analog component switcher we built at GVG used RBG 
processing - we quickly learned that that was a BAD idea. Try getting 
three multipliers to track perfectly during a dissolve. Any tracking 
errors show us as luminance errors.

With YUV processing it is possible to largely avoid this issue.

With digital processing this become less of an issue, if you do the 
math correctly.

>
>3.
>With digital RGB "graphics" signals (e.g. DVI out) it is common
>to have black = 0, white = 255, but with digital YUV "video"
>signals (e.g. ITU-R.656 or SDI) it is common to have black = 16,
>white = 235. The Y signal has headroom that the RGB signals have
>not. This headroom is reserved for the ringing due to anti-
>aliasing filtering, and thus plays a role in the perfect recon-
>struction of the original analog video signal. However, if the
>target is a display with digital RGB inputs, and the signal must
>be limited between black and white anyway, then it does not seem
>to matter whether this limiting is applied before an RGB
>interface or after a YUV interface. Only if such display contains
>an up-scaler then it would be beneficial (for aliasing) to apply
>the limiting after the scaler, and opt for the YUV interface.

This is true, but largely a legacy problem.

Set-up is no longer an issue -we haven't needed it for decades. But 
proper coding of luminance IS a major issue, especially if we want to 
approach the characteristics of film. As Tom McMahon noted we really 
need 10 or 12 bits, and we need more values at the ends of the range 
than in the middle.

I was pleased to see Alan and Jeroen talking about gamuts that extend 
not only the range of legal color values, but the coding of luminance 
as well. Alan wrote:

"The emphasis should now be on investigating CIELuv or CIELab or something
similar, because they allow seperate treatment of true luminance and colour,
and that's where all the benefits lie. "

Exactly. We want to preserve EVERYTHING that the camera sees, and 
make decisions about what to throw away in post, during color 
correction. We want the "printing" latitude we enjoy today with film 
negative, where we have enough information to bring out details in 
the blacks and the whites. And we need to support colors that may not 
exist in nature, because they exist inside the heads of graphic 
designers, who have become accustomed to the full gamut of colors you 
can work with in 24bit RGB colorspace.

Regards
Craig
 
 
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 
FreeLists.org 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: