[opendtv] Re: 1080P Question
- From: Kilroy Hughes <Kilroy.Hughes@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 16 Sep 2009 20:03:33 +0000
I am just focused on getting wide gamut encoded "right" at this point, but the
method HDMI uses to signal color boundaries might be a useful addition in an
SEI message (an optional/informative element in the H.264 bitstream). H.264
has specific VUI (Video Useability Information) parameters that are pitched to
the Display Process so it can implement the correct "render intent" e.g. wide
gamut. Only thing lacking is a method to signal "which wide?".
That is a major improvement over MPEG-2, which was designed when the world had
one choice (Rec 601), so the bitstream didn't have to deal with these options.
Kilroy Hughes
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of Stessen, Jeroen
Sent: Wednesday, September 16, 2009 4:26 AM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: 1080P Question
Hello,
Kilroy Hughes @ Microsoft wrote:
Ø I reviewed the deck and am newly inspired to advocate allowing xvYCC
(negative coefficient encoding in Y'CbCr).
I prefer if you say: (encoding of negative R'G'B' values in Y'CbCr). But let's
not forget
that xvYCC can (and probably will) also encode larger-than-unity values of
R'G'B'.
BTW, if Y'CbCr stay within 16..235(240) and add only the previously illegal
combinations of legal Y'CbCr values then (I think) the standard is called sYCC.
Ø Any recommendation on how to correctly represent that in H.264 encoded
content?
I'm not sure what you mean, or if I did that I would know the answer, but I
think that
it makes no difference to the (video) content, only to the metadata that
describes the
way the content is encoded. Is that what you meant ? In that case I can only
refer you
to the HDMI 1.3 and 1.4 specs, where they have tackled the same problem. I think
that there are similar references in MPEG-2. It's all in the metadata.
The only purpose for the "this is wide gamut" metadata bit that I can think of
is for
switching between gamut extension (for standard gamut content) and gamut mapping
(for wide gamut content). And this is not even very essential to have.
I think that even in the absence of any metadata, xvYCC would still work quite
well.
Of course you do need information about the R'G'B'<->Y'CbCr matrix (Rec.601
for SD, Rec.709 for HD), but that applies also to standard YCC.
Ø It looks like Transfer Characteristics = 11 signals IEC 6966-2-4; and
Primaries and Matrix Coefficients are the same as Rec 709 (VUI value = 1).
Ø Some inaccuracy there, but Transfer Characteristics different from Rec 709
should encourage some guessing as to what real primaries were encoded.
True, basically you just need a few bits to signal that a wide-gamut standard
has been
used, and perhaps distinguish between a few variations. Nothing of it is
essential IMO.
On top of that, HDMI also allows to send "Gamut Boundary Metadata", which can
describe very accurately what the source gamut is. This can be simplified to the
original color primaries, i.e. the source gamut is an RGB cube with primaries
that are
different from Rec.709 (a.k.a. sRGB). But it is also possible to encode an
irregular 3D
shape in all its detail. I think that very few people really ever want to use
this, so I don't
know if this will ever be picked up by broadcasters or receivers. It's optional
anyway.
The real camera primaries themselves do not matter, of course, since they have
been
replaced by (color space converted to) the Rec.709 (sRGB) primaries for xvYCC
encoding. The color space that is actually used will be smaller than an RGB
cube, it
is described by a 2D contour like the "Pointer color set" or the 3D "Munsell
cascade"
variant. Knowing the edges of the source gamut is supposed to help you with
tuning
of the gamut mapping or gamut extension.
Note that HDMI 1.4 distinguishes a few of the professional (photo) color spaces,
meaning that the data is referred to the actual (non-standard) color primaries.
This
avoids the conversion to the Rec.709 referred xvYCC color space, and permits a
single conversion to the target (display) color space. There is no
compatibility with
Rec.709 standard displays, but if the target refuses to accept it then the
source will
have to convert the data to an acceptable format (xvYCC or even standard gamut).
I suppose that these color spaces were added for connecting professional cameras
directly to a display (via HDMI), and transfer the image data as in the JPEG
files.
Groeten,
-- Jeroen
Jeroen H. Stessen
Specialist Picture Quality
Philips Consumer Lifestyle
Advanced Technology (Eindhoven)
High Tech Campus 37 - room 8.042
5656 AE Eindhoven - Nederland
________________________________
The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended recipient,
please contact the sender by return e-mail and destroy all copies of the
original message.
Other related posts:
