Re: [Openexr-devel] Half samples & DPX

[Bob Friesenhahn]

On Tue, 6 Mar 2007, Florian Kainz wrote:
> Of course you'd handle DPX 16-bit float samples the same way you treat
> 32-bit and 64-bit samples...
>
> Seriously, how you treat the 16-bit float samples for viewing, color
> grading etc. depends on what the samples mean.  Three possibilities
> come to mind immediately:
>
> A) The samples might represent the amount of light emitted by the screen.
>   In this case, the conversion for viewing is straightforward: make the
>   screen emit the amount of light specified by the RGB samples you get.
>   Defining the primaries and white point of the DPX image would probably
>   be enough to make this work.

This seems useful and since DPX already has a way to specify primaries 
and white point, not difficult to incorporate.

> B) The samples might represent light in the depicted scene.  In this
>   case you need a rendering transform that converts to light on the
>   screen.  The problem is no more or less difficult than with OpenEXR
>   or any other scene-referred floating-point format.  (In my opinion,
>   the Academy's Image Interchange Framework committee is pretty close
>   to resolving the issue.)

This approach does not seem to be common for DPX, which is usually 
output referenced.  DPX is usually used for telecine/datacine or for 
grading and output to a film printer.

> C) The samples might represent the density of a scanned Film negative.
>   In this case you treat the images the same as DPX files with 10-bit
>   integer samples.

This sounds valuable to vendors who want the extended range of floats 
but want to preserve the density approach.  I think that this is 
supportable with existing metadata as well.

> I suspect there is no _simple_ answer that will satisfy everyone.  If
> someone does find a simple solution to the HDR color management problem,
> it should apply equally to DPX, OpenEXR and floating-point TIFF.  "Exotic"
> techniques such as CTL, Truelight, ICC profiles, and the in-house lookup
> table formats used by various production companies exist because so far
> nobody has found anything better.

Agreed.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/