Wrong colors with some float TIFF files #58621

New Issue

David Vogel · 2018-12-03T16:33:14+01:00

David Vogel commented

2018-12-03 16:33:14 +01:00

System Information
Operating system: Windows 10 Pro 10.0.17134 Build 17134
Graphics card: Nvidia 660 GTX

Blender Version
Broken: 2.80 (sub 35), branch: blender2.8, commit date: 2018-11-30 00:46, hash: 4c31bed6b4, type: Release
Previous versions (2.79 and earlier) are broken too in similar ways.

Short description of error
Some float TIFF files get rendered in wrong colors in eevee or cycles. Even though the image looks correct in the image viewer, it will show wrong colors in the render. But i mainly tested normal maps, so the report will be about normal maps.

Here are some example outputs which compare the original float TIFF image with a version externally converted to integer. The image is applied as normal map, both versions of the normal map look the same in any external program or even the blender image viewer, but they render differently. Left uses the original image and right uses the converted image:

Description	Example output
Rendered in eevee
Rendered in cycles, but files are not packed into the blend file
Rendered in cycles, but files are packed into the blend file

I'm not sure yet, but it seems it doesn't happen with all float RGB TIFF images. I could only reproduce it with normal maps i have here. Some float RGB TIFF images for the base color didn't show any huge color differences in the output.

Exact steps for others to reproduce the error
Here is a blend file from which the above examples where created from. For some reason it makes a difference for cycles if the images are packed into the blend file, so you may unpack or repack the two textures to test. To reproduce the behaviour, just open the file in blender 2.8 and display the viewport as LookDev or Rendered. tiffbug.blend

**System Information** Operating system: Windows 10 Pro 10.0.17134 Build 17134 Graphics card: Nvidia 660 GTX **Blender Version** Broken: 2.80 (sub 35), branch: blender2.8, commit date: 2018-11-30 00:46, hash: 4c31bed6b46, type: Release Previous versions (2.79 and earlier) are broken too in similar ways. **Short description of error** Some float TIFF files get rendered in wrong colors in eevee or cycles. Even though the image looks correct in the image viewer, it will show wrong colors in the render. But i mainly tested normal maps, so the report will be about normal maps. Here are some example outputs which compare the original float TIFF image with a version externally converted to integer. The image is applied as normal map, both versions of the normal map look the same in any external program or even the blender image viewer, but they render differently. Left uses the original image and right uses the converted image: | Description | Example output | | -- | -- | | Rendered in eevee | ![Eevee.png](https://archive.blender.org/developer/F5801076/Eevee.png) | | Rendered in cycles, but files are not packed into the blend file | ![Cycles unpacked.png](https://archive.blender.org/developer/F5801199/Cycles_unpacked.png) | | Rendered in cycles, but files are packed into the blend file | ![Cycles packed.png](https://archive.blender.org/developer/F5801207/Cycles_packed.png) | I'm not sure yet, but it seems it doesn't happen with all float RGB TIFF images. I could only reproduce it with normal maps i have here. Some float RGB TIFF images for the base color didn't show any huge color differences in the output. **Exact steps for others to reproduce the error** Here is a blend file from which the above examples where created from. For some reason it makes a difference for cycles if the images are packed into the blend file, so you may unpack or repack the two textures to test. To reproduce the behaviour, just open the file in blender 2.8 and display the viewport as LookDev or Rendered. [tiffbug.blend](https://archive.blender.org/developer/F5801217/tiffbug.blend)

David Vogel commented

2018-12-03 16:33:14 +01:00

Added subscriber: @Dadido3

blender-admin commented

2018-12-03 16:33:14 +01:00

#63908 was marked as duplicate of this issue

blender-admin commented

2018-12-03 16:33:14 +01:00

#61439 was marked as duplicate of this issue

blender-admin commented

2018-12-03 16:33:14 +01:00

#59760 was marked as duplicate of this issue

blender-admin commented

2018-12-03 16:33:14 +01:00

#60583 was marked as duplicate of this issue

Brecht Van Lommel commented

2018-12-03 17:16:15 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-12-03 17:16:15 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-12-03 17:16:15 +01:00

Brecht Van Lommel self-assigned this 2018-12-03 17:16:15 +01:00

Brecht Van Lommel commented

2018-12-03 17:16:15 +01:00

It's a color space issue, Cycles and EEVEE use different settings and this will be fixed as part of #54659 (Move and share Eevee / Cycles render settings).

The solution for now is to set the image to Non-Color Data both in the node and in the image editor.

It's a color space issue, Cycles and EEVEE use different settings and this will be fixed as part of #54659 (Move and share Eevee / Cycles render settings). The solution for now is to set the image to Non-Color Data both in the node and in the image editor.

David Vogel commented

2018-12-03 18:08:29 +01:00

This issue has nothing to do with differences between cycles or eevee. It's not an issue between the two render engines, but rather an issue that sort of affects both equally.

I noticed it before eevee was a thing. In older blender versions normal maps were shown incorrect in the preview like i've shown above, but they rendered correctly in cycles so i didn't care much. But now with eevee they render incorrect, too. And by trying to narrow down the problem i also noticed that the same problem happens in cycles, but only if the images are packed into the blend file.

It has something to do with the way TIFF images are handled, and it happens especially with normal map images. Perhaps those images contain a color profile or some other information that is wrongly or not used by blender. I don't know much about how blender handles the data, but i'm sure it's not an issue that only lies between cycles or eevee.

Alone the fact that cycles produces different results if images are packed into the blend file or not, shows that there is something wrong in how blender handles the float TIFF image data. I hope this issue gets reopened.

Edit: Ok, declaring that image as Non-Color Data in the image editor too seems to fix it. So as long as it gets fixed with the other bug, it doesn't need to be reopened.

Thanks for the solution.

This issue has nothing to do with differences between cycles or eevee. It's not an issue between the two render engines, but rather an issue that sort of affects both equally. I noticed it before eevee was a thing. In older blender versions normal maps were shown incorrect in the preview like i've shown above, but they rendered correctly in cycles so i didn't care much. But now with eevee they render incorrect, too. And by trying to narrow down the problem i also noticed that the same problem happens in cycles, but only if the images are packed into the blend file. It has something to do with the way TIFF images are handled, and it happens especially with normal map images. Perhaps those images contain a color profile or some other information that is wrongly or not used by blender. I don't know much about how blender handles the data, but i'm sure it's not an issue that only lies between cycles or eevee. Alone the fact that cycles produces different results if images are packed into the blend file or not, shows that there is something wrong in how blender handles the float TIFF image data. I hope this issue gets reopened. Edit: Ok, declaring that image as Non-Color Data in the image editor too seems to fix it. So as long as it gets fixed with the other bug, it doesn't need to be reopened. Thanks for the solution.

Brecht Van Lommel commented

2018-12-03 18:09:45 +01:00

When images are packed, Cycles loads them through Blender like EEVEE. So it's the same issue.