Allow config's context to be replaced?

Nathan Rusch <natha...@...>

Hey all,

I'm wondering if there has been any thought or discussion internally about allowing a config's Context to be replaced in place. I've been looking at ways to change the context variables of the active config on the fly using the Python bindings, and actually having them affect the existing processing environment, but after perusing the library and binding sources, it seems there isn't any way to do this currently.

Some of the machinery is already there: You can get an editable copy of the active config's current context and modify its context variables to your heart's content. However, at that point, there isn't really anything useful you can do with that object unless you're actually doing color processing yourself. I was hoping to find a way to inject the updated context back into the currently active config via Python, to affect all future processor lookups within Nuke, but there's a distinct lack of symmetry to the interface in that regard.

What I'm hoping for:

config = ocio.GetCurrentConfig()
ctx = config.getCurrentContext().createEditableCopy()
ctx.setStringVar('FOO', 'BAR')
config.setCurrentContext(ctx)  # <-- The missing link

Unless I'm mistaken, the only way to do something like this right now (at either the C++ or Python level) would be to modify the process environment (not ideal), and then call ocio.SetCurrentConfig(ocio.Config.CreateFromEnv()), which feels... dirty.

Now, I'm guessing this isn't the first time you've crossed paths with an idea like this, so I feel like it's worth asking: Am I overlooking something blatantly obvious here? I've done my best to sniff out any existing functionality like this, but haven't found anything. However, if this is in fact a nonexistent feature, I'm wondering if there is a specific reason for excluding it, and if you would be willing to consider adding it in the future.

Thanks for any information,


P.S. In the case of Nuke, I know it's possible to work around this using node-level context overrides and making Nuke do the environment lookups for you using TCL, but that's far from an ideal solution when a simple context replacement would let me do the same thing much more cleanly (and doesn't address other applications).

Join { to automatically receive all group messages.