[Openexr-devel] RE: proposed standard for .exr linear float file exchange/filmout

[Haarm-Pieter Duiker]

Hello,

It's great to see that this issue is being addressed. It would be useful to 
have a standard.

I'd like to propose adding a new parameter. At ESC, we've come up with an 
additional modification to the Kodak Cineon equations that is easy to integrate 
and provide direct benefit. We've added a parameter that specifies the target 
linear value for the white point, of pdxWhiteReference in this context. The 
standard equation has an implicit value of 1 for this parameter, we've found 
that it is useful to be able to set the parameter to values other than 1.

I would propose a new parameter to be called pdxWhiteReferenceLinear and have 
default values of {1, 1, 1}.

The modified equations would be :

        Log to Lin
        ==========

        blackLin = pow( 10, (pdxBlackPoint-pdxWhiteReference) * 
                        pdxDensityPerCodeValue/pdxNegativeGamma );
        whiteLin = 1;

        xLin = pow( 10, (xLog - pdxWhiteReference) * 
                        pdxDensityPerCodeValue/pdxNegativeGamma );

        if ( pdxBlackPoint != 0.0 )
        {
                xLin = (xLin - blackLin)/(whiteLin - blackLin);
        }
        xLin *= pdxWhiteReferenceLinear;

        Lin to Log
        ==========

        xLin /= pdxWhiteReferenceLinear;

        if ( pdxBlackPoint != 0.0 )
        {
                xLin = xLin*(whiteLin - blackLin) + blackLin;
        }
        xLog = log10( xLin ) pdxNegativeGamma/pdxDensityPerCodeValue + 
pdxWhiteReference;
        
The default values for the new parameter maintain the same behavior as the 
Cineon standard. The black point computation changes a bit. The assumption of a 
white point mapping to 1 had to be removed from equation listed in your 
posting. The results though, as before, match the Cineon standard when using 
the default values.

The new parameter was added after much experimenting with and use of system 
that solves for the nGamma values of a given film stock. It turns out that, 
given a fixed log white point and a fixed mapping of that log value to a linear 
value of 1, changing the nGamma values ends up changing exposure as well as 
contrast. Using a pdxWhiteReference value of (444, 444, 444), and a 
pdxWhiteReferenceLinear value of (0.18, 0.18, 0.18), we've been able to 
effectively factor out the exposure changing aspect of varying the nGamma. The 
parameter is in some ways a natural addition. We saw that the implied linear 
mapping was troublesome. Aside from that, the equations maintained full 
compatibility with the Cineon standard.

Hope this doesn't seem like too outlandish a suggestion, especially from a 
newcomer to the list.

Regards,
Haarm-Pieter Duiker
ESC Entertainment
Research and Development
address@hidden 510 749 7343
        





> -------- Original Message --------
> Subject:      [Openexr-devel] exchanging exr's
> Date:         Wed, 09 Jun 2004 10:33:03 +0100
> From:         Ken McGaugh <address@hidden>
> To:   address@hidden
> 
> 
> 
> Hello all,
> 
> We have recently shifted most of our pipeline (both 3D and 
> 2D) to OpenEXR
> format, and we will soon be sending exr's to Cinesite UK for filmout.
> Keven Wheatly from Cinesite and I have worked out a spec for 
> exchanging
> these exr's, but we hope this can become a standard.  Below is the the
> proposed spec, and we would appreciate comments and suggestions.
> 
> 
> Thanks.
> --Ken
> 
> ---------------
> 
> 
> We propose methology for the interchange of OpenEXR images between
> Visual Effects and film scanning/recording facilities.  Currently
> most facilities transfer images as either cineon or dpx files, with
> the pixel values representing print density.  So we propose several
> new standard header attributes which will describe the transform
> between the linear values in the exr image and a film print density.
> We prefix all the attributes with "pdx", which stands for 
> Print Density
> Xform.
> 
> All the attributes are of type V3fAttribute and are listed below
> with the default values to be assumed if the attribute is not
> present in the file.
> 
>     pdxBlackPoint            = {0, 0, 0}
>     pdxWhiteReference        = {685, 685, 685}
>     pdxNegativeGamma         = {0.6, 0.6, 0.6}
>     pdxDensityPerCodeValue   = {0.002, 0.002, 0.002}
> 
> Together these attributes define 3 1-dimensional transforms, one
> for each color channel.  To do the math for one color channel, we
> need to define some values:
> 
>     xLin = linear pixel value (ie. from exr)
>     xLog = log pixel value (ie. print density)
> 
> We also need to precompute what the pdxBlackPoint value would
> be after converted into linear:
> 
>     blackLin = pow( 10, (pdxBlackPoint-pdxWhiteReference) *
>         pdxDensityPerCodeValue/pdxNegativeGamma )
> 
> Then the math to convert per-channel pixel values would look like:
> 
>     Log to Lin
>     ==========
> 
>     xLin = pow( 10, (xLog - pdxWhiteReference) *
>         pdxDensityPerCodeValue/pdxNegativeGamma );
>     if ( pdxBlackPoint != 0.0 )
>     {
>         xLin = 1 - (1 - xLin)/(1 - blackLin)
>     }
> 
>     Lin to Log
>     ==========
> 
>     if ( pdxBlackPoint != 0.0 )
>     {
>         xLin = blackLin + (1 - blackLin)*xLin
>     }
>     xLog = pdxWhiteReference + log10( xLin )*siftGamma/siftStep
> 
> The above math is very similar to that described by the Kodak
> technical documentation.  The only difference is that we treat
> a pdxBlackPoint of 0 to be a special case where the linear black point
> remapping is omitted.
> 
> Additionally, if either of the matrix attributes
> 
>     pdxLinMatrix
>     pdxLogMatrix
> 
> are found, the pixel's color is to be transformed by them.  
> The pdxLinMatrix
> should transform the linear pixel color before being converted to log.
> The pdxLogMatrix should transform the log pixel color after 
> being converted.
> If converting from log to lin, the inverses of these matrices 
> should be used.
> If a matrix is 4x4 instead of 3x3, treat the color as a 
> 4-tuple with the
> last component equal to one.
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> 
>