ID 370714 - When a Nuke script has a layer named "other", any .exr files read in will have their default RGBA channels will be moved to this "other" layer

Follow

Problem summary
When a Nuke script has a layer named "other", any .exr files read in will have their default RGBA channels will be moved to this "other" layer.

This only seems to affect .exr files and the layer needs to be called specifically "other". The .exr file does not need to contain the "other" layer itself for it to be affected by this issue.

 

Customer reported version
Nuke 11.2v2

 

Customer reported platform
Windows 10

 

Steps to reproduce

 

1) Open Nuke

2) Open the script editor and run the below code:

layname = 'other'lay = nuke.Layer( layname, [ layname +'.red', layname + '.green', layname + '.blue'] )

 

3) Read in any .exr, the RGBA channels will be black, and they will be in the "other" layer instead

 

 

Alternative steps to reproduce

 

1) Open Nuke.

 

2) Create a CheckerBoard node.

 

3) Create a Write node and set its channels knob to rgba.

 

4) Write out one frame.

 

5) Read the rendered frame back into the Node Graph.

 

6) Notice that the RGBA channels are read correctly.

 

7) Create an AddChannels node downstream from the Read node.

 

8) From the channels dropdown on the AddChannels node, select new.

 

9) Create a new layer named "other" and press OK.

 

 

10) Copy and paste the previously created Read node. 

 

11) Now connect this second Read node to the Viewer and view it. Notice that the RGBA channels have now been moved to the "other" layer.

NOTE: You may need to clear your cache (Cache > Clear All) for the channels to be properly updated in the Viewer.

 

Expected behaviour
For Nuke to be able to read the RGBA channels from an .exr file.

 

Actual behaviour
It moved the RGBA channels to the "other" channel.

 

Workaround
Don't use any layers called "other", or use a Shuffle node to move the channels back to RGBA.

 

Reproduced by support
 

This bug has been reproduced in:
Nuke 11.2v4 - Windows 10 - CentOS 6.9 - MacOSX 10.13

Nuke 11.2v1 - Windows 10

Nuke 11.1v6 - Windows 10

Nuke 11.1v1 - Windows 10

Nuke 11.0v4 - Windows 10

Nuke 11.0v1 - Windows 10

Nuke 10.5v8 - Windows 10

Nuke 10.5v1 - Windows 10

Nuke 10.0v6 - Windows 10

Nuke 10.0v1 - Windows 10

Nuke 9.0v9 - Windows 10

Nuke 9.0v1 - Windows 10

Nuke 8.0v7 - Windows 10

Nuke 8.0v1 - Windows 10 - CentOS 6.9 - MacOSX 10.13 - regression

 

Unable to reproduce bug in:

Nuke 7.0v10 - Windows 10 - CentOS 6.8 - MacOSX 10.13

 

Earliest version tested
Nuke 7.0v10

- This issue no longer appears in this version and has regressed

    We're sorry to hear that

    Please tell us why