[opendtv] Re: negative RGB
- From: Tom Barry <trbarry@xxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Thu, 13 Jan 2005 09:17:37 -0500
Tom McMahon wrote:
> As an aside, when using XYZ, all of those unused non-visible code values
> don't seem to hurt the compressed bitrate any. Neither
> does going from 8 bits to 10 or 12 bits/component, at least with H.264.
I have sometime wondered about that. It seems that, at the same bit
rate, 8 bit would be very similar to 10 bit quantized slightly more by
the encoder. Of course then at high bit rates 10 or 12 bits might start
to be different, and better. But at lower rates, does it make a difference?
- Tom
>
> -----Original Message-----
> From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
> Behalf Of Alan Roberts
> Sent: Thursday, January 13, 2005 5:47 AM
> To: opendtv@xxxxxxxxxxxxx
> Subject: [opendtv] Re: negative RGB (was: "we'll forever be stuck with by
> going ATSC")
>
> Jeroen,
>
> the idea of allowing negative (and super white) values for RGB is
> entertaining and interesting. ITU1361 introduced it in about 1990
> when we were thinking about wide-gamut and constant-luminance coding for
> HDTV. I did a lot of analysis work then, and am still doing
> some in retirement.
>
> The problem is that. although it increases the analysis gamut, it isn't
> enough to cover the more saturated cyan/greens we are seeing
> now, and it grossly codes a huge gamut of non-existent colours. In fact, it's
> a far less efficient gamut extension system that
> simply using XYZ as the aiming primaries in the camera. I have a wonderful
> demonstration of this, and showed it at the recent RTS
> HDTV colloquium in Reading.
>
> It really isn't a sensible way to extend the gamut.
>
> ----- Original Message -----
> From: <jeroen.stessen@xxxxxxxxxxx>
> To: <opendtv@xxxxxxxxxxxxx>
> Sent: Thursday, January 13, 2005 8:04 AM
> Subject: [opendtv] Re: negative RGB (was: "we'll forever be stuck with by
> going ATSC")
>
>
>
>>Hello,
>>
>>John Shutt wrote:
>>
>>>I see how you can manipulate the numeric values of component to create a
>>
>>>negative value of RGB, but how does a camera produce a negative value of
>>
>>>RGB? (Does light shoot out of the CCD?) How does a CRT, LCD, or Plasma
>>
>>set
>>
>>>display a negative value of RGB (does the room get darker?)
>>
>>As I have recently hosted the "wide colour gamut and HDTV seminar"
>>in Eindhoven, starring Charles Poynton, I have given a lot of
>>thought to the subject of gamut mapping. Allow me to explain.
>>
>>The ideal colour camera (and not all of them are ideal) will
>>capture all the colours that the human eye can distinguish.
>>Since the typical eye uses only 3 different sensors, named
>>LMS (for long, medium and short wavelength, loosely comparable
>>to red, green and blue), the perception can be described in
>>3 dimensions, leading to the tristimulus theory. We can
>>transform to any other threedimensional space, e.g. with the
>>luminance as one of the dimensions. The other two dimensions
>>are then "colour", e.g. x,y or u',v' or saturation and hue.
>>
>>If we draw this two dimensional colour plane, then the range
>>of perceivable colours is limited by a "horseshoe" shape of
>>spectral colours, and the magenta line. It is not at all
>>difficult to design a camera that can capture this entire
>>area, although tradeoffs must be made for signal/noise ratio.
>>Since many colours do not regularly appear in nature, one
>>such tradeoff is to limit the colour gamut to a smaller
>>triangle, defined by its 3 corners known as the RGB colour
>>primaries. These are defined by standards, like NTSC 1953,
>>EBU Tech.3213, SMPTE 240M. Today's de-facto standard for the
>>colour primaries of ALL television systems is ITU R.709.
>>In CGI applications many more gamuts exist. The ultimate
>>set of primaries is XYZ, they form a triangle that is much
>>larger than the horseshoe and is therefore not limiting.
>>(The triangle is in fact way too large, but XYZ has the
>>"benefit" that the luminance is represented by only Y.)
>>
>>The R.709 triangle is quite limited, especially the green-
>>blue line cuts off a lot of saturated cyanish colours. As
>>cyan is not a popular colour in nature, this is no big deal.
>>But a camera might capture a cyan that does not fit inside
>>the R.709 triangle. Encoding a captured colour, e.g. from
>>a camera with XYZ or LMS primaries to a signal format with
>>R.709 primaries, involves a 3x3 matrix operation in linear-
>>light domain. This matrix has the effect of increasing the
>>saturation factor, i.e. increasing the gain for the colour-
>>difference signals. This can and will cause negative values
>>on any of the RGB outputs, like in the example of extreme
>>cyan: the red output will go negative. Cameras include
>>clipping circuits to take care of this, thereby limiting
>>the colour gamut to the triangle of the colour primaries.
>>
>>A wide colour gamut camera would transform to a larger
>>triangle (possibly as large as XYZ, for the latest digital
>>cinema proposal) by applying less gain to the colour
>>difference signals. But this leads to weaker signals, less
>>efficient use of the code space, less signal/noise ratio.
>>And it would not be compatible with current standards.
>>
>>The camera outputs only legal RGB signals. We can very
>>easily make illegal signals again by applying saturation
>>control with gain > 1. The easiest way is by amplifying
>>the B'-Y',R'-Y' signals (a.k.a. Pb,Pr or Cb,Cr or U,V).
>>This too can cause negative R',G', or B' signals. So the
>>the television receiver must also have a clipping circuit
>>to handle these illegal values. In the simplest case this
>>is just the beam cutoff of the picture tube. The result
>>will be a distortion of the colour gamut, because this is
>>a too crude form of gamut mapping. In CGI, much more
>>advanced forms of gamut mapping must be applied, in order
>>to preserve some faith in the displayed colours.
>>
>>To summarize: negative (RGB) values are not needed for
>>representing negative light (super darkness ?) but for
>>representing colours that are outside the gamut as it is
>>defined by a too small triangle of primary colours.
>>Some signal standards like e-sRGB or sRGB64 define extra
>>headroom for preserving these undershoots, and also over-
>>shoots. This is just one way of handling wide gamut.
>>Headroom is also good for preventing clipping artefacts,
>>like due to the ringing of anti-aliasing filtering.
>>
>>Note that legal Y'UV signals can already cause negative
>>R'G'B' signals, so they are already somewhat wide gamut.
>>But my favourite way of dealing with a wide colour gamut
>>would be to specify a saturation correction factor in an
>>otherwise standard TV signal (i.e. with R.709 primaries).
>>This would change nothing to the handling of the luminance
>>component (no extra headroom, no wasted code space), it
>>only applies a controlled gain to the colour differences.
>>
>>Best regards,
>>-- Jeroen
>>
>>+-------------------------------+----------------------------------------+
>>| From: Jeroen H. Stessen | E-mail: Jeroen.Stessen@xxxxxxxxxxx |
>>| Building: SFJ-5.22 Eindhoven | Philips Digital Systems Laboratories |
>>| Phone: ++31.40.2732739 | Visiting & mail address: Glaslaan 2 |
>>| Mobile: ++31.6.44680021 | NL 5616 LW Eindhoven, the Netherlands |
>>| Pager: ++31.6.65133818 | Website: http://www.pdsl.philips.com/ |
>>+-------------------------------+----------------------------------------+
>>
>>
>>
>>----------------------------------------------------------------------
>>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.
>
>>
>
>
>
>
> ----------------------------------------------------------------------
> 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.
>
>
>
>
>
> ----------------------------------------------------------------------
> 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.
>
>
----------------------------------------------------------------------
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:
