Hi Jep,
Yes, you're correct. Both these problems stem from the same issue - Bug
50345 - Nuke - OCIO env var being saved into script. Were, as you say, the
OCIOConfigPath knob is out of date. Until this is fixed you should be able
to work around it by triggering a refresh of the OCIO config, which will
reset the OCIOConfigPath knob to the correct value. This can be done with
the following bit of python..
root = nuke.Root()
config = root['customOCIOConfigPath'].value()
root['customOCIOConfigPath'].setValue("blah")
root['customOCIOConfigPath'].setValue(config)
Sorry for the inconvenience but hope that helps!
Babak
On 25 July 2015 at 23:25, Jep Hill <jep...@gmail.com> wrote:
> Hi guys,
>
> I searched for this and didn’t see anything on it so apologies if this has
> already been covered.
>
> I’m seeing 2 issues:
>
> 1. All OCIO nodes aren’t sourcing the same OCIO config — some nodes are
> correctly using the config set by the $OCIO environment variable but some
> are using the config saved to Nuke 9’s OCIOConfigPath knob (incorrect),
> which appears to be a problem if you update your $OCIO environment variable
> at any point after initially saving the nuke script.
>
> 2. Either the OCIOConfigPath knob is broken, or it’s purpose is suspect.
>
> When first seeing Nuke 9’s OCIOConfigPath knob attached to the root node,
> I thought it was probably meant to serve as a record of the resolved OCIO
> config path used in that nuke session — which is a great idea.
> Unfortunately, I’m seeing that the OCIOConfigPath knob does not update
> accordingly and actually interferes with Nuke’s ability to source the
> proper OCIO config with some nodes.
>
> e.g.: if you change your OCIO environment variable and open an existing
> Nuke 9 script from a new shell, it appears that the OCIOColorspace node
> ignores the OCIO config defined by the current $OCIO environment variable
> in favor of the config previously hardcoded to the
> nuke.Root()['OCIOConfigPath'].value() that was encoded at it’s INITIAL
> SAVE. You’ll also notice the OCIO Viewer LUTs *do* reflect the current
> $OCIO environment variable and they *do* use the proper config.
>
> This also means when you start a fresh new script and then save it for the
> first time, Nuke encodes the current resolved OCIO environment variable
> value to the OCIOConfigPath knob, never to be changed. This knob appears to
> ignore any subsequent updates to the OCIO environment variable path in
> favor of the value it encoded at first save. This seems like it must be a
> bug?
>
> Since the OCIOConfigPath is a READ ONLY knob, as far as I know, Nuke will
> not allow me to change it via Python. The only workaround I’ve found with
> existing scripts to ensure all of Nuke’s OCIO nodes use the current $OCIO
> config thus far is to open the .nk file in a text editor and remove the
> line "OCIOConfigPath /path/to/my/initial_config.ocio”.
>
> I need to make certain that all of Nuke is using the *SAME* and current
> OCIO config at all times. How do I do this without munging the .nk file?
>
> Hopefully it’s something obvious that I’m missing.
>
> Thanks!
> Jep
>
>
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
