I just remembered… for cinema/movies: i saw sometime (actually years) ago that special effects like smoke and explosions where filmed in front of an black background…
…and they where mixed in such a way that they did appear in front of the objects they where added…
…so yeah… it’s not unsolvable… 
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
You could describe it as a PNG issue, since, as you already noted, the Glare node is correctly producing additive values, and Blender is handling them correctly in an associated-alpha ("premultiplied’) workflow, including showing them correctly in that viewer.
In an associated-alpha system, R, G, and B store one physical quality—the amount of light the pixel adds to the scene—and alpha stores another: the amount of light from behind it the pixel removes from the scene. This allows for the storage of pretty much anything: reflections, lens flares, fire, glows, solid objects… (The one thing they can’t do (by default) is RGB transparency (i.e. stained glass, chromatic aberration), since alpha is only one value and not three, alphaR alphaG alphaB. Although, since EXRs can store any number of arbitrary channels beyond RGBA, that functionality is also just a few clicks away (if you have a way to generate it).)
PNGs, by storing their data unpremultiplied, tie themselves to an unassociated workflow, which is also used in programs like Photoshop, where alpha doesn’t measure a physical property and is instead an arbitrary “transparency” mask. 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. EXR, on the other hand, doesn’t require that division/multiplication step, and simply stores the associated-alpha values it was given, which is why people suggest its use in these cases where additive pixels are involved.
Fundamentally, adding alpha to glows always risks situations like this, but I understand that as long as we live in a world where a lot of the major graphics & design programs still handle alpha badly, we’ll keep getting client requests & constraints like this, so… it is what it is.
@carterbk it was my ignorance of associated alpha!!!, im really scratching my head how i missed this all this time. all i do is watching CG stuff. tutorials and forums, so if i missed for this long, i’m glad i tried to add to this thread.
cause yeah, even if i called blender behavior odd, I honestly saw same thing in fusion in some cases and not others (maybe the file format used) without linking the pattern when that happens and when it not. and ended up cooking something even in fusion with the channel-boolean node lol
@Okidoki @carterbk really appreciate you guys for taking time explaining 
, i almost missed it again!!! couldn’t grasp all the previous references to PNG limitation cause i was thinking in an un-assosciated alpha . i will definitely read more about the subject.
as soon as I did hit post reply. and my brain so wait a second!!! it even answered a question i had about fusion for a while that have nothing to do with glare and glows:
when i want to fade out something that i generate in vector and animate the alpha to 0. it doesn’t get fully transparent if the RGB channels aren’t fully black. lol
I highly recommend this piece — great primer on alpha & compositing, deriving everything from first principles and building it up step by step.
And yeah, in a premultiplied-workflow program like Fusion, or Blender, or Nuke, alpha and RGB are assumed to already correspond to one another, so they won’t affect each other unless you specifically ask them to. In, say, After Effects, animating the alpha down will fade out the entire layer, since AE works in straight-alpha internally, and the layer’s alpha is “applied” at the end, during the compositing operation itself. To match the same behavior in a premultiplied workflow, you’d simply animate all 4 channels down at the same time (or animate the single value of the mix/opacity/influence/whatever-word-Fusion-uses, on the merge node itself).
The formula for the fundamental “over” operation (the default merge in Fusion or Nuke, an AlphaOver in Blender) is A + B(1-a). (Foreground) plus (background multiplied by inverted foreground alpha). Punch a foreground-shaped hole in the background, double-expose the values of the foreground onto it—it’s the same way we composited images 50 years ago, just with math instead of celluloid!
So if the alpha is zero, 1-alpha is 1, the background is multiplied by 1 (and doesn’t change), and then the foreground RGB is added, so the result is identical to an Add blend mode—which is what you were getting with your alpha-zero vector shapes. So that means “over” smoothly accounts for both solid and additive objects, all in one operation, which is great, as long as you know that’s what it’s doing!
I don’t think this problem will be easy to solve. 
The easiest way would be to print out the source as a layer and synthesize it, and that’s what I’m doing. 
Yeah, a single channel is weaker than white, so kinda makes sense to me it should produce less glow.
Color->BW node is weighted differently than setting HueSatValue node saturation to zero. The downloaded Lumens converter node group I use has its own color weighting.
Not claiming anything is right or wrong, just curious about the thought process and maybe make aware to others that there might be considerations to make.
I agree and nothing wrong or right (since the approach to start with is kinda wrong). i really meant here is a quick hack to make it kinda works for a quick png with alpha. maybe switching the color to HSL and taking the L will give a better results which i will give a try too if i need that (AGAIN for a quick png that is not worth being scientific about and i don’t want to explain to the client how light works, and even add a multiplier after that and tweak lol).
we had very informative feedback from other folks on this thread about the subject after my hacky wacky suggestion lol in case you missed. i learned some stuff
Oh, right, HSL, thanks for reminding me. Completely forgot about that - not so new anymore - mode. Need to check something in my custom stuff.
I had a similar probIem, and didn’t realize the glare node was guilty because not generating an alpha output. Thank you for this life saving response 
