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

c/ Luma coefficients for DTV



Dear TIG -

There is an issue that I think ought to be addressed in the transition to
DTV and ATV: the choice of luma coefficients.

The world has effectively standardized on a single set of RGB primaries
(SMPTE 240M primaries and Rec. 709 primaries, surrounded by appropriate
tolerance boxes). R'G'B' signals are effectively identical, independent of
scan format, world-wide. (This even extends to computing.) SDTV and HDTV
will code exactly the same R'G'B' values for a given image (or signal).

In component digital video, and component digital HDTV, we don't record,
process, or transmit R'G'B'. Instead, we form Y'CbCr. Standard video has
since 1953 used this formulation of luma (Y'):

  Y' = 0.299 R' + 0.587 G' + 0.114 B'

(This is different from "luminance", and ought not to be called that. See
"YUV and luminance considered harmful: A plea for precise terminology in
video", in Acrobat PDF format at
<http://www.inforamp.net/~poynton/PDFs/YUV_and_luminance_harmful.pdf>.)

In HDTV, the SMPTE 240M and 274M standards, wrongly in my opinion, call for
these coefficients:

  Y' = 0.212 R' + 0.701 G' + 0.087 B'

If Y' is encoded according to the first equation for SDTV, and according to
the second for HDTV, then luma is coded into different numbers. The Cb and
Cr scale factors depend upon the luma coefficients, so Cb and Cr will be
coded differently as well. (Rec. 709 coefficients are roughly similar to
the 240M numbers, but different in detail: 0.2126, 0.7152, 0.0722.)

Owing to the unwise decision to change the luma coefficients, the same
image (or signal) will code into different Y'CbCr values. For picture
content that starts out identical, small (SDTV) video will have different
Y'CbCr codes than big (HDTV) video.

This decision obligates upconverters and downconverters - both in the
studio, and in consumer equipment - to perform a color transformation - a 
3 x 3 matrix multiply every pixel. (Alternatively, Y'CbCr can be transcoded
back to R'G'B' prior to standards conversion, and recoded to Y'CbCr, with
different coefficients, afterwards.) Color correction could be accomplished
manually for conversions in the studio, but this would add to the
production workload. If the necessary color transformation (or color
correction) is not performed, very serious color errors are introduced.
Failure of converters to make the necessary corrections will be evident
from colorbars being reproduced with incorrect colors.

A few people have argued that an incremental performance advantageaccrues
from changing the coefficients. I have examined the numbers, and in my
opinion, the performance advantage is negligible. (When I say that the
performance difference between the two systems is negligible, I mean if
each encoder is used with the appropriate decoder. If encoding and decoding
is mismatched, the color errors are huge.) Not only is the numerical
difference in performance very small, but no simulations have demonstrated
any perceptible improvement in any actual pictures. In any event, the
advantage would accrue only if HDTV were a closed system. ATV is not, and
never will be, a closed system.Choosing a new set of color coding
parameters for HDTV injects a huge and persistent conversion problem into
HDTV, ATV, and DTV.

I argue that none of this is necessary. I argue that the sensible approach
is to retain, for all forms of DTV and HDTV, the luma coefficients that
have served well since 1953. The MPEG-2 datastream provides for an
indication of the luma coefficients used, and Rec. 601 coefficients are
accommodated there. I argue that the ATSC and SMPTE specs should mandate -
or at the very least allow - Rec. 601 luma coefficients.

I presented a paper on this topic at the SMPTE conference in Toronto this
February. An abstract of that paper is available:

  <http://www.inforamp.net/~poynton/papers/SMPTE_98_YYZ_Luma/index.html>

Some other related information is available at my web site:

  <http://www.inforamp.net/~poynton/notes/video/Constant_luminance.html>

I suggest that this issue should be discussed at the upcoming T3S6 meeting.
I cannot attend; I will be at SIGGRAPH in Orlando all next week. If any of
you are able to attend my SIGGRAPH color or video courses there, those
courses describe the derivation of (true, CIE) luminance, the Principle of
Constant Luminance, the derivation of luma coefficients, and the scaling of
color difference components.

  <http://www.inforamp.net/~poynton/notes/events/19980920a_SIGGRAPH.html>


C.

-- 
Charles Poynton 
<mailto:poynton at poynton.com> [Mac Eudora, MIME, BinHex, uu, qpv]
<http://www.inforamp.net/~poynton/>

---
Thanks to Queue Systems and Lipsner Smith for support in 1998.
No product marketing allowed on the main TIG.  Contact rob at alegria.com
998 subscribers in 39 countries on Wed Jul 15 20:12:54 PDT 1998 
subscribe/unsubscribe with that Subject: to telecine-request at alegria.com
complete information on the TIG website http://www.alegria.com/tig3/