Alpha coming from compositor effects not saved properly in final image ( whatever the format, png, tga or exr, is ) #88199

New Issue

CJ L · 2021-05-11T15:26:28+02:00

CJ L commented

2021-05-11 15:26:28 +02:00

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GT 610/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 391.35

Blender Version
Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: 02948a2cab
Worked: IDK

Short description of error
Alpha halo around mesh are not saved properly when background is transparent.

Exact steps for others to reproduce the error
Hit F12 or CTRL+F12
Look at final render; this is what i want to be saved.
open the saved file in gimp.
Add a layer mask transfering alpha.
show layer mask.
Note the blue hazy glow place is pure black ( alpha =0 )
This is unexpected behaviour.

Here's the blend:
lightning2.blend
regards :)

**System Information** Operating system: Windows-7-6.1.7601-SP1 64 Bits Graphics card: GeForce GT 610/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 391.35 **Blender Version** Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: `02948a2cab` Worked: IDK **Short description of error** Alpha halo around mesh are not saved properly when background is transparent. **Exact steps for others to reproduce the error** Hit F12 or CTRL+F12 Look at final render; this is what i want to be saved. open the saved file in gimp. Add a layer mask transfering alpha. show layer mask. Note the blue hazy glow place is pure black ( alpha =0 ) This is unexpected behaviour. Here's the blend: [lightning2.blend](https://archive.blender.org/developer/F10078979/lightning2.blend) regards :)

CJ L commented

2021-05-11 15:26:28 +02:00

Added subscriber: @pitibonom

Richard Antalik commented

2021-05-11 16:32:02 +02:00

Added subscriber: @iss

Richard Antalik commented

2021-05-11 16:32:02 +02:00

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

Richard Antalik closed this issue

2021-05-11 16:32:02 +02:00

Richard Antalik commented

2021-05-11 16:32:02 +02:00

Issue here is, that you don't specify alpha, glow you see is purely emissive.
You can plug RGB color into alpha socket which will produce image with alpha channel as you expect. You may need to apply some processing to get desired result.
Depending on what you want to do in GIMP, you could save render as EXR, as GIMP should be able to handle emissive colors.

This isn't a bug though, so I will close this report.

Issue here is, that you don't specify alpha, glow you see is purely emissive. You can plug RGB color into alpha socket which will produce image with alpha channel as you expect. You may need to apply some processing to get desired result. Depending on what you want to do in GIMP, you could save render as EXR, as GIMP should be able to handle emissive colors. This isn't a bug though, so I will close this report.

tobiasBora commented

2021-05-17 16:37:24 +02:00

Added subscriber: @tobiasBora

tobiasBora commented

2021-05-17 16:37:24 +02:00

I'm having the same "bug", however plugging RGB colors into alpha sockets does not produce really the good png. Here is what I get without any background in blender:

Here is what I get if I add a black background in blender:

Here is what I get if I plug the RGB colors to the alpha socket inside blender (at least it's what I understood from your comment)

Here is what I get if I save this last image in a .png, load into krita, and add a black background:

Which is very different from what blender shows me. If I use .EXR, the result is again different from what I get from blender (much brighter), but it is definitely better than the .png:

Actually, I'm realizing that this seems to match exactly the blender version if blender is configured to use "Standard view transform" instead of the default filmic view (which flattens a lot the colors, no idea why it is default):

But unfortunetely, .EXR takes much more space than png (26MB instead of 2MB...), cannot be converted reliably to .png (so no way to save space), and are not really nice to work with: for instance in Krita if I copy the EXR layer into another png file, I lose again most of the alpha channel. Moreover, results are not consistent between different softwares. For instance, if I do exactly the same operation in GIMP (i.e. just add a black background to the .EXR file), I get a very different result from what I get from blender and Krita (I guess GIMP is wrong here?).

Moreover, I can't use .EXR files in LaTeX.

So I've 2 questions:

why saving .png could not also take into account emissive colors?
how could I "fake" that properly in blender and/or via an external conversion program?
any reason why Gimp gives a very different results for the same .EXR file opened with Krita?

I'm having the same "bug", however plugging RGB colors into alpha sockets does not produce really the good png. Here is what I get without any background in blender: ![image.png](https://archive.blender.org/developer/F10117368/image.png) Here is what I get if I add a black background in blender: ![image.png](https://archive.blender.org/developer/F10117361/image.png) Here is what I get if I plug the RGB colors to the alpha socket inside blender (at least it's what I understood from your comment) ![image.png](https://archive.blender.org/developer/F10117378/image.png) Here is what I get if I save this last image in a `.png`, load into krita, and add a black background: ![image.png](https://archive.blender.org/developer/F10117391/image.png) Which is very different from what blender shows me. If I use `.EXR`, the result is again different from what I get from blender (much brighter), but it is definitely better than the `.png`: ![image.png](https://archive.blender.org/developer/F10117407/image.png) Actually, I'm realizing that this seems to match exactly the blender version if blender is configured to use "Standard view transform" instead of the default filmic view (which flattens a lot the colors, no idea why it is default): ![image.png](https://archive.blender.org/developer/F10117470/image.png) But unfortunetely, .EXR takes much more space than png (26MB instead of 2MB...), cannot be converted reliably to .png (so no way to save space), and are not really nice to work with: for instance in Krita if I copy the EXR layer into another png file, I lose again most of the alpha channel. Moreover, results are not consistent between different softwares. For instance, if I do exactly the same operation in GIMP (i.e. just add a black background to the .EXR file), I get a very different result from what I get from blender and Krita (I guess GIMP is wrong here?). ![image.png](https://archive.blender.org/developer/F10117423/image.png) Moreover, I can't use .EXR files in LaTeX. So I've 2 questions: 1. why saving .png could not also take into account emissive colors? 2. how could I "fake" that properly in blender and/or via an external conversion program? 3. any reason why Gimp gives a very different results for the same .EXR file opened with Krita?

tobiasBora commented

2021-05-18 10:29:01 +02:00

For references, this answer explains very clearly why the solution proposed by Richard is not that simple. So I do think that Blender should provide more tools to properly handle the alpha channel when saving PNG files, for instance by providing a node "scene- to display-referred data in the compositor" as proposed in the aforementioned answer.

For references, [this answer ](https://blender.stackexchange.com/questions/222837/blender-does-not-set-the-alpha-channel-correctly/222893#222893) explains very clearly why the solution proposed by Richard is not that simple. So I do think that Blender should provide more tools to properly handle the alpha channel when saving PNG files, for instance by providing a node "scene- to display-referred data in the compositor" as proposed in the aforementioned answer.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Alpha coming from compositor effects not saved properly in final image ( whatever the format, png, tga or exr, is ) #88199