Problem summary
When loading a Nuke session, all OCIO LUTs within the custom config.ocio folder are loaded.
If OCIO is set to load as default, instead of the Nuke-default LUTs, when a session is started the size of the custom OCIO LUTs can cause Nuke to take a significant amount more time to load.
This has been seen to mainly occur with larger LUTs such as 3D LUTs that contain vast amounts of color data.
Customer reported version
nuke.11.3v4
Customer reported platform
n_a_linux
Steps to reproduce
1) Unzip the attached file. (custom_luts.zip) to your Desktop
2) Set the OCIO environment variable to the config.ocio file within the 'custom_luts' folder location.
eg. OCIO = /path/to/custom_luts/ocio/config.ocio
3) Within a Text Editor, amend the following snippet into your .init.py file. (to set up OCIO as the default colorspace option)
nuke.knobDefault('Root.colorManagement', 'OCIO')
4) Open a new session of Nuke and note the length of time it takes Nuke to load.
Result: Load times will be much longer than normal
5) To confirm this is caused by the larger OCIO LUTs
a) Remove the five added colorspaces (biglut)'s at the end of the ocio.config file, save and close
b) Run a new session of Nuke.
Result: Load times will be back to normal
Note: When finished, be sure to remove the environment variable and delete the init.py addition.
Expected behaviour
Nuke should not take a significant longer time to load at startup if larger OCIO LUTs are being called
Actual behaviour
Nuke takes a significant amount more time to load when larger OCIO LUTs are being called.
Workaround
Unknown.
Reproduced by support
This bug has been reproduced in:
Nuke 11.3v5 - Windows 7 - CentOS 7 - MacOS 10.14.5
Nuke 11.3v1 - Windows 7
Nuke 11.2v1 - Windows 7
Nuke 11.1v1 - Windows 7
Nuke 11.0v1 - Windows 7
Nuke 10.5v1 - Windows 7
Nuke 10.0v1 - Windows 7
Nuke 9.0v1 - Windows 7
Nuke 8.0v1 - Windows 7 - CentOS 7 - MacOS 10.14.5
Earliest version tested
Nuke 8.0v1
- This issue appears to be in all versions of the product