Hey Ned!
One suggestion, based on some stuff I just made for us here, is to drive
the Context inputs on the OCIO nodes with expressions. Here's one of my
expressions as it appears for the SHOT key:
[python -execlocal {import os;m = nuke.thisNode().metadata();ret =
m['ocio/shot'] if 'ocio/shot' in m.keys() else 'None' if not 'SHOT' in
os.environ.keys() else os.environ['SHOT']}]
What you'll notice is that I'm explicitly setting the value of this key to
a value pulled from metadata, or from an environment variable, with
preference for the metadata value. A nice thing about this approach is
that you can then work with multiple OCIO contexts within a single Nuke
script (which turns out to be really useful for the scripts where you're
generating all this stuff in the first place). In my case, I named my
metadata key 'ocio/shot' but it can be whatever you want. I'm using a
separate gizmo in the stream to set that value based on the
'input/filename' key and some simple parsing logic.
The other big caveat I've had with OCIO is that any changes to the config
that's loaded in Nuke can cause nodes to forget what settings they're
supposed to have. In order to guarantee a stable setup, I've created
gizmos with the colorspace options I want, and am driving the underlying
OCIO nodes via expressions.
Another warning -- looks get cached pretty agressively, and the only node
with an explicit reload button is OCIOLookTransform. Even unloading and
reloading the OCIO config doesn't seem to clear the cached looks. It may
be worth looking for a python binding to trigger OCIO to empty its cache
(or maybe putting in a ticket to request one if it doesn't exist). It's
possible that the behavior you're seeing is just due to OCIO's caching
behaviors, but I'm not entirely sure.
Those are my little OCIO tips after having just spent a week working on
improving our setup here. Hopefully it helps!
On Fri, Aug 15, 2014 at 3:53 PM, Ned Wilson <nedwil...@gmail.com> wrote:
> Hello all,
>
> Like many of you, I am working inside a pipeline where the client provides
> a separate CDL file for each shot. In order to view these properly, the
> files must be first in Alexa Log colorspace, and then a CDL is applied,
> followed by a 3D LUT file.
>
> One of the things that OCIO seems to mention frequently in the
> documentation is its ability to recognize context/environment variables.
> So, you can look for ${SEQ}/${SHOT}/grade/${SHOT}.cdl and apply it, in
> theory, as part of an OCIO config.
>
> The only problem is, it would appear that OCIO only calculates these
> variables ONCE at application startup? I have scripts that run when the
> onScriptLoad event handler is triggered that alter these environment
> variables based on the script that is opened. However, it would appear that
> OCIO is not listening for any changes to the environment variables while
> Nuke is running?
>
> Do I have this right? If not, what am I doing wrong?
>
> -n
>
> _______________________________________________
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
