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.

 
It might have to wait a few weeks, I'm in Hong Kong right now and I'm going to be MIA in asia for a bit.

But yes a chat would be good when we are both free.

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.

 
They are a common mechanism for setting up initial state for a lot of apps. This being similar is a nice entry point for integration with existing systems.

But I agree the env vars should only be used to setup the initial state.

Even if it is possible to change this state with setenv()'s I would discourage this use with a better interface for changing state during execution, similar to what you have suggested.

Most places have some form of setshot system which bootstraps the env for a shot, not just for color but things like the required toolchain for that artist session doing task A (I'm guessing you have something similar at SPI).

I can guarantee that I would need to write something that grabbed env's and setup an initial state through which ever interface we settle on. I would prefer that this ocio env wrapper type code was internal rather than each shop doing it slightly differently.

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.

 
+1

Being able to setup/enfoce the initial state like this is important for multiple dept / group workflows. Who are most likely using diffrent toolchains but require to start with the same consistent viewing env between them.

In this style of setup each person gets pushed the currently approved viewing env for that session and are not concerned with modification of it.

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.

Neither do I, that would be a bit clumsy for that specific problem.

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 think a mixture of the two ideas could work well (see below).

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!

 
I was thinking the same kind of thing, but with the possibility of these grabbing their initial value from the env (if it exists).

I'm also thinking it might be better to be explicit with globals eg. config->addglobal(name) these would end up as a list in the yaml profile. Only the $globals in this list would be expanded and also the only ones initialized from the env. (This does resolve my niggles with the current expand code which has the potential to be a bit slow, if used in many)

These globals could be set/get dynamically at run-time ie config->getglobal(), config->setglobal(). I would prefer to call these globals over variables as it suggests their scope.

Right now I only see a direct use for globals with string parameters and would only want to add support for other types if we had a strong need for them.

As an example this would be nearly a complete list of globals I could see a use for ($JOB, $SCENE, $SEQ, $SHOT, $TASK, $USERGROUP, $BALLANCE_GRADE, $CREATIVE_GRADE, $EDIT_GRADE). I'm sure these have slightly different names per shop but represent the same concepts.

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

 
I definitely would like some form of dynamic parameters/variables, but these should be something different to globals.

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

 
With the prospect of multiple image sequences / clips with transforms, configs and or grades. For these case are you proposing that we setup a single config and then store some kind of ocio processor relationship per clip?

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

 
It would be great to flesh this out as it would be good for client apps not to need to manage the details of this per clip state storage if this is the way we are thinking of going.

.malcolm