Cycles Image Texture Alpha conversion inconsistency with EEVEE and Image Editor #76187

New Issue

Manda Rajoelisolo · 2020-04-28T14:40:33+02:00

Manda Rajoelisolo commented

2020-04-28 14:40:33 +02:00

System Information
Operating system: Windows 10 Pro 64-bit (10.0, Build 18363)
Graphics card: NVIDIA GeForce 920M (Laptop)

Blender Version
Broken: v2.83.13 Beta, 2020-04-21

Short description of error
If an image is packed, it will get displayed differently in Cycles and EEVEE. It changes in EEVEE when
Alpha Mode is changed from Straight to Premultiplied to match Cycles, but it does not change in Cycles
by changing that option. If the image is unpacked Cycles will look like EEVEE with Straight Alpha Mode
and again it will not be changed by the Alpha Mode option like EEVEE is.

Exact steps for others to reproduce the error

Open the provided file.
Select the Image Texture Node
Go into the right panel in the Shader Editor (N-panel) into the Item tab and Properties subsection
Render Image
try changing Alpha Mode and rerendering.
try unpacking the image and rerendering.
try changing the Alpha Mode on unpacked image and rerender.
packed_image_cycles_display_inconsistency.blend

**System Information** Operating system: Windows 10 Pro 64-bit (10.0, Build 18363) Graphics card: NVIDIA GeForce 920M (Laptop) **Blender Version** Broken: v2.83.13 Beta, 2020-04-21 **Short description of error** If an image is packed, it will get displayed differently in Cycles and EEVEE. It changes in EEVEE when Alpha Mode is changed from Straight to Premultiplied to match Cycles, but it does not change in Cycles by changing that option. If the image is unpacked Cycles will look like EEVEE with Straight Alpha Mode and again it will not be changed by the Alpha Mode option like EEVEE is. **Exact steps for others to reproduce the error** 1. Open the provided file. 2. Select the Image Texture Node 3. Go into the right panel in the Shader Editor (N-panel) into the Item tab and Properties subsection 4. Render Image 5. try changing Alpha Mode and rerendering. 6. try unpacking the image and rerendering. 7. try changing the Alpha Mode on unpacked image and rerender. [packed_image_cycles_display_inconsistency.blend](https://archive.blender.org/developer/F8499431/packed_image_cycles_display_inconsistency.blend)

Manda Rajoelisolo commented

2020-04-28 14:40:33 +02:00

Added subscriber: @manda.3d.projects

Henrik D. commented

2020-04-28 15:19:50 +02:00

Added subscriber: @HDMaster84

Henrik D. commented

2020-04-28 15:19:50 +02:00

Where is the bug? Yes Denoise can cause artifacts if used wrong. That's known.

Is it about the albedo and normal pass? They are pretty good and you can work around the technical limitations.

Where is the bug? Yes Denoise can cause artifacts if used wrong. That's known. Is it about the albedo and normal pass? They are pretty good and you can work around the technical limitations.

Manda Rajoelisolo commented

2020-04-28 15:35:09 +02:00

The node "Denoise" has no artifact at all, it's perfect, it's famous made by Intel. But the artifact is all about the Noisy Image, Albedo and Normal input to the "Denoise" node.

And it's not a technical limitation, if you pack the Image Texture, then the artifact is gone like magic which proves that it's a bug, but not a limitation.

The node "Denoise" has no artifact at all, it's perfect, it's famous made by Intel. But the artifact is all about the Noisy Image, Albedo and Normal input to the "Denoise" node. And it's not a technical limitation, if you pack the Image Texture, then the artifact is gone like magic which proves that it's a bug, but not a limitation.

Henrik D. commented

2020-04-28 16:27:19 +02:00

Ok I kind of get your point now. So as far as I understand it, just packing a image will already solve the problem with the albedo pass. This is more likely to have something to do with the image data which is formatted in a different way when packed. If that is the case, then please simplify your report to the point where intel denoise is not even mentioned as denoise is not related to the problem at all. For a start you could try to compare the packed image and the unpacked image in the image editor with the sample tool (Ctrl+RMB) and see if there are differences in the critical areas.

Manda Rajoelisolo commented

2020-04-28 16:58:01 +02:00

@Henrik Dick (weasel),

Here is my quote in the step 3:

With the Image Texture Node, open the texture file "Tex.bmp" or "Tex.png", they will produce the exact same result, just to know that it has nothing to do with .png.

I had doubt if it has something to do with the image data format, that's why I used "BMP" which is the extreme in format simplicity, its binary format is a serie of RGB 8-bit and there is no compression.
The reason I used BMP is because it only has single setting (only RGB 8-bit, edit: also BW but no body use it), but PNG has multiple settings like BW, RGB or RGBA and 8-bit or 16-bit, and Compression Value, I just used BMP to remove the doubt on formatting.

Comparision between Packed and Unpacked
I had that doubt too, check the Step 5 to Step 8, we are about to Pack the image and Unpack it back which leads to the exact result as when it was not packed at all.

Here is Albedo of Step 5 vs Step 8: Pack it and Unpack it back.

Comparaison between Unpacked and Packed at the pixel (X:451,Y:22) with same value (R: 0.00392, G:0.00392, B:0.00392, A:1.0000). It's not completely black, but I intentionally leave the image like that because in real project most of the images are like that for an uncontrollable reason, Photoshop maybe.

@Henrik Dick (weasel), Here is my quote in the step 3: > With the Image Texture Node, open the texture file "Tex.bmp" or "Tex.png", they will produce the exact same result, just to know that it has nothing to do with .png. I had doubt if it has something to do with the image data format, that's why I used "BMP" which is the extreme in format simplicity, its binary format is a serie of RGB 8-bit and there is no compression. The reason I used BMP is because it only has single setting (only RGB 8-bit, edit: also BW but no body use it), but PNG has multiple settings like BW, RGB or RGBA and 8-bit or 16-bit, and Compression Value, I just used BMP to remove the doubt on formatting. **Comparision between Packed and Unpacked** I had that doubt too, check the Step 5 to Step 8, we are about to Pack the image and Unpack it back which leads to the exact result as when it was not packed at all. Here is Albedo of Step 5 vs Step 8: Pack it and Unpack it back. ![Pack Unpack.jpg](https://archive.blender.org/developer/F8499287/Pack_Unpack.jpg) Comparaison between Unpacked and Packed at the pixel (X:451,Y:22) with same value (R: 0.00392, G:0.00392, B:0.00392, A:1.0000). It's not completely black, but I intentionally leave the image like that because in real project most of the images are like that for an uncontrollable reason, Photoshop maybe. ![Difference.jpg](https://archive.blender.org/developer/F8499338/Difference.jpg)

Henrik D. commented

2020-04-28 19:19:12 +02:00

Added subscriber: @ankitm

Henrik D. commented

2020-04-28 19:19:12 +02:00

Here is what the report should be about: (roughly)

Cycles Image Texture Alpha conversion inconsistency with EEVEE and Image Editor

Short description of error
If an image is packed, it will get displayed differently in Cycles and EEVEE. It changes in EEVEE when
Alpha Mode is changed from Straight to Premultiplied to match Cycles, but it does not change in Cycles
by changing that option. If the image is unpacked Cycles will look like EEVEE with Straight Alpha Mode
and again it will not be changed by the Alpha Mode option like EEVEE is.

Exact steps for others to reproduce the error

Open the provided file.
Select the Image Texture Node
Go into the right panel in the Shader Editor (N-panel) into the Item tab and Properties subsection
Render Image
try changing Alpha Mode and rerendering.
try unpacking the image and rerendering.
try changing the Alpha Mode on unpacked image and rerender.
packed_image_cycles_display_inconsistency.blend

Notice there is nothing about denoise...
For your problem in your production, just use a Math Node to Subtract 0.01 from the image (with clamp enabled) and another Math Node to Multiply with 1.1 to make the white areas white (again clamp enabled)

@ankitm can you update the report?

Here is what the report should be about: (roughly) **Cycles Image Texture Alpha conversion inconsistency with EEVEE and Image Editor** **Short description of error** If an image is packed, it will get displayed differently in Cycles and EEVEE. It changes in EEVEE when Alpha Mode is changed from Straight to Premultiplied to match Cycles, but it does not change in Cycles by changing that option. If the image is unpacked Cycles will look like EEVEE with Straight Alpha Mode and again it will not be changed by the Alpha Mode option like EEVEE is. **Exact steps for others to reproduce the error** 1. Open the provided file. 2. Select the Image Texture Node 3. Go into the right panel in the Shader Editor (N-panel) into the Item tab and Properties subsection 4. Render Image 5. try changing Alpha Mode and rerendering. 6. try unpacking the image and rerendering. 7. try changing the Alpha Mode on unpacked image and rerender. [packed_image_cycles_display_inconsistency.blend](https://archive.blender.org/developer/F8499431/packed_image_cycles_display_inconsistency.blend) Notice there is nothing about denoise... For your problem in your production, just use a Math Node to Subtract 0.01 from the image (with clamp enabled) and another Math Node to Multiply with 1.1 to make the white areas white (again clamp enabled) @ankitm can you update the report?

Manda Rajoelisolo commented

2020-04-28 20:03:42 +02:00

@Henrik Dick (weasel), thanks, you are brilliant, the bug is not really about denoise, it's about something else.
And thanks, and I use clamp(clamp(image - 0.01) * 1.1) then the artifact I was talking about is gone.

Other method:

For developer, please fix the bug as Henrik explained before because not everyone will able to use the Map Range node, even genius like us were very confused what happening? Everyone can make mistake on their texture with pixel color value about 0.00392 instead of 0.

The texture was rendered with Blender that causes the non exact zero, it has precision and tileable with Blender, I always use Blender to make such detailed texture, it was not the first time.

@Henrik Dick (weasel), thanks, you are brilliant, the bug is not really about denoise, it's about something else. And thanks, and I use clamp(clamp(image - 0.01) * 1.1) then the artifact I was talking about is gone. Other method:![MapRange.jpg](https://archive.blender.org/developer/F8499581/MapRange.jpg) For developer, please fix the bug as Henrik explained before because not everyone will able to use the Map Range node, even genius like us were very confused what happening? Everyone can make mistake on their texture with pixel color value about 0.00392 instead of 0. The texture was rendered with Blender that causes the non exact zero, it has precision and tileable with Blender, I always use Blender to make such detailed texture, it was not the first time.

Ankit Meel changed title from ~~Artifact of the Denoise Filter in compositor on almost 100% transparent area~~ to Cycles Image Texture Alpha conversion inconsistency with EEVEE and Image Editor

2020-04-29 07:48:10 +02:00

Brecht Van Lommel commented

2020-04-29 08:17:26 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles Image Texture Alpha conversion inconsistency with EEVEE and Image Editor #76187