Re: [Openexr-devel] Half samples & DPX

[Florian Kainz]

Bob,

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.

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.)

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.

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.

Florian



Bob Friesenhahn wrote:
> A SMPTE workgroup is currently re-working the specification for the 
> venerable DPX file format.  I know that several people on this list have 
> been involved in the discussion.  A new planned addition is support for 
> Half samples as used by OpenEXR.  There was already support in the 
> specification for storing 32 and 64 bit floats.
>
> It seems to me that there needs to be a bit of file metadata to allow 
> Half data to be exported from OpenEXR into DPX while preserving the 
> original intent of the values.  DPX is a very spartan format so 
> exporting a full CTL description is not a good fit.  In DPX, standard 
> colorspace transforms are indicated by reference (e.g. as an 
> enumeration) and non-standard transforms need to be managed (by the 
> user) using an external LUT.
>
> I am interested to hear any ideas as to what the minimal amount of 
> metadata needs to be in order to support exporting an RGB(A) rendition 
> of the image from OpenEXR into a simple float representation suitable 
> for viewing, grading, or sending to a film printer.  Is there a standard 
> Half (or floats in general) sample representation which allows 
> viewing/interpreting the image without using exotic color management 
> approaches like CTL?
>
> Bob
> ======================================
> Bob Friesenhahn
> address@hidden, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel