Problem summary
When writing an Uncompressed 10-bit mov from Nuke using the 'Uncompressed 10bit 422' codec, when this mov is brought back into Nuke this will show up as an 8-bit file in the metadata.
Note: In Nuke 10.5v6, 10.5v7 and the Nuke 11 releases 11.0v1, 11.0v2 and 11.0v3 the image will be brought in at 8-bit and there will be image degradation. In prior releases to Nuke 10.5v6, the image was not altered, just the metadata values.
Customer reported version
nuke.10.0v4
Customer reported platform
centos7
Steps to reproduce
1. Open Nuke
2. Create a 'Colorwheel' node
3. Write out Colorwheel as 'cw.exr' (confirming it is 16bit)
4. Read in 'cw.exr'
3. Create a ViewMetaData node and look at the 'input/bitsperchannel attribute' and confirm it is '16-bit half float'
4. Create a Write node
4. In the file path provide a directory location and filename eg. yourcomputer/desktop/10bit.mov
5. Entering .mov in the file type should default to mov, if not set to mov.
6. Set codec to 'Uncompressed 10-bit 4:2:2'
7. Render a frame.
8. Read in '10bit.mov via a Read node
9. Add a viewMetaData node
Result: The 'input/bitsperchannel' will have a value of '8-bit fixed' instead of '10-bit fixed'
Workaround
Avoid using 'Uncompressed 10-bit' codec and use one of the other codecs as an alternative for quicktimes:
Earliest version tested
Nuke 9.0v1
- Uncompressed 10-bit codec export option did not exist before this version
Expected behaviour
The uncompressed 10bit mov file should be seen as a 10bit file in the metadata properties as well as not causing image degradation in versions including Nuke 10.5v6 and after.
Actual behaviour
The uncompressed 10bit mov file is seen as an 8bit file in the metadata properties as well as causing image degradation in versions including Nuke 10.5v6 and after.