Re: [Openexr-devel] Re: Openexr-devel Digest, Vol 18, Issue 6

[Kevin Wheatley]

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.

> 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.
> 
> This would change the common black and white points to .19 (a code value
> of 95) and 1.37 (a code value of 685).

the values suggested were based on a set of well supported, and
reasonably well understood equations, that we thought would be
acceptable and understandable by most. Also they were referenced to
the printing density space which is  conventionally 0-1023, if you
want to make them floats, then they should be 683/1023 or 0.66959922
(ish :-), i.e. normalised in my book, that way Cineon/Shake/Nuke users
get what they expect, based upon a principal of least surprise.

Kevin

-- 
| Kevin Wheatley                   | These are the opinions of |
| Senior Do-er of Technical Things | nobody and are not shared |
| Cinesite (Europe) Ltd            | by my employers           |