Alan,

OCIO is being a bit clever under the hood, though in my opinion not in
a dangerous way.

OCIO's currently approach is that to make colorspace definitions
"convenient", we assumes inverse color transforms are allowed when the
round-trip can automatically be made 100% accurately. I.e, if your
colorspace definition is only built from cleanly invertible ops
(simple cc math, matrix ops, log, 1D lookup tables), and is round-trip
safe, the inverse transform is allowed. If your colorspace definition
relies on 3D LUTs, any attempt to run the inverse transform will fail
during the getProcessor call. (If you try to add a 3d lut to nuke and
try to perform the inverse you'll see this). I'd love to figure out
a way to make this more explicit in the API. Suggestions?

The reason we defer the inverse 3d lut check to this late part in the
API is to allow for the following interesting possibility.

Say you have 2 display emulation colorspaces defined as follows.

srgb: (A normal filmlook)
lin_to_log.lut1d
log_to_srgb.lut3d

srgb_warm: (A warmer filmlook varient).
lin_to_log.lut1d
log_to_srgb.lut3d
warm.mtx


Say you have pixels in a baked srgb representation, and you wanted to
view them with the warm look. Internally, our processing chain would
look like:
INPUT -> inverse log_to_srgb.lut3d -> inverse lin_to_log.lut1d ->
lin_to_log.lut1d -> log_to_srgb.lut3d -> warm.mtx -> OUTPUT

But, OCIO ( will soon) optimize this to a simplified conversion:
INPUT -> warm.mtx -> OUTPUT

This particular color space transformation, although conceptually
requiring an inverse 3d lut, doesnt actually end up using it!
Which is pretty cool, and really convenient in practice.

This is why in Nuke we just blindly added all color spaces to both the
input and output side, to allow for these circumstances. I can see
this is subtle though, and potentially misleading from a new user
perspective.

Thoughts?

-- Jeremy