[Openexr-user] CTL questions

[gga]

Hi, Florian.

I'm integrating CTL into my applications and I have some questions
regarding the demo programs and its OpenEXR interaction.

Currently, the demo programs define CTL_DISPLAY_WHITE_LUMINANCE and
CTL_DISPLAY_SURROUND_LUMINANCE, which are then shuffled into the Open=
EXR
environment header as the attributes "displayWhiteLuminance" and
"displaySurroundLuminance".
Now, as far as I can tell, these two attributes are currently a NO-OP=
in
any of the demo programs and the CTL library. Is this on purpose?

The chromaticities attribute, on the other hand, works properly.
However, with the demo programs, I am unable to understand what setti=
ngs
would produce a simple pass-thru (ie. no color transform just as, say=
,
the old exrdisplay would do with gamma and gain at 1.0 and no
defogging). I expected that setting a gamma of 1.0, Rec
709.chromacities and using the default .ctl programs would achieve th=
is,
but what I obtain is an image that is almost a 0.5 stop darker. I
expect this is some user error on my side, but I'm not sure what it i=
s
exactly.

The demo programs seem to construct a 3d Lut of 64x64x64 half values.
Is there any particular advantage to using a half 3d texture in this
case (as opposed to a full float texture)?



--=20
Gonzalo Garramu=F1o
***@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

[Florian Kainz]

Hi Gonzalo,

the displayWhiteLuminance and displaySurroundLuminance are made
available to the CTL transforms. The idea is that the brightness
of the display and the environment that surrounds the display have
an effect on how the colors on the screen are perceived by a human
viewer. A CTL transform might want take this effect into account
and compensate for it.

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

The EXR_DISPLAY_VIDEO_GAMMA environment variable tells playexr and
exrdisplay the native gamma for your monitor. The CTL transforms
are expected to output floating-point RGB values that are proportional
to the luminance you want on the screen (twice the number means twice
the amount of light). EXR_DISPLAY_VIDEO_GAMMA is used to convert the
floating-point RGB values into appropriate 8-bit values for your
graphic cards's frame buffer.

To find the right setting for EXR_DISPLAY_VIDEO_GAMMA, get the
GammaChart.exr image from the OpenEXR sample files:


http://cvs.savannah.nongnu.org/viewvc/OpenEXR-images/TestImages/GammaChart.exr?root=openexr&view=log

Display the image using this command line:

exrdisplay -1 GammaChart.exr

If you have EXR_DISPLAY_VIDEO_GAMMA set correctly, each of the fields
with horizontal lines in it should have an average brightness equal
to the flat field immediately to its right. You may have to squint or
sit further back from your screen for this operation. If the field with
the lines is brighter or darker than than the flat field, increase or
decrease the value of EXR_DISPLAY_VIDEO_GAMMA until you get a match.
For most monitors a value of 2.2 is about right.

As far as I know it doesn't matter very much if the 3D LUT used by
playexr contains half or float values. CTL transforms aren't supposed
to know if they are working directly on your images or if they are
generating a LUT, so I made them read and write half values in both
cases.

Florian

Post by gga
Hi, Florian.
I'm integrating CTL into my applications and I have some questions
regarding the demo programs and its OpenEXR interaction.
Currently, the demo programs define CTL_DISPLAY_WHITE_LUMINANCE and
CTL_DISPLAY_SURROUND_LUMINANCE, which are then shuffled into the OpenEXR
environment header as the attributes "displayWhiteLuminance" and
"displaySurroundLuminance".
Now, as far as I can tell, these two attributes are currently a NO-OP in
any of the demo programs and the CTL library. Is this on purpose?
The chromaticities attribute, on the other hand, works properly.
However, with the demo programs, I am unable to understand what settings
would produce a simple pass-thru (ie. no color transform just as, say,
the old exrdisplay would do with gamma and gain at 1.0 and no
defogging). I expected that setting a gamma of 1.0, Rec
709.chromacities and using the default .ctl programs would achieve this,
but what I obtain is an image that is almost a 0.5 stop darker. I
expect this is some user error on my side, but I'm not sure what it is
exactly.
The demo programs seem to construct a 3d Lut of 64x64x64 half values.
Is there any particular advantage to using a half 3d texture in this
case (as opposed to a full float texture)?

[gga]

Post by Florian Kainz
Hi Gonzalo,
=20
The CTL examples that come with playexr and exrdisplay do not make
use of displayWhiteLuminance and displaySurroundLuminance. (I am no=

t

Post by Florian Kainz
enough of an expert to properly model color appearance.)
=20

Okay. That explains that: not implemented. So the next question is,=
is
there any documentation on how those parameters need to be implemente=
d
in a ctl transform? One of the .ctl 'shaders' mentions an upcoming s=
pec
=66rom AMPAS, but makes no reference to any document.
I imagine displayWhiteLuminance should modify the image's gain someho=
w,
while displaySurroundLuminance should modify the image's gain/contras=
t
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.

Post by Florian Kainz
The EXR_DISPLAY_VIDEO_GAMMA environment variable tells playexr and
exrdisplay the native gamma for your monitor. =20

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 implemente=
d.
There's a weird 1D lookup in there that, supposedly, changes contras=
t
but in my tests really seems to just darken any non HDR image. Remov=
ing
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.


--=20
Gonzalo Garramu=F1o
***@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

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

Post by Florian Kainz
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.

Post by Florian Kainz
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.