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
convertfrom 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:
- 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
- it seems that some software like GIMP does not handle .EXR files properly.
- 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:
- How do I get the Glare node to output transparent instead of Black background
- Render semi-transparent volume with cycles
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...