Blender 4.2 transparent bsdf bug

[Habib_S]

After hours spending on Transparent BSDF and rendering all possible solutions and trying all solutions on internet, I’ve come to conclusion that this is definitely a bug in blender.

Please advise.

I’ve tried about 10 materials with Transparent BSDF, and all their render with eevee transparent on, and saving the render results as RGBA PNG, I’ve seen blender saving to PNG (as they should be transparent renders) will messing up alpha channel with RGB and actually save wrong channel data that will never be recoverable. Here is detail:

material shader part:

transparent BSDF color:

blender viewport with shading no problem showing transparent material:

Render output showing transparent material without any problem:

saving rendered image options (I’ve tried every combination with no luck):

now the problem arise just after saving renders. for more information, I’ve tried many other saving ways with blender python and all came with exact results.
this is saved png viewing on xnview or similar image viewers:

I’ve attached exact render save file from blender attached if you want to see too:

even opening same saved png inside blender image view show messed up channels:

Now I’m sure its a blender bug, or am I missing something?

Any advise will be appreciated.

[Bartosz_Matynia]

Could you also share Blender file?

[joseph]

Well, your emission is 50, which is a huge amount, so it’s not at all a surprise your saved result is all white. What’s more strange is that you’re not seeing that in the viewport, it’s probably something to do with your color management. Regardless, turn down your emission to 2 and see how it looks

[Habib_S]

test.blend (1.0 MB)

a simple demonstration. render image and try saving it as png. all channels will be messed up.

[Habib_S]

I dont think that should be problem, as many surfaces such as neon texture, explosion, … has a very great value of emission.
but in my original file, I even tried emission 2, and again color channel messed up again. so its not emission.

[RobWu (Rob)]

Took a quick look at your test scene, and it’s your emission.

If you set it to 1, it will give you the results you expect. I tried this for png, exr and tga.

Emission like 50 will mess up the saved file, and then in Affinity Photo I have to crank up the levels to get something visible in/as a alpha, and the color is gone as well.
Same for exr and tga formats with 50 emission.
I don’t know if this is a blender bug, or just values that go way off the ‘value chart’ for a png.

Look at compositing if you want to ‘level up’ the brightness imho…

[Secrop]

@Habib_S

a simple demonstration. render image and try saving it as png. all channels will be messed up.

I don’t see nothing wrong…
Just opened your file, rendered, save as png.
Restart blender with an empty scene, opened the image in the compositor, set the image’s color space to ‘Agx Base sRGB’ (the same color space as in your scene!!) and nothing different.

Further more, I opened your file once again and added a multicolored object behind your transparency mess… Did a render of the new object alone, and in compositor mixed this new render with the previous render from my first test. The end result is exactly the same as if I render the new modified scene with both objects visible.

[Kanerka]

As far as I can see, you save in 8 bits, so you need to select 16 bits.
8 bits Vs 16 bits :

[Habib_S]

color channels missing in both your screenshots.
original color is red:

[Habib_S]

the problem is, you should be enable to see png file saved in any app as it should be standard RGBA PNG.
it doesnt even show in blender “Image Editor” correctly.
also in compositing node, i cant get alpha channel and color channel to show the right way.
do you see them as I posted above?

[Habib_S]

this is with emission 2:

left is blender render window, right is saved png file. they’re not the same

[RobWu (Rob)]

It would help if you post the download for exactly the same scene you’re showing, instead of a different one where everybody else has no problems with.

[Secrop]

@Habib_S

[…] in any app as it should be standard RGBA PNG.

You shouldn’t encode your PNGs in Agx… Most apps don’t have the builtin logic to operate color spaces other than pure sRGB.

Also, you have to take into account that the PNG has a premultiplied alpha. So if you want to extract the ‘true’ colors from the image, you’d need to divide the color value by the alpha value.

[Habib_S]

I dont know where did I choose encoding as Agx. It shows RGBA float, RGBA16F

please elaborate

[Secrop]

Elaborated (from your test.blend):

[Habib_S]

no change:

png output:

[Secrop]

Here’s something Brech said in a devtalk thread (about a similar problem):

@brecht

The PNG image specification does not support these kinds of images with additive glow. When Blender writes a PNG image, it is discarded. What Blender could do better is try to write an image that looks as close as possible, but not exactly the same.

Whenever possible I recommended outputting EXR files, which EEVEE does support. This file format is designed for storing renders without data loss.

(this was in 2018, and some changes were made, but just on the Blender side. PNGs are still not a good support for this)

[Kanerka]

@Habib_S

color channels missing in both your screenshots.

No, it’s just that I activated the alpha view only., the color is there:

I’ve already had similar problems with .png in other software, so I wouldn’t be surprised if it’s a limitation of the file format.

If you want the raw data, use openEXR :

[Kanerka]

I found this:

GLARE is lost in exported .PNG (Cycles) despite these composite nodes ..?

yeah i used smoke footage on black, an add is enough when it’s a white smoke with maybe over clipped version of it as garbage matte if it’s in color choose one channel the dominant plug it as an alpha with a curve adjust in between to tweak the keying and maybe a blur. same way we used to cut hair in photoshop before smart erasers and IA took over lol

@carterbk

When the data goes into the PNG, it’s unpremultiplied (divided by its alpha), and when a program reads the PNG, it has to premultiply it (multiply it by its alpha), which kills any alpha-0 pixels (and also breaks any areas where the RGB might have been brighter than the alpha, since that will produce an unpremultiplied value greater than 1 and PNG only stores 0-1 values). This is a fundamental characteristic of the image format, it’s just how it’s designed to work.

I’ve just checked, in his test file, the alpha values are very low: 0.001, 0.0015, 0.0020

So colors are multiplied by 500-1000, then clamped during recording.
The result is a loss of data at output, with color crushing.

So this is a limitation of png.

[Joel_RVC]

Yes, as others say, this behavior is due to png’s design which only recognizes opaque alpha, not additive alpha. I imagine exrs can store this information due to their float encoding nature (png encodes integer).
One way you can bake the additive alpha to opaque is this:

Impossible to save image from Blender with Alpha

Try it if you must necessarily use png, if not I recommend using EXR.