There's a lot of good ideas here, it's taken me a bit of time to think
through the implications.

I'm going to be out of town for the remainder of the week, perhaps we
could try an internet call early next week to discuss these specifics
further? (Skype, iChat, etc). Many of these points can probably be
hashed out easier live, and then we can summarize our thoughts back to
the list.

What about per shot balance grades and look / creative grades, I would cry if I needed to create a zip ocio profile per shot to do this. > Then re-syncing these profiles would be a nightmare.

Agreed. Under no circumstances are we going to make per-shot looks
complicated to use. We're in the same boat here.

JS: I think it will be preferable when possible to minimize the use of envvars.

MH: Can you elaborate on this?

Your approach to implementing per-shot looks - using environment
variables within search paths - is clever. However, I'm not sold.
The portion I'm concerned about is the use of environment variables as
a communications mechanism.

For an application (such as a compositor) where you're not changing
show / shot / sequence at runtime the use of envvars is no big deal.
For example, say you have a per-shot display lut
(/job/$SHOT/.../shotgrade.3dl). You could run a script which sets up
the shot environment, launch the APP, and everything just works.

However, consider an image-viewing tool which needs to flipbook
multiple shots (or whole sequences) back to back. I.e., the display
transform, as queried from OCIO, would be different based on the shot
name. Would this approach be possible using an envvar mechanism? I
dont believe so. Envvars are commonly locked down at launch time.
And, even if you could modify it at runtime as playback was in
progress, would you want to? How would you notifiy OCIO that it had
changed? This seems like a tricky implementation, and strikes me as
going down the path of evil.

I would prefer to promote this concept of 'variables' to be an
explicit communications mechanism, rather then using envvars as a
back-door. Alternate implementation options include:

* a config->setVariable option, where variables were available for
use in color transforms. (They could even retain the $SHOW $SHOT
syntax). This way the OCIO plugin could set it as needed, and with
the python API exposed in client apps the list of variables could even
be amended with facility code, as needed at runtime!

* Alternatively, with a less stateful implementation the variables /
arguments could be passed along in the config->getProcessor call. This
may be preferable to those computer scientists among us.

Either way, this passing of variables as arguments to a transforms is
half of the work towards allowing fully dynamic colorspaces. (The
other 1/2 being the plugin API to define the lists of transforms at
runtime).

Perhaps this is good reason to move forward on both ASAP?

-- Jeremy