openexr-devel
[Top][All Lists]
Advanced

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

Re: [Openexr-devel] On YUV support


From: Drew Hess
Subject: Re: [Openexr-devel] On YUV support
Date: Sat, 29 Nov 2003 14:15:19 -0800 (PST)

Hi all,

We have a new release coming out any day now which defines some more 
channel names, esp. for specifying color spaces.  Look for it next week.

We would also welcome a discussion on how to standardize other channel 
definitions.

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.  There might be a few advantages to using 
OpenEXR over PNG or other formats due to its ability to store channel 
attributes, but overall, yeah, there's no compelling reason to use OpenEXR 
for YUV.  I don't know of an application that does, currently.

There are also some new HD cameras which use log curves to encode HDR 
information in the signal, but whether these operate in some funky 
over-range YUV space or log-encoded RGB, I don't know.  I'll try to find 
out.

-dwh-



On Sat, 29 Nov 2003, Richard Annema wrote:

> Hi Billy,
> 
> Just to jump in on nomenclature, there may be a clash between that 'Z' and
> the 'Z' potentially used by 3D graphics applications to indicate the
> Z-Buffer.
> 
> Hopefully a more meaningful discussion between various developers can be
> started at some point on exactly these issues : standardization of channel
> names, definitions and formats. Mostly because I think the OpenEXR format
> should not end up in a situation in which there will be a "Written-by" type
> field indicating the application that wrote the OpenEXR file, with all other
> applications having to look up the specifics of how said application writes
> things when trying to read a file ( as suggested by somebody who shall
> remain nameless ).
> 
> We'd gladly be part of such a discussion.
> 
> Kindest regards,
> Richard Annema
> Director of Client Relations
> SplutterFish, LLC
> 
> 
> ----- Original Message ----- 
> From: "Billy Biggs" <address@hidden>
> To: <address@hidden>
> Sent: Friday, November 28, 2003 20:52
> Subject: [Openexr-devel] On YUV support
> 
> 
> >   The website has some notes on YUV support in OpenEXR and asks for
> > suggestions.  I would like to offer some.
> >
> >   EXR files currently store linear intensity values for RGB.  However,
> > the YUV used in video systems is always based on gamma corrected RGB:
> > the Y in a YUV system is not really luminance [1].  Because of this, I
> > do not see any way to convert from linear intensity RGB to the U, V
> > channels of a video system without clamping to [0,1], making the use of
> > EXR over a 16-bit per channel integer format like PNG seem useless.
> >
> >   Because of this, I would recommend dropping the idea of a YUV mode,
> > and the channel names U and V, until a better defined use case is found.
> >
> >   I do have an alternate suggestion for some more channel names in EXR
> > files.  Specifying colours as CIEXYZ triples is quite useful, and I
> > would recommend "X" and "Z" as channel names.  I would then recommend
> > changing this text:
> >
> >   Y  luminance, used either alone, for gray-scale images, or in
> >          combination with U and V for color images.
> >
> >   to this:
> >
> >   Y  luminance, used either alone, for gray-scale images, or in
> >          combination with X and Z for color images in CIEXYZ.
> >
> >   Which makes much more sense and seems a lot more useful.
> >
> >   Thoughts?
> >
> >   -Billy
> >
> >   [1] http://www.poynton.com/PDFs/YUV_and_luminance_harmful.pdf
> >
> >
> >
> > _______________________________________________
> > Openexr-devel mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/openexr-devel
> >
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]