openexr-devel
[Top][All Lists]
Advanced

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

Re: [Openexr-devel] exchanging exr's


From: Florian Kainz
Subject: Re: [Openexr-devel] exchanging exr's
Date: Thu, 10 Jun 2004 16:49:50 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314


As Drew mentioned yesterday, we have been discussing OpenEXR
image interchange for a while at ILM.  We are working on a
proposal for doing this that is different from Ken McGaugh's.

The data in OpenEXR files are meant to be scene-referred,
that is, the numbers stored in the pixels are proportional to
luminance values in the original scene.   (The chromaticities
and whiteLuminance attributes tie the pixel values to real-world
units.)  With scene-referred data, it is possible to import
images from different sources, for example film and digital
cameras, into a common space, so that combining the images
produces meaningful results.  For example, you should be able
composite an image that originated on film over an image taken
with a digital still camera; or use an image from a panoramic
HDR camera to light a computer-generated object, and composite
the result over a plate shot on film.

If you convert a DPX file to OpenEXR and back to DPX with the
method proposed by Ken, the new DPX file is a duplicate of the
original DPX file.  The pixel values in the OpenEXR file are
roughly proportional to scene luminance values, so that the
OpenEXR can easily be processed.  For a project where all input
images orginate on the same type of film stock, this works just
fine.  However, with Ken's method, it is not easily possible to
convert images from different sources into a common space.

In the near future, we intend to propose a more general method
for OpenEXR image import and export, which will work roughly like
this:  Attributes in an OpenEXR file's header specify the source
from where the image was imported, or the destination for exporting
the image.  The attributes also refer to the transformation that
was applied to the pixels during importing, and to the transformation
that should be applied during exporting.  The actual transformations
are specified in separate files.  (The specifications can be rather
long, and embedding them in every image would be a waste of file
space.)  The specification format will be general enough to describe
Ken's method, but it will also allow more accurate descriptions of
specific film stocks or entirely different input and output media,
for example, video.  We intend to supply an open-source software
library that can read color transformation specifications and
transform pixel data accordingly.  Stay tuned...

Florian







reply via email to

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