Page MenuHome

Blender 2.91.0 Alpha - Blender cannot export proper image when containing smooth gradient of Alpha
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-25 20:54, hash: rB83dc97ccc081
Worked: (newest version of Blender that worked as expected)

Short description of error
ISSUE is appearing when you try to save-as and export an RGBA image as .PNG etc, out of Blender result looks completely different by color, different brightness, etc. (3), not only in Photoshop but also in Windows Viewer.

Exact steps for others to reproduce the error

  1. Open the attached blend file
  2. Press render
  3. Save-as RGBA ... .PNG file format, etc. save on your local device
  4. Open the outputted image in any program or viewer and compare again vs blend file to see the difference
  1. By the way .EXR format looks correct, but not the PNG. Once I render the.EXR needs to convert all the sequences to.PNGs once again

Event Timeline

I can see a big difference between 2.83.6 and 2.91.0.

The problem is how the file is displayed in Image Editor.

@Yevgeny Makarov (jenkm) they fix The Image Editor issue in Blender 2.91 there is no issue, you can see my image above. Check here: https://developer.blender.org/T52680

So the BUG you are showing is fixed already. But..

The problem is coming now about the output of this. When you save as such image as RGBA -png, exr.. etc the result out of Blender looks really, really different.
I test via Window Image Preview, Photoshop, AE same.. result..

Ivaylo Gogov (ivaydesign) updated the task description. (Show Details)EditedOct 5 2020, 11:08 PM

Quick Update,
I tried the same with.EXR and TIFF - and working but not completely fine.
.PNG is not working at all. Now all sequences and render passes from EXR need to be converted to .PNG, and it is really time-consuming and annoying process.

  • Could you please check and advise for a solution to this bug?

I would like to properly render many sequences as PNG's from Blender.

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export. Though, I don't insist on it, just a quick test.

This is the same problem as described in T81101: Saving image with Alpha (like bloom) not saving correctly
In short, emission + transparency does not do well in some image formats.

This not related to "emission + transparency", this also happens with normal 8bit png images,
it looks different in the Image Editor (2.91.0) than in photoshop or in the 2.83.6.

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export.

@Jeroen Bakker (jbakker) You can use the file I attached, you can see there is no difference between viewport rendering and image editor, once is get rendered. The problem is coming when you want to Save as the output. Please check, simply following the steps above.

When comparing you should add the comparison with the whole 3d pipeline. The bug was that the alpha of rendered image in the image editor was off from the 3d viewport, The 3d viewport was correct.
The reason was that the image editor (2.90 and earlier) used to be doing the alpha blending in display space and not in scene reference space.
Alpha blending should be done in scene reference space (follow the color management settings and ocio configuration).
PNG images and other file formats do alpha blending in display space (srgb), the issue of alpha differences is now moved towards Image IO.

NOTE: that the same problem exists when importing a PNG file with transparencies and use it the transparency in a material or compositor. The image editor shows the effect that it has.

Keeping this in mind you see that a solution will always have limitations. For now if transparency is important use a file format that is flexible in color management for best results. I believe that the best option for usability is to decode and encode the alpha channel to get close to expected results. Not sure if OCIO can help in this case.

@Jeroen Bakker (jbakker) I completely agree with your comments.
My observations after many hours of comparison and analyzes are the same.

I would like to recommend you for fixing the issue, counting the complete process and pipeline of render production.
Based on my latest observation RESULT compared between 3D view-port and Image Editor --- THERE IS NO DIFFERENCE. The difference is coming when I want to Save As the product out of it.

So here, my thoughts are dividing by 2 possible projections. You tell me, which one is correct, and it can be used.

1/ Projection of thought:

  • After the Setup the Scene in 3D-view-port and calculation of all DATA is stored temporary "somewhere", by definition of TYPE [buffer for poly/meshes; buffer for vertex color, textures, buffer fro shaders]

In this way as an output of rendered image we have result of that buffers combinations merged based on Zdistance, space-AO,GI, REFLECTIONS, EMISSIONS etc.
So the first logic calculating and merging the data -by- transferring it on ImageEditor Screen, and based on transfere here, alpha it cannot be calculated properly because is not stored properly, or it is not projected properly compare the life 3D-viewport-screen.

