Color ramped pre-multiplied images have solid background in PNGA preview and movie

Hello, I am confused as to this behavior:

Say, you have applied a color ramp to an image (with soft transitions from white to 0 alpha) with the alpha on the black input side anchor set to 0. When this is previewed as a png animation, there is a harsh halo/solid color around the the edges of portions going to 0 alpha/black. However, one can apply AlphaConvert node and resolve this. I am curious as to the logic of what is going on here.

As you can in the above image, I am even more confused because the anchor for the black input is set to black with alpha 0, as opposed to the blue that is shining through in the preview. The blue is the color in the center.

The image that the color ramp is being applied to is a an addition of several blurs to vector blurred sparks. The only thing I can think as to why the color shown for the pre-multiplied alpha is blue is that perhaps the color of the 0 alpha portion of the render layer (sky) is grey.

I am looking at an explanation to this with regards to how premulitiplied works. Considering this, I am guessing that using pre-multiplied alpha in situations like this does not work for non-alpha outputs, with this type of artifacting occurring on all outputs.

In addition, when this pre-multiplied image is opened in photoshop and a layer is added under it, there is no artifacting. I have not tested how this behaves with opengl shaders, flash or browsers.

You should render with alpha or without, don’t expect premult to work for both. The point is that the foreground color is inserted in the alpha fall off region, this will look odd (blocky) in a flat or non-alpha version.

Well, this issue is occuring with non-alpha output (PNGA). This is occuring with the PNGA preview, so I am curious as to if the output of this pre-multiplied image is incorrect or if it would, in fact, behave as expected in pre-multiplied alpha viewing implementations (browsers, flash, opengl, directx, it behaves correctly in Photoshop). So basically the question is: is the preview viewer just messed up or is the output messed up?

Just curious if somebody knows an answer as it would save me some time satisfying my curiosity and testing in implementations or checking the encoding.

Oh okay, now I understand and should have understood considering I added the straight to pre-multiplied.

So basically, the color ramp is converting to straight alpha I am presuming. Thus, the pixel value for some pixel is 1,1,1,0 with compositing node/saver ignoring the specified 0 alpha. It’s certainly confusing as to how the composite node would divide 1/0 when converting the pre-multiplied input to 8 bit PNGA but that is a different discussion and is probably caught as an exception leading to this peculiar behavior.

However, the following does not work:

From the color ramp, seperate the image output and combine it back together with the alpha using seperate RGB & combine RGB. Perhaps the output of combine RGBA is straight.