[Openexr-devel] OpenEXR <-> Cineon/DPX

[Tom Dilligan]

I guess that I should specify a little better exactly where I'm coming
from (with more comments on some of the proposed fields).

At PacTitle we have a couple of scanners from FilmLight. One of the
features of this scanner is that it will scan to 14 bits per sample (and
outputs them as a 16 bit DPX file with the samples up-shifted 2 bits so
that the range is 0 to 65532).  Obviously this changes the whole
'specifying the black / white points as 95 / 685' at least technically
false (yes, you can up-shift these two bits).

I wonder exactly how closely people follow the min_code_value /
min_value and max_code_value / max_value parts of the header. For
starts, in DPX (and presumably in the Cineon sub-set), they are not
considered 'core' and are not always filled out (Discreet's Luster is
guilty of this). Another example is that Shake sets the max_value to 2.0
(no matter what was in the original file), but will not actually change
any of the code values (making everything off by about 2% if your input
file had a density range of 0 to 2.046) (Shake also uses the integer
value 0x4eff0000 (2139095040.0) in floating point fields to denote
undefined fields as opposed to the bit-pattern 0x4eff0000 (+inf), but
that's another rant).

So if it looks like I'm sort of jumping up on the table, throwing up my
hands and saying, "Well, it's not like a Cineon/DPX file is getting
interpreted consistently across all applications so we should just back
off and do this *right*", you are completely correct.

In regards to the Cineon/DPX <-> EXR I think that the following sweeping
generalizations can be made.

        *) For well behaved files (i.e. that we KNOW are actually
        dealing in density space, not the arbitrary 0 to 1023 space, and
        we know will be interpreted as density) we treat them as such.
        This encompasses files coming from film scanners and going to
        film recorders. I'd view everything else as suspect.
        
        *) For everything else we just say, well, 0 is 0 and
        (2^bit-depth -1) is a density of 2.046, and we just sort of hold
        on and hope for the best.

In the first case a EXR to Cineon/DPX converter needs to be supplied
with the Cineon/DPX bit depth and the density value that corresponds to
the maximum code value. Everything above that code value is clipped. For
converting a Cineon/DPX file to EXR it's trivial because we just
correctly interpret the code / density values. In the second case, we
just ignore the values in the header and use the above generalizations.


> "Haarm-Pieter Duiker" <address@hidden> on Wed, 9 Jun 2004 18:26:34 -0700 said:
>
> I would propose a new parameter to be called pdxWhiteReferenceLinear
> and have default values of {1, 1, 1}.

This makes me nervous. The white point implicitly states that values
above it are 'brighter than white', and that white is 1.0 (maximum
display brightness)? The log->linear curve continues upwards past the
white point, so that you can still pull values out of it, but just for
display purposes we have to clip it.


> Kevin Wheatley <address@hidden> on Thu, 10 Jun 2004 10:13:36 +0100 said:
>
> Tom Dilligan wrote:
> > I would suggest that the pdxBlackPoint, pdxWhiteReference, be stored as
> > floating point values, and that the pdxDensityPerCodeValue be dropped.
>
> Float, fine
>
> but why do you wish to do away with the density per code value ? the
> idea was to describe the transformation from OpenEXR to/from
> Cineon/DPX log encoding. That way somebody could send us a file in EXR
> and we'll fire it through our system to the recorders, without us
> having to choose the right values, for somebody.

At some point these floating point values have to become integers for
the D/A converters before <whatever> in your recorders. A calibration
strip run through the recorders would tell you what integer values are
associated with what densities. You take this to build a table to
convert from the EXR density values to whatever format the recorders
happen to like.

You don't have to choose the right values, the calibration does that for
you. The clients know that if a frame is sent in EXR format with
densities that's what they are going to get out of the recorder.

What I'm saying is that it's the recording companies responsibility to
do whatever voodoo is required to take the raw density values out of the
EXR file and put them in a format that their recorders like.


>>>Tom