Blender 2.92 not saving alpha values properly

Hi :slight_smile:

I got a problem with 2.92.
Made a funny animation with some postprocessing.
The result looks nice on the screen but when saving the render, blender only saves the renderlayer and not the renderlayer+postpro…
Here’s a pic of this:

On the left the render that i like a lot and on the right, the saved image in gimp.
The alpha layer is missing transparency fade.
I tried to save in various formats including exr float but nothing seems to work.

Am i missing something ?

thanjs for your answers and happy blending !

Might be related to this

I recall another similar thread but can not find it. Try using TGA or exr. (they did not say if it was a solution in that thread if it works in TGA let us know.)

yes @DNorman it is related :slight_smile:

They talk about TGA.

I already thought this could come from some format problem and therefore i tried all formats, even EXR in high resolution and it does not solve the problem.
It appears to come from blender.
Does anyone know a blender version where this problem do not occur ?

Not 100% sure, but looks like the same issue

sounds like it is :confused:

i’ll file a bug with my lightning project…

1 Like

Yeah, but make sure to check first if there are already reports. Maybe it’s already a known issue to the developers.

for sure ^^
Even if i know as you surely do that it’s not always straightforward to find already filed bugs on the dev site :wink:

Aside this @Habauk and as you seem to know about this problem :stuck_out_tongue:
Do you know wether or not there is a version of blender >= 2.79 that properly handles the postpro result saving ?

Thanks for your answer :slight_smile:

regards and happy blending !

EDIT: btw the 1st step would be to put my lightning blend here to let ppl give a try to it and tell me wether thy have the same problem as i do ^^
so here it is:
lightning2.blend (842.0 KB)
load the thing, hit F12 ( i set up a save node in postpro ) or CTRL+F12 for the full anim and please tell me wether or not alpha is fu*ked-up in the resulting images in various format :slight_smile:
thankies !

I’m honestly not up to date on that matter… I’m not even sure how many other tools/files support associated alpha (which is needed for properly encoding glows and stuff)

The tricky part is that the glow doesn’t occlude anything. Thats not possible to encode in regular (unassociated) alpha.

Maybe there is something in that thread:
https://developer.blender.org/T78578

In fact it’s pretty simple :slight_smile:
I wrote enough TGA encoders to know there is always and RGB for each pixel even for those with alpha = 0.
And if you save as TGA and disable alpha in unity or gimp, you see the ‘usually’ invisible color behing the transparent pixels.
And all the encoding process cannot be the problem as it’s too simple and obvious for beeing buggy ( i cannot imagine dev would the this noobs :stuck_out_tongue: ) and blender perfectly handles alpha in many ways ( shader, image viewer, and even renderer )
My opinion is that there’s a problem on what blenders exports after a postpro effect.
Just like if it only saves what is rendered forgetting about what goes through the postprocessing pipe.
I’m pretty sure this is an simple ‘oops’ bug :rofl: and all the cases i find now about this, comfort me in this opinion.
I never used postprocessing, so i cannot say wether or not 2.79 properly saves things ( i cannot imagine an LTS like 2.79 would not ^^ )

@Habauk i red the case in your link and though my english is not good enough I understand i got the same problem, and i also see it’s a kind of def dialog as some people consider this is not a bug.
I won’t run into this sterile discussion in what alpha really is but really hope serious persons in dev team will handle this as it has to be ^^

Thanks for your kind help !

and happy blending ! :slight_smile:

Okay… back there with some info :slight_smile:

I filed a bug, almost certain it was one ( as the final image content is different from the final result and IMHO opinion this defines a disfunction if not a bug ) and it is not one !

in blender world, difference between visual result and file content is an intended feature :rofl:

Okay more seriously it appears to be a matter of alpha.
Mr Richar Antalik whom i thank very much answered me here:
https://developer.blender.org/T88199

he told me:

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.

This is pure nonsense for ( i guess ) most people to connect RGB to alpha… at least as much as connecting your house gas inlet to the kitchen water tap ^^

but against all odds, THIS WORKS !!!
so here’s my compositor nodes setup:

and the result difference between the visual in blender ( left ) and the file in GIMP ( right )

The result is much closer to what i expect than in the 1st post of this topic ( though i suspect the final file has some fade to black in transparent parts than a color ( blueish ) sustain… )

I honestly do not understand at all what i did and why i did it as it doesn’t make sense but it simply works.
I hope this can help people who asked the same kind of question as i did here :slight_smile:

Happy blending !

2 Likes

Hi all :slight_smile:

Back here again with some more info…

As i said in the previous post, i had a small doubt about the alpha parts of the picture…
and i had to check it out as human eye is far from beeing perfect and sometimes show something that do not exist :sweat_smile:

I was right, saying they had a black ( wich seems to be the background default color ) component.
This picture is part of a 64 images animation. When stacking the animation in GIMP here’s what you get:

You can see the black part set up in the pictures stransparent stack.
This black comes from accumulation of very few black in transparent parts. And it should be blueish instead of black.

This comes IMHO from the lack in blender to properly handle tranparent things that contain the front color with transparency and a fraction of the background color.

Of course this is not proper alpha handling and i’m sur i’ll need more that 3 lifes to make devs understand this :joy: therefore i simply won’t try.

Instead i’ll ask here whether anybody knows a way to change the ‘forced to black’ compositor background color ?
If it is possible, then i’ll force it to the pure blueish glow color and this will do something very close to perfect…

But the question is: is it possible ? :wink:

happy blending ! :slight_smile:

It’s more efficient if you use blend modes than try to extract alpha values from glow areas. All image or video softwares have it, they’re meant for cases like that.

Blender:

PS:

From that file, lightning material was a 20 Strenght emission shader, and was causing RGB values to go way beyond 1. Compositing had a good visual result but math was very off, resulting in strange outcomes. Yet to solve that alpha issue you need to apply same glow effects to the alpha channel.

Left is RGBA, right is Alpha:

Thanks for all these infos @lucas.coutin :slight_smile:

As you said the compositing topic is a full time job and deserves beeing better known as i do :wink:

Unfortunately i lack of time for this and i guess i’ll always be a noob…

Anyway, with a try & redo method, i finally got exactly what i need ( without using the alpha input as the blender dev guy told me ).
Here’s the result:

This is the stack of the 64 images i need for my anim.

Note that all pics have to be saved in openEXR. any other format gives bad result ( LOL :rofl: )

for the curious, here’s my com:positor nodes setup:

Now i can go back to my time teleporter and my medieval city app :wink:

Thanks a lot and happy blending ! :smiley: