Problem summary When exporting an Apple ProRes QuickTime file, the file itself will contain nclc data. This data contains the color parameters (primaries, transfer and matrixes) for the exported QuickTime. https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-142486
It has been discovered that if the original ProRes QuickTime file is reformatted and exported at less than 2/3rds of the original resolution height, the nclc data will unexpected be changed from 1:1:1 to 6:1:6.
As per the link above, this change from 1:1:1 to 6:1:6 gives the written file the wrong primary and matrix information in the metadata.
Note: This issue only occurs in Nuke 12.0v1 releases and later.
Customer reported version
Customer reported platform 11_big_sur
Steps to reproduce
1) Open a new Nuke session, setting it at 1920x1080 resolution
2) Create a Checkerboard node
2) Create a Write node under the Checkerboard node.
3) Within the Write node, set the file to write out a ProRes 422 QuickTime file called 'render_FR.mov'
4) Create a Reformat node branching off the Checkerboard node, and create a new resolution at 1920x719
5) Duplicate the Write node and place it under the Reformat node, renaming the exported file to 'render_HR.mov'
6) Render out 10 frames for both Write nodes
7) Open both files and compare results in a metadata/EXIF viewing application (such as ExifTool) Results:
render_HR (1920x719)
render_FR (1920x1080)
8) To confirm this only occurs below 2/3rds height ratio, re-render at 1920x720 resolution Result: nclc 1:1:1
Expected behaviour The nclc color atoms should not change based on reducing the height of the source resolution
Actual behaviour The nclc color atoms change from 1:1:1 to 6:1:6 when the height goes below 2/3rds of the original resolution
Workaround Unknown.
Reproduced by support This bug has been reproduced in: Nuke 13.0v1 - Windows 10 - CentOS 7 - MacOS 10.15.6 Nuke 12.2v1 - Windows 10 Nuke 12.1v1 - Windows 10 Nuke 12.0v1 - Windows 10 - CentOS 7 - MacOS 10.15.6
Unable to reproduce bug in: Nuke 11.3v6 - Windows 10 - CentOS 7 - MacOS 10.15.6
Earliest version tested Nuke 11.3v6 - Color representation did not exist in the metadata till Nuke 12.0v1
