Caps for full-range YUV data?

[David Schleef]

On Thu, Jul 28, 2011 at 11:37:07PM -0400, Gruenke, Matt wrote:
> Therefore, for both practical reasons and the precedent set by these
> standards & implementations, I feel a separate 'video-range' property
> would be warranted.  Did you consider this option, or what's the
> rationale behind 'color-matrix'?

Yes, I considered several options, including adding fields for transfer
characteristics, color primaries, etc.  It turns out that none of these
are relevant, because nobody uses them for real work.  Everyone sticks
to the two standards, BT.601 and BT.709, which we've conveniently labeled
as "sdtv" and "hdtv".  From those two values, you can infer the matrix,
offsets, excursions, color primaries, and transfer characteristic.  It's
also extensible, so "jpeg" can be easily added, for data in standard JFIF
matrixed form and sRGB primaries and transfer characteristic.

Technically, there are different color primaries between NTSC and PAL
for stdv, but the difference is so slight that it's almost completely
invisible.  Even the difference in primaries between SD and HD are
minor and nearly invisible.

In the unlikely event that someone needs transfer characteristic, etc,
fields in the future, we can easily expand to that too.

Over the years, I've heard a number of people ask "But 255 > 219, isn't
full-range YUV more precise?"  The answer is no, because it's almost
always compressed (not to mention noisy), in which case the precision
is entirely dependent on the codec bitrate.  And if you're doing
uncompressed and care about precision, you'd use 10-bit video.



David