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.

I was about to create a new bug report when I found this task.
I am using 2.93.5 and still have the same problem as described in the original report: When saving a PNG with smooth alpha transparency, the colors get completely messed up.


I tried correcting the color space using ImageMagick but no success.

Is there any solution available to fix this?
(And no I can't just use exr. I need a png with correct alpha transparency)

After reading the lengthy discussion here: https://developer.blender.org/T52680 I just want to summarize to see if I have gotten the correct points.

  1. Blender handles and display the alpha transparency correctly now
  2. Blender saves the alpha correctly, but PNG as a format is broken, which is why the saved images appear wrong

To which I reply: Even if PNG transparency is broken, since it is a widely used format, Blender should adapt and try its best to store it in a WYSIWYG manner.

For anyone having a similar issue and trying to get at least a somewhat accurate result: I was able to get an improved result by exporting the image as RGB PNG, then exporting the Alpha channel as separate grey scale PNG and then use ImageMagick to apply the transparency following this answer:
https://stackoverflow.com/questions/55376263/set-alpha-according-to-gradient-with-imagemagick/55377377

Also, since this appears to be a well known (and accepted ?) issue, how about a warning note in the export settings? This still seems to me like a major bug, but when the current position is: "Don't fix" then at least a heads up for the users would be nice.

Your points seems to be correct. Note that the described work-a-round can still introduce incorrect alpha blending as when apply-ing the transparency on a different color space than it was generated.
Adding an warning note in the export setting is a good idea.

Thanks for the quick answer.

Yeah, maybe I should have said it more clearly, the work-around doesn't give you a perfect result, but in my situation (where I need the png and care more about the overall look than perfect accurate blending) it gets me about 80% of the way, which is something I can work with.

*Sidenote: I guess an additional option in Blender to save it directly in a way similar to this hack may already be an improvement for many people

@Stefan Fallert (srfall) yes indeed. yes indeed. I was talking about this issue for a long time, but looks like was neglected, due to other urgent priorities on the road map, and squeezed schedule.
I think is a significant misalignment (bug) when we talk for high fidelity production, which is being there for years. There is no way to export a correct alpha from blender at the moment, doesn't matter if you use blender compositor e or other file type. At the end you always have to composite 2 flat images (once used as an alpha) the other as color, out of Blender to have an accurate look. Unfortunately, this is been for a long, long time.

Same bug happening to me. This is not a minor thing. There is any progress on this?