2/. Projection of thought

  • IF the data of the Alpha cannot be stored properly, there will be no way of projecting it properly. Which mean the focus should be how this data need to be a/stored b/transferred c/projected on final output image.

Probably the HIGH dynamic range images as you mentioned will look more accurate on look, but again it will not be exactly based on the present. Additional alpha adjustment will be always required.

Some questions:

  • how you store the alpha?
  • what approach you are using to transfer the color data and how you combine it with the alpha?
  • what should be added in addition to make possible Image Editor to Save As properly images with such Alpha.

Thank you, Respect for you work and huge effort!
Regards,
Ivaylo

I am having the same problem.
unfortunately, I can't share the blend file but I have attached a screenshot, and is there any workaround for this?
I am working on a really imported project.

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.91.0 Beta, branch: master, commit date: 2020-10-26 17:29, hash: rBedf4378c442a

Thank you,
Regards,
Gurlaldeep

Jeroen Bakker (jbakker) changed the subtype of this task from "Report" to "Known Issue".

If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Nov 25 2020, 4:51 PM

I am setting as confirmed, since it was classified as a Known Issue.

If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

I tried open EXR and keeps the alpha but not glow\bloom

Hello @Clément Foucault (fclem)
Same here, I see a big difference between what people are trying to mention and what the reality is.

`Real example:
`I'm using a blender to showcase and develop assets using alpha and smooth gradient effects.
After this confirmed, I'm moving this production to the development stage from which we need to collect the data from Blender. The standard format for 95% of the real-time render engines we used is PNGs. Not because we want it, but because the support of Open .exr's and others are not compatible with the render engines for embedded systems in Automotive Industries, where I work and develop using Blender.

--> I see a big difference when I export transparency open.EXR image especially when this not 32bit.
Basically, 90% of the TFT's for that field are supporting 16bits but not 32bits.
When I Open the.EXR and convert it to 16bit, there is a big difference in the colors, through the alpha, and basically this simply was not working.

!!! Converting the data once again, after is been ready in Blender is something that I really struggle with since I found such a defect exists.

All capabilities of Blender exporter are not in sync when this related to > **an image with alpha-transparent - smooth-gradient, especially when we save out of Blender to any format.

I still cannot understand what is so difficult for that fix?
Tell me please, where is the blocker?

The program it is been in serious development for years, and I'm really thankful for that.
However, we have been part of it also, and we have been supporting the process all the time. Now, I see something which I'm told cannot be resolved for more than 1 year ..?

@Jeroen Bakker (jbakker) If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

@Jeroen Bakker (jbakker) I'm giving you an example that, your suggestion won't work properly

  1. You create an image in Blender using a smooth alpha transparency gradient. Then you render it F12.
  2. Save this image in any format (however you want Open EXR for example)
  3. Open EXR is supported only as 32bit, when you load this in photoshop or AE or any other program, you will have a number of limitations to do simple post-production. THEN
  4. You have to convert the image from 32Bit to 16Bit and look what will happen?! -> it will look completely different

Even you won't do any post-production. The image will be completely different when you convert it from 32bit to 16bit.

How does this work for you? I don't know :) Still wondering ...

@Ivaylo Gogov (ivaydesign)
I'm not sure I understand the issue. I've edited the original file to include some 3D solid color planes to check if blending is
the same in other applications. Of course it only works if said application uses the same colorspace. Here this works because Scenere Refered colorspace is the same as Display Linear space (using the Standard view transform).

What I can say is this: exporting the render as .png and opening it in Gimp shows wrong alpha blending with the alpha checker / background color, BUT it does blend correctly if I put a layer with same color below it.

Over black checkerboard/backgroundOver black layer

To me this looks like blending in the wrong color space. Maybe there is an issue with this in photoshop as well? I know there is an option to enable linear blending. https://blog.prototypr.io/psa-on-mischievous-opacity-72bb355e6069

If this isn't the issue please post an image of what you get when you open the render with photoshop.