[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] does half round-trip?
From: |
Florian Kainz |
Subject: |
Re: [Openexr-devel] does half round-trip? |
Date: |
Wed, 21 Sep 2005 15:06:36 -0700 |
User-agent: |
Mozilla Thunderbird 1.0 (X11/20041207) |
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