unpremultiply in combustion?

I'm having a problem. I'm compositing CGI elements which were rendered with premultiplied alpha and do NOT include the alpha. Alpha is in a separate file sequence. Thus, I use the alpha pass for compositing through the "Set Matte" Operator... and I get the expected ugly dark fringe.

I can find no way to solve this problem. Is there a way to unpremultiply in combustion? Even the most manual aproach seems impossible, since I can't find a way to mathematically divide the pixel's RGB values by the Alpha value.

Thanks for your reply Rayk.

The file does not have alpha embedded, but, believe me, it is premultiplied. Premultiplied is the same as what you mean by "rendered against a bg color". If saved as premultiplied, the pixels that do not have a full (white) alpha value are partly mixed with the black background, and thus are darkened, resulting in the ugly dark fringe we all know, when they are *again* multiplied by the alpha in the compositing process (in the "set matte" step in this case).

If it were not premultiplied, the render would look very ugly, with strange white-ish aliased borders, but it would composite perfectly with a separate alpha pass and I would have no problems

Check in your 3D application: save TGAs with premultiplied alpha and without (both without embedded alpha) and see the difference.

Rerendering would be the best option right now, but it's not an option anymore (big slow Vray renders, tight deadline). I'll look at the sapphire plug-ins you mention...

Mayec

I don't agree. As I said before, an image can be premultiplied without having saved the alpha that was used in the multiplication. As I said to Rayk, try to save a render from your 3d software both as TGA 24 bits premultiplied and not premultiplied, and see the difference.

maybe to get the steam out of the discussion before it gets really hot.
of course, the transparency of your fg object was taken into account by your 3d program to produce the rendered image. it would have done so, too, when there's something behind your transparent fg object. it's simply the way objects at different distances to each other get "packed" together to render the final image, that's the rgb info in it. you might relate it to an "over node"/operation in a compositing program. if i have a fg layer and a bg layer and i want to combine them together, it's done in the following manner: (fg*alpha)+(bg*(1-alpha)) in plain words, you take the rgb date of your fg layer and multiply them with the fg alpha values. you take the bg rgb values and multiply them by the inverse fg alpha values. then, you add both. that's just one small step of how a 3d renderer comes up with a picture, which i'm far from being expert in. since you usually have a lot of layers to comp in your composite it was handy to incorporate the first step of this "over operation" in the image file. the image was "pre"-multiplied, that is for further compositiong. in your case, the cg fg object with it's transparency/alpha information was composited/layed over a solid bg. when you choose to save that file "pre-multiplied" with a separate alpha file your 3d app gave you the above result as rgb info in a tga file and a separated file which contains the alpha. but that's not what is generally referred to as "pre-multiplied". the term itself refers to a way how transparency information can be stored in an image file. the alternative is "non-premultiplied" or "straight". in any case, the terms refer to alpha information in the image file.
now, you have a final rgb image and the alpha info which was used to derive that result, as well as, you know the bg color. it is fair to say, that you can reverse engineer that over operation which was done by your 3d app. unfortunately, c* doesn't have a divide node or operation (in the rgb arithmetics, for instance). but as i mentioned in my first reply, there might be options.

in case i wrote something which was not correct,please correct me.

cheers,
rayk

Thanks Rayk!

That was a very extense, precise and clear exposition of the problem. Now we know we're talking about the same thing. Thanks for not letting the conversation bog down!
So, on with it: I'm looking for ways to reverse engineer that step that happened during render, as you skillfully put it, and after fiddling with everything I could think of in Combustion, I'm looking for plug-in related solutions. There's an AfterFX plugins pack called Walker Effects, which includes unpremultiply (or divide) operations, but sadly it doesn't work with Combustion. So now I'm going to try the demo of the Sapphire plug-ins you told me about earlier. Updates coming soon...

well, thank you for your offer :o)
i thought about it a bit longer ... would you do a short test?
take your fg footage and just put it in the workspace.
do the same with the alpha and bg footage.
apply an arithmetic rgb op to the bg. apply a matte controle op to the fg alpha and check inverse. use this as a secondary input to the arithmetic op of the bg; connect all to r,g,b . in the arithmetic op set all three channels operator to multiply and channel to alpha. -your bg should display now a black hole in the shape of the fg alpha-. in the bg branch use another arithmetic rgb op (on top of the already present) and pipe the fg footage into the secondary input connectiong all three channels. set operator to add and in the channels red to red, green to green ... .
does it give you the same result as you get with the sapphire plug in?
it's a bit too early here in germany to test it myself :o)

glad i was of any help.
cheers,
rayk

I'm saving the math too! Thanks, Rayk. It makes sense: multiply is the inverse of division, after all, but thanks for thinking it through. Very cool.

-jeff