Re: [Openexr-devel] does half round-trip?

[Florian Kainz]

Going from 16-bit half to 32-bit float and back to half is lossless,
at least if you use ILM's Half library to do the conversion.  The set
of possible half values is a subset of the possible float values, so
every half can be represented exactly as a float, with no roundoff.

Conversion from a 10-bit log value, i, to a half value, h, is typically
done like this:

        // d is the printing density that corresponds
        // to Cineon/DPX integer code value i.

        double d = i * 0.002;

        // h is the "linear light" value that corresponds
        // to density d.  We assume that the film's gamma
        // is g.  We map the digital LAD value, l, to 0.18.

        double g = 0.62;
        double l = 0.89;
        half h = 0.18 * pow (10.0, (d - l) / g);

With a negative gamma of 0.62, the half values that correspond to i and
i+1 are always separated by at least 7 quantization steps.  (In other
words, h(i) is always less than h(i+1), and there are always at least
6 distinct half values that are greater than h(i) and less than h(i+1).)

The separation separation decreases with increasing negative gamma, but
even with a gamma of 1.0 the half values that correspond i and i+1 are
at least 4 quantization steps apart.

This means that a roundtrip from Cineon's 10-bit log to half and back
can be made lossless.  The following does in fact reliably recover the
original 10-bit log value from a half:

        double d = l + g * log ((h / 0.18)) / log (10.0);
        int i = int (d / 0.002 + 0.5);

Florian



Ken McGaugh wrote:
> I wrote a small program a while back to test this and it did
> round-trip without any loss.  For every 10-bit code value there
> was exactly one 16-bit half.  But in shake you have the extra
> step of going through 32-bit float which may introduce some
> rounding errors.
>
> Paul Miller wrote:
> > I'm working on an updated Cineon I/O module, and when I use 16 bit 
> > int, with the Cineon log data stretched to 0-65535, I can round-trip 
> > exactly.
> >
> > However, when I use half as an intermediate format with the cineon 
> > linearized between 0->1 (keeping super blacks and super whites), it 
> > does not seem to be round-tripping. It's close, and not noticable 
> > visually, but Shake's Common node is showing tons of "noise".
> >
> > Is this expected?
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel