ID 388212 - Projecting an image using Projectors is resulting in clamped colour range of the original image

​​​​Problem summary
Projecting an image in Mari using the Projectors is resulting in clamped colour values of the image if the colorspace is different than nuke-default.

Original image on the left and image exported from Mari on the right: 

Customer reported version

4.5v1

Customer reported platform
centos7

Steps to reproduce

1) Create a color wheel 16 bit exr image in Nuke using ACES colorspace (or use the one attached)

2) Open Mari and create a new project using the attached geometry, ACES colorspace and one 16 bit Base Color channel

3) Go to Projectors Palette and make sure that under the projector's properties the Color Depth is 16 bit and Clamped is unticked 

4) Right click on the projector>Project and choose the image created in step 1 (or use the one attached)

5) Export the Base Color channel using the Channels palette, right click on the channel>Export Flattened>Export Current Channel Flattened

6) Make sure that the exported texture is 16 bit exr image

7) Load the exported texture and link it to the geometry in Nuke

8) Load the original image, load the geometry once more and link them in Nuke

9) ​Open the Vectorscope view in Nuke and compare the color range between both images

​

result: Clamped color range in the exported from Mari image

On the left is the range of the original image and on the right is the range from the exported image from Mari 

​

​​

​

​​

Expected behaviour
The exported image should have the same color range as the one imported

Actual behaviour
The exported image loses color range after it has been projected using a projector 

Workaround
Using the Paint Through tool overcomes this issue 

Reproduced by support
This bug has been reproduced in:

Mari 4.5v1 - Windows 10 - CentOS 7

Mari 4.2v2 - Windows 10 

Mari 4.1v1 - Windows 10 

Mari 3.4v1 - Windows 10 - OSX 10.12.6 - regression

Unable to reproduce bug in:
Mari 3.3v1 - Windows 10 - CentOS 7 - OSX 10.12.6

Earliest version tested
3.3v1 - This issue no longer appears in this version and has regressed