# Blender compositor: problem with saving/previewing semi-transparent pictures

I just created a super simple scene with a beam light (cylinder + emit + cycle render) on which I want to add a bloom/glare effect. So I did that in the compositor directly (I just used multiple glare to have a stronger result):

However, as you can see, the preview in the compositor window is not really the one I expect, it's like if glare failed (or if the alpha channel is dropped). On the other side, if I open the Render image/Viewer Node, then the glare is applied properly (???). Unfortunately, if I save the image via Image/save, what I get is the result without proper glare (here I just added a black background behind using Krita to check that is was not an artifact of my viewer):

Note that if I combine it with a background image using alpha over (don't know why, Mix does not work), then the glare is produced properly in both preview/render/saved image:

How can I properly save/preview my image with the render?

-- EDIT -- As suggested in comment (thanks) I tried to save it in .EXR... So of course it does not solve the problem of the render (to see the alpha channel in the render, I need to manually add a black background using an "alpha over" node), but now it's suuper strange:

• if I open with Gwenview: it adds a black background automatically, and the glare is applied.
• if I open it with Krita and Gimp, there is an alpha channel visible (Krita displays a warning saying that is will slighly modify the alpha channel because it can't deal with zero values), but the glare is not directly visible: So I tried to add a black background in both Krita and Gimp... While Krita does display the glare, Gimp is not able to display the glare at all even with the dark background! Moreover, Krita's version is brighter that what I can see in the blender render. Who is right? Krita or Blender?
• Finally, if I try (tried in Krita and convert from ImageMagick) to export to .png, then I (again) lose the alpha channel, even if I add a black background!

Could anyone explain why png is failing, even when converted from .EXR? Is it due to some high dynamic range? If so, can't I flatten the range/cut high luminosity to make it work as expected on .PNG files? Is there any method to make it work on png files too? I have to admit that I'm not really confortable using .EXR for multiple reasons:

1. file size is huge (20MB vs 300KB, it's basically x70...) and my files are quite simple so I don't want to use 20MB per picture
2. it seems that some software like GIMP does not handle .EXR files properly.
3. I can't include .EXR files directly in LaTeX and I need anyway to convert it back to .PNG at some points.

-- EDIT 2 -- So moving from 2.91 to 2.92 solves the difference between the compositor preview and the render preivew. But the saved png is still different. This was reported here, but apparently this is not considered as a bug because this is emisive colors... They suggest a method to try to fake it to obtain a .PNG, but in my case it does not work (see my answer in the bug report). Krita displays actually the same result as blender (assuming blender is configured to use "Standard View transform" Color management instead of filmic) when using .EXR, but Gimp does not give the good result.

So if anyone knows how to obtain .png (to save space and to use it in LaTeX) I'd love to ear it.

Also, I found multiple related threads:

They explain notably why EXR is needed and why .PNG is not enough:

PNG images can't represent objects that emit light but not block any light, due to the way they represent transparency. For that reason, you must always have some amount of volume absorption for the emission to be visible when saved as a PNG image.

However, I guess it should be possible to approximate it. To do that, I guess I need to find a way to extract emisive pixels. I tried to use separate HSVA to extract V and A, lighten A using V. The result is better, but I've the feeling that the alpha channel is "premultiplied" again...

• Don’t. Use. PNG. Ever. Use EXRs. Always. May 11, 2021 at 12:47
• @troy_s if I save with EXRs, it works better indeed (but it does not solve the problem of the preview: I need to manually add a black background with alpha over to make it appear), thanks! But what's wrong with PNG? Is the high dynamic range an issue here? It's super strange: if I import the .EXR in krita and save it as .png, I lose again the transparency! I really can't make it work with PNG? EXRs files are huge: 19.1MB (EXR) vs 334KB (.PNG) for the same file... May 11, 2021 at 13:05
• @troy_s Who it's super strange: GIMP does not displays transparency of these files properly while Krita can (but the result is quite brighter). Also, I can't anymore convert back to .PNG: I lose all colors that are in the transparent part when doing so! (and .EXR files are too big for my needs) May 11, 2021 at 13:26
• PNG is the problem; it doesn’t encode alpha properly. As a result, it doesn’t work. EXRs do in Blender. Simple alpha over and done. Plenty of good posts on this site to explain it. Worth some time. May 12, 2021 at 2:08
• i just downloaded your blend file ....connected your laser to the viewer and got...[![enter image description here][1]][1] [1]: i.stack.imgur.com/ZMQ4I.jpg. ....is this what you want or did i misunderstood...? May 12, 2021 at 6:33

The button is right there. ;)

I am not sure, whether you know, but you only see in preview, what you connect to the viewer node.

You only see in render what you connect to the composite node.

and this can be 2 totally different results.

if you wanna make sure that render and preview show the same, connect the last nodes like this:

• Thanks. So I tried to upgrade to blender 2.92 (3.X is not yet available in my distribution), and now the compositor preview is correct (it is now similar to the screenshots you sent). However, if I try to save the output file via Blender Render > Image > Save as (.png), all my semi-transparent parts are forced to be fully transparent... In your case can you actually save your file in .png and keep it transparent? May 17, 2021 at 14:02
• Apparently, this is reported here [1] but this is not considered as a bug (see more in my edit). [1] developer.blender.org/T88199 May 17, 2021 at 14:52

Bloom effect is a kind of effect that should be added to an image, rather than composited with Alpha Channel, so if you have a bloom effect image like this