[opendtv] Re: All colors of rainbow in new display concept

  • From: Cliff Benham <cbenham@xxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Tue, 22 Aug 2006 01:38:28 -0400

In reading all the comments on this topic I've only seen the displays mentioned.
Don't the cameras have to be capable of capturing wider color gamuts too?
Or do they already and it's now time for the displays to play catch up?


Don Munsil wrote:

-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx]
On Behalf Of Manfredi, Albert E





I think philosophically, no matter how you slice it, if you provide more
information (in the form of more colors), you will require more bits.
All else being equal. Don did mention that even to use the currently
illegal Y, Cb, Cr to expand your color gamut, you'd need more bits
assigned to the MPEG block coefficients. Otherwise, the additional
colors would come at the expense of more coarsely defined colors. Which
sort of defeats the purpose.



I thought this too at first, but really it doesn't require any changes at all to MPEG, doesn't theoretically require any more bits, compressed or uncompressed, and doesn't make the existing colors more coarsely defined. The MPEG DCT coefficients are already large enough to accept the full range of Y, Cb, and Cr values - they have to be, because at least some valid colors use the absolute fringes of at least one channel.

Colors that are on the outer limits of multiple Y'CbCr channels
simultaneously, which would in the past map to illegal R'G'B' colors, now
map to legal R'G'B' colors. So no extra bit depth is required in the Y'CbCr
space, or in the DCT-transformed space used by MPEG. Same goes for the
DCT-like transforms used in VC-1 and AVC. They're already using the full
range, just not simultaneously in all channels. If Cb is high, Y and Cr
can't be high at the same time in the current model. Under the new extended
gamut model, all three can be high simultaneously (or all low
simultaneously) creating a greater range of valid codes within the same code
space.

Ultimately this is just a much more efficient use of Y'CbCr coding. Under
BT.709 and similar standards, much of the code space is unusable. Not using
that code space really doesn't save much, if any, compression efficiency,
because each individual channel does use its entire code space. It's only in
combination that the code space is sparse. But all of these compression
systems encode the three channels separately, so increased use of the
combination space doesn't actually make more use of single channels. And if
I understand the math correctly, the Y channel really doesn't change - it's
just the Cb and Cr channels that extend their valid code space.

The above is all just my SWAG at the real answer. If some real video was
encoded using the extended gamut Y'CbCr standards and required more bits to
encode properly than the same video remapped into BT.709 color space it
wouldn't completely surprise me. But I'd be surprised if it was more than a
few percent.

Don





Other related posts: