ID 303479 - 8-bit image sequences have a slight colour difference when compared between rendered frames

Problem summary

It has been discovered that when rendering a sequence of images as 8-bit eg. (8-bit jpeg, png, tiff, dpx) when comparing consecutively rendered frames against each other there is a slight (0.001-0.003) difference in colour in the renders.

This has been seen to occur with images that are generated by Nuke at 32-bit (e.g. ColorWheel, Constant), or 32-bit/16-bit source files that have been Read in.

Customer reported version
nuke.n/a

Customer reported platform

Steps to reproduce

1) Within a new Nuke session, create a ColorWheel node

2) Under the ColorWheel node, create a Write node, setting it as a jpeg file, and render frames 1-2.

3) Read in both renders into separate Read nodes and compare using a Merge set to 'Difference'

Result: There will be a slight difference between the two consecutively rendered jpeg images (see below)

Expected behaviour
There should not be a difference between the two consecutively rendered jpeg files

Actual behaviour
There is a difference between the two consecutively rendered jpeg files

Workaround
If colour retention at this minor level is important, we would suggest using 16bit/32 bit compression to retain the colour values.

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 

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 - CentOS 7 - MacOS

Earliest version tested
Nuke 9.0v1 
- This issue appears to be in all versions of the product