Problem summary
When a
Write node is rendering, any metadata values created by that
Write node should overwrite any existing metadata values of the same name in the stream.
It has recently been discovered that if the
exr/compressionName metadata is modified (either by an input Read node or in the stream), that when rendering this custom metadata value is retained and not overwritten by the Write node.
Customer reported version
Nuke 12.2v3
Customer reported platform
CentOS 7
Steps to reproduce
1) Within a new Nuke session, create a
Checkerboard node
2) Under the
Checkerboard node, add in a
ModifyMetaData node.
3) Within the
ModifyMetaData node
a) create a new action (+) using the default set attribute
b) set the key value to exr/compressionName
c) set the value to test
4) Create a
Write node, then
a) set the file to export to a location as an exr file with the file path (filename.####.exr)
b) alter the metadata field to all metadata
c) alter the compression field to none
c) Render the exr file
5)
Read back in this rendered
exr file, and view the metadata tab in the
Read nodes properties bin
Result: The metadata will show a value of
test and not the expected
none compression type
Expected behavior
The written exr file should have set the
compressionName metadata to that of the
Write node when rendering.
Actual behavior
The
Write node has not overwritten the
compressionName metadata when rendering
Workaround
It is possible to add in a manual
ModifyMetaData node, and set this to the correct
compressionName metadata value that the Write node is using, before the Write node renders.
Using setting the
metadata knob in the Write node to
default metadata seems to override this correctly.
Reproduced by Support in:
Nuke 13.0v1 - Windows 10 - MacOS 10.15.6 - CentOS 7
Nuke 12.2v1 - Windows 10
Nuke 12.1v1 - Windows 10
Nuke 12.0v1 - Windows 10
Nuke 11.3v1 - Windows 10
Nuke 11.2v1 - Windows 10
Nuke 11.1v1 - Windows 10
Nuke 11.0v1 - Windows 10
Nuke 10.5v1 - Windows 10
Nuke 10.0v1 - Windows 10
Nuke 9.0v1 - Windows 10 - MacOS - CentOS 7
Earliest version tested
Nuke 9.0v1 - This issue appears to be in all versions of the product