On Thu, Aug 2, 2012 at 1:11 AM, Nhat Phong Tran
<nhatpho...@...> wrote:

Hi! I think I got most part of OCIO configs now. The only few
questions that I have left are

- COLORSPACE_DIR_TO_REFERENCE, what is that exactly supposed to mean?
Practically it seemed like one was just the inverse of the same
transformation. Should I be aware of anything that could be breaking
in the future if I have swapped TO and FROM but with the inverted
transform on one of the settings (thus getting the same result w/ both
TO and FROM).

You can specify the set of transforms (luts, matricies, etc) either
"to reference", "from reference", or both. Most of the time, it's
only required to specify the transform in one of the directions, and
users are free to do which ever is most convenient. There is
absolutely no difference in the result for tranform chains which are
"trivially invertible" (matricies, 1dluts, gamma, etc). however, if
user utilize 3d luts OCIO will not make any attempt to automatically
provide the inverse transform. In these cases a user who wanted to
specify both the inverse and reverse transform, referencing separate
files, is free to do so.

- allocation vars is that something that only affects viewing the
images or also the transformation from one colorspace to another?

This used to be called GPUAllocationVars, and perhaps we should have
left it with that name. This only affects image display on
applications which utilize the GPU pathway (including Katana, Mari,
etc). This does not impact the CPU processing. Setting up the
allocation vars is currently a subtle operation, which requires a bit
too much special knowledge. I've put together this web page,
http://opencolorio.org/configurations/allocation_vars.html, but it
definitely needs a bit more details.

We have some code improvement ideas related to AllocationVars which
will hopefully make it less magical to write configs (and easier to
test!) and hope to have time to implement these post siggraph.

- what is that setIsData() for? Isn't this just like raw if true and done?

data spaces are intended to denote spaces used for 'data' (normals,
depth, etc.) They are handled specially inside OCIO, in that all
colorspace transforms to or from a 'data' space is ALWAYS a no-op.
This is particularly important inside the DisplayTransform (used
inside the viewer), because it means that even if an app asks for a
'scene-linear' exposure change, or a 'color timing cc', they can be
assured that on data image no accidental color-specific conversions
will be applied.

- how's the RRT in the ACES config specified? To me it should start
with a scene-linear to inverted adx10 conversion, but what comes next?
I've not managed to reproduce the ACES RRT in the config.

https://github.com/imageworks/OpenColorIO-Configs/blob/master/aces/README

ociolutimage is used to make an exr, representing a 3d lattice, with
an analytical log encoding:

ociolutimage --generate --colorconvert log aces --output log_aces.exr

ctlrender then applies both the rrt and ODT

ctlrender -ctl rrt/rrt.ctl -ctl odt/p3d60/odt_p3d60.ctl log_aces.exr rrt_ut33_p3d60.exr

ociolutimage then converts the exr lattice to a 3dlut:

ociolutimage --extract --input rrt_ut33_p3d60.exr --output rrt_ut33_p3d60.spi3d

(cc'ing ocio-dev)

-- Jeremy