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

[Ken McGaugh]

Firstly, I think Kevin summed up all of our reasoning behind this
proposal much better than I could have.  But I'll comment on a few
responses...

Tom Dilligan wrote:
> 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.

I think there is some confusion here.  We do not propose sending exr's
for filmout that have pixel values representing densities.  The pixel
values in the exr are assumed to be proportional to (roughly) linear
light intensities, and the pdx* attributes describe how to convert those
back into densities.

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

The 95 / 685 numbers are just defaults.  If they are not common enough
we can change them.  Alternately, we can make all the attributes required
if need be.  But you wouldn't need to do any upshifting of the black/white
values.  All you need to do is specify them relative to your 0-65532 range
(ie. 43880.18 / 6085.57) and then choose a pdxDensityPerCodeValue which
squeezes the results into your 0-2.046 density range (ie. 3.122e-5).

In practice I don't plan on every shipping an exr that doesn't have all
of the pdx* attributes fully specified.

>
> I would suggest that the pdxBlackPoint, pdxWhiteReference, be stored as
> floating point values, and that the pdxDensityPerCodeValue be dropped.
>
> Since the EXR format supports floating point numbers, there is no
> particular reason that we need to continue to hedge to the cineon/dpx
> method of encoding the floating point density values.
>

Actually, the pdxBlackPoint and pdxWhiteReference are stored as floating
point values since the attributes would be of type Vec3f. I just dropped
off the ".0" in the default values to be concise, which I guess was misleading.

Please note that we purposefully over-specified the number of a parameters
needed to do the conversion so that it was general enough to work with numbers
that are familiar with different camps.  This is also why the default
black/white points aren't normalized to be between 0 and 1.  It has been
quite a struggle to get the supervisors who are all old-school cineon operators
to adopt a linear workflow.  If they have to start dealing with numbers they
don't recognize they'll never go for it.


Thanks.
--Ken