Re: [Openexr-devel] exchanging exr's

[Drew Hess]

Hi all,

Thanks to Ken for pushing the topic of interchange.  At ILM, we've been
talking about this internally and will have an "official" response soon.  
Just wanted to let people know that we're not ignoring this proposal....


-dwh-


On Wed, 9 Jun 2004, Ken McGaugh wrote:

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