Correct 16bit byte image transform to scene-linear in Eevee, but not in Cycles #64578

New Issue

Joaquín Kierbel · 2019-05-14T02:53:55+02:00

Joaquín Kierbel commented

2019-05-14 02:53:55 +02:00

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 770/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 416.94

Blender Version
Broken: version: 2.80 (sub 64), branch: master, commit date: 2019-05-13 19:09, hash: 27d097e92d
Worked: (optional)

Short description of error
In this example, a Filmic Log Encoding Base 16bit byte image is being transformed back to scene thanks to the new management features, but only properly working in EEVEE. Cycles result seems to be clamping all values >1 to 1.0.

Float images seem to work properly on both engines and 8bit byte images do the clamping thing on both engines (which I guess should deserve its own report)

But amusingly 16bit byte works properly only on EEVEE :P

Captures from 16bit byte Filmic Log Encoding Base source image set to Filmic Log in the new image node color-space setting. I realise now that it looks like a direct render of the cubes, but it's an image of a render attached to a plane, sorry if it's confusing:

EEVEE (correct result)

Cycles (wrong result)

The only thing changing between the two captures is the engine. Checked the scene values on offline render too, is not an issue with the view.

Exact steps for others to reproduce the error

Add plane
Create emission material for it with 1.0 strength and a FLEB 16bit byte image as color (attached one like that down here)
Set the color-space of the image to Filmic Log in the image node.
Compare renders of that plane from Cycles and Eevee.

**System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 770/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 416.94 **Blender Version** Broken: version: 2.80 (sub 64), branch: master, commit date: 2019-05-13 19:09, hash: `27d097e92d` Worked: (optional) **Short description of error** In this example, a Filmic Log Encoding Base 16bit byte image is being transformed back to scene thanks to the new management features, but only properly working in EEVEE. Cycles result seems to be clamping all values >1 to 1.0. Float images seem to work properly on both engines and 8bit byte images do the clamping thing on both engines (which I guess should deserve its own report) But amusingly 16bit byte works properly only on EEVEE :P Captures from 16bit byte Filmic Log Encoding Base source image set to Filmic Log in the new image node color-space setting. I realise now that it looks like a direct render of the cubes, but it's an image of a render attached to a plane, sorry if it's confusing: EEVEE (correct result) ![image.png](https://archive.blender.org/developer/F7035129/image.png) Cycles (wrong result) ![image.png](https://archive.blender.org/developer/F7035132/image.png) The only thing changing between the two captures is the engine. Checked the scene values on offline render too, is not an issue with the view. **Exact steps for others to reproduce the error** - Add plane - Create emission material for it with 1.0 strength and a FLEB 16bit byte image as color (attached one like that down here) - Set the color-space of the image to Filmic Log in the image node. - Compare renders of that plane from Cycles and Eevee. ![fleb_16bit.tif](https://archive.blender.org/developer/F7035134/fleb_16bit.tif)

Joaquín Kierbel commented

2019-05-14 02:53:55 +02:00

Added subscriber: @JoaquinKierbel