[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: i/ Luma coefficients for DTV
Craig B writes concerning luma coefficients,
> The problem that Charles cites with 601 and 709 colorimetry
> is a trivial task ...
I am intimate with color management systems. I can assure you, the
computational load for these sorts of corrections on 60 million pixels per
second is large. A 3x3 matrix multiply of the sort necessary for luma
coefficient correction takes 6 or 8 multiplies and 6 or 8 adds. (That is
more computation per pixel than is necessary to perform 8x8 DCTs across the
whole image.) For 60 million pixels per second, 6 or 8 multiplies and 6 or
8 adds requires about 840 million operations per second. This is
prohibitive for software, and a nuisance for hardware - especially for
correction of color coding that could have been done right in the first
> ... for a color management system to deal with.
The 3-D table-based interpolation algorithms employed by ICC-based color
management systems have much more computation that 6 or 8 multiplies and 6
or 8 adds per pixel. Jan de Clippeleer (Agfa), Ed Giorgianni (Kodak), and
Michael Bourgoin (Adobe) - all world-class color management experts -
detailed these calculations at the "Color Management: Theory and
Implementation" course that was presented a week ago at SIGGRAPH 98.
(I organized that course.)
But the larger issue remains:
NO FUNCTIONAL OR PERFORMANCE ADVANTAGE IS GAINED
FROM CHANGING THE LUMA COEFFICIENTS. (Sorry to shout.)
> I certainly am not going to lose sleep over something
> that is so easy to deal with ...
I hope my shouting didn't disturb your sleep, Craig. I repeat, though:
It's not easy to deal with.
> ... fundamental change that will deliver real benefits.
> So let's stop arguing about the piddling differences between 601
> and 709 colorimetry and start talking about a quantum leap in the
> colorimetry we can deliver to everyone ...
Be specific, Craig. I suppose you want wide gamut. But altered luma
coefficients do not contribute to that goal.
> If we extend Charles argument to it's logical conclusion, we must argue for
> a DTV system with only one format, one colorimetery, one luma equation ...
I am in favor of programmable parameters when a functional benefit accrues,
and where the parameter can be made programmable without imposing a large
cost burden or performance disadvantage. A fixed-size hex wrench is a lot
more efficient than an adjustable wrench or a pair of vise-grips. If you can
achieve timely standardization, a reasonably small set of sensibly-chosen
standards is the way to go. (I have a set of 14 hex wrenches, of standard
sizes.) No functional benefit accrues from infinitely-variable hex-nut
sizes, and we do not need infinite programmability in image sizes at
aquisition or display (and some people would argue, in distribution).
A small set of closely-related, sensibly-chosen rasters should suffice.
> SMPTE should ... be developing an infrastructure where we can support any
> colorimetry, including ... extended range luma (10-14 bits log) ...
As founding chairman of the SMPTE DPX initiative for the exchange of
digital film, and co-organizer of last year's SIGGRAPH course on "Scanning
and Recording Motion Picture Film", I am fairly familiar with film coding.
I've no idea what you mean by "extended range luma". Log coding is
widespread, but it's RGB, not luma and color differences. I'd welcome a
serious, technical discussion about how to extend video and film coding.
But it's not related to luma coefficients.
<mailto:poynton at poynton.com> [Mac Eudora, MIME, BinHex, uu, qpv]
Thanks to Filmworkers Club Dallas for support in 1998.
No product marketing allowed on the main TIG. Contact rob at alegria.com
998 subscribers in 39 countries on Sun Aug 2 13:11:18 PDT 1998
subscribe/unsubscribe with that Subject: to telecine-request at alegria.com
complete information on the TIG website http://www.alegria.com/tig3/