Re: [Openexr-user] CTL questions

[Florian Kainz]

The displayWhiteLuminance and displaySurroundLuminance parameters
themselves are implemented in the sense that their values can be
accessed by CTL transforms.

What isn't implemented is the parameters' effect on the displayed image.
The parameters are intended to help model "color appearance."  An image
looks different on, for example, a screen in a dark theater and on a
computer monitor in an office with ambient light, even if the pixels have
exactly the same CIE XYZ values.  Color appearance modeling attempts to
predict the differences and to compensate for them.  To find out more
about this topic you may want to take a look at this book:

    http://www.cis.rit.edu/fairchild/CAM.html

Given that this is an open-source project, I hope someone will implement
a good color appearance model in CTL and make it available to everyone...

Regarding the "upcoming spec from AMPAS":  A while ago the Academy of
Motion Picture Arts and Sciences formed an Image Interchange Framework
committee to decide on recommendations for digital mastering of motion
pictures, including file formats, color management and overall work flow.
The committee's work is not yet finished, and so far no detailed documents
have been published.  The committee will hold a Birds of a Feather meeting
at Siggraph 2007.  I intend to present preliminary results regarding how
CTL and OpenEXR might be used in the context of the recommended work flow.
I'll send out another mail as soon as I know the time and location of the
BoF meeting.

The transform_RRT.ctl program is only a placeholder.  It tries to change
your image noticeably, but without destroying it.  In a real production
work flow, the rendering transform, or RT, will contain your "film look".
The Academy's Image Interchange Committee intends to supply a recommended
Reference Rendering Transform, or RRT.

Gonzalo, as you mentioned, you can convert the placeholder RRT into a pass-
through by removing the lookup tables.  You don't want to remove the RGB
coordinate transforms in transform_RRT.ctl and transform_display_video.ctl;
those are needed to convert the image from the RGB primary set in the image
file to the primaries of your monitor.  Without the coordinate transforms,
XYZ images or images with RIMM or Adobe RGB primaries will not be displayed
correctly.

About the CTL license - I cannot speak for the Academy, but the way I read
it this is the BSD license, but with two rather inconsequential additions:
You are allowed to use CTL, but that doesn't give you the right to use any
of the Academy's patents or trademarks (e.g. "Oscar").  And if you decide
to sue the Academy, you'll have to do it in California.  The license
shouldn't prevent you from using CTL in production software.  Again, this
is my interpretation, not necessarily the Academy's.  For official answers
to licensing questions, please contact the Academy.


gga wrote:
> Florian Kainz wrote:
> > Hi Gonzalo,
> >
> > The CTL examples that come with playexr and exrdisplay do not make
> > use of displayWhiteLuminance and displaySurroundLuminance. (I am not
> > enough of an expert to properly model color appearance.)
>
> Okay.  That explains that: not implemented.  So the next question is, is
> there any documentation on how those parameters need to be implemented
> in a ctl transform?  One of the .ctl 'shaders' mentions an upcoming spec
> from AMPAS, but makes no reference to any document.
> I imagine displayWhiteLuminance should modify the image's gain somehow,
> while displaySurroundLuminance should modify the image's gain/contrast
> somehow.  Being that they are measured in candelas per square meter
> (nits) I imagine this requires obtaining the proper information from the
> monitor's EDID and/or a good calibration device that takes the
> environment into account.  I'm still curious how the change in
> gain/contrast is to be applied, thou.
>
> > The EXR_DISPLAY_VIDEO_GAMMA environment variable tells playexr and
> > exrdisplay the native gamma for your monitor.  
>
> Thanks, Florian.  I'm aware of gamma.  I'm already setting gamma
> automatically from the monitor's EDID information if present.
>
> No, basically the issue is due to how transform_RRT.ctl is implemented.
>  There's a weird 1D lookup in there that, supposedly, changes contrast
> but in my tests really seems to just darken any non HDR image.  Removing
> that makes a pass-thru possible.
>
> A final question: what's the status of the licensing (and, more
> importantly, the I.P./patent status) of CTL?  The current licensing
> reads like a BSD license with a loophole allowing AMPAS to sue anyone
> due to patent infringements in California.