Re: [Openexr-devel] On YUV support

[Billy Biggs]

Kevin Wheatley (address@hidden):

> Drew Hess wrote:
> > Billy, re: your YUV comments, I tend to agree with you.  The OpenEXR
> > format doesn't require that files store linear intensities (though
> > that's what applications expect for RGB triples, anyway), so "YUV"
> > could be stored gamma-corrected 0-1. [...]
> 
> it's perfectly valid to have values outside of 0-1 in "YUV" (Y'CbCr,
> Y'PbPr, etc etc) if they come from another colour space by means of a
> 3x3 matrix transform, they represent items outside the gamut of "YUV".
> (Just like its valid not to have subsampled CbCr when dealing with
> "4:4:4" material.) 

  My argument is that this should never happen since the gamma functions
for most spaces are undefined outside of [0-1], so given out-of-gamut
values in a gamma corrected space, I'm not so sure that you can say
which colour you mean.  You can only go to other gamma corrected spaces
using a 3x3 transform of Y'CbCr values, so they're all really tied to
the R'G'B' space they correspond to and its corresponding functions.

> Storing 'gamma corrected' data means you also would ideally want to
> store the encoding method somehow, e.g. like SMPTE 268M (DPX) v2.0 as
> a { gamma, black level, black gain, break point, reference white level
> } tuple. as well as some reference to the colour space they represent
> (ITU-R 709-5, 601-5 system B or G, 601-5 system M, SMPTE 274M, etc
> etc).

  Agreed.

  -Billy