I have a PNG watermark which I am .CompositeWithPositionAndGravity. If I composite it over an image everything is fine. If however I composite it over the area from a .Resize it improperly composites and doesn’t appear to pre-multiply properly or something.
An example of this would be a watermark .png over letterboxing or in this case pillarboxing.
Thank you for your report! We will look into this.
This happens because the matte is transparent black instead of opaque black. I’m not sure what the best fix is; perhaps we should change the matte to opaque black?
For now you can work around this problem by making the image opaque after resizing. You can do this using the SetChannel method:
img.Resize( width, height )
img.SetChannel( 'A', 1.0 )
How are you compositing?
F*A + BG * 1-A
Wouldn’t the best solution to just composite properly? 
I don’t see where in the standard “over” equation it would cause that bug. We can do the setChannel method in the interim. But I’m not sure why any composite equation would result in that.
Draft’s output is non-premultiplied. Nuke appears to produce the same result, for example.
There may be something wrong, but it would seem surprising to me if compositing A over a fully transparent B changed A’s color? (Assuming non-premulitplied colors).
That’s definitely not the nuke system. It appears to premult the FG if it’s over 1.0 Alpha. The BG’s alpha is irellevant in the standard OVER composite:
Unpremultiplied FG:
FG(RGB)FG(A)+BG(RGB)(1-FG(A)) Equation.
Premultiplied FG:
FG(RGB)+BG(RGB)*(1-FG(A))
The BG would get treated the same regardless. If it wasn’t premultiplying the Alpha then you would see a bright halo over the BG too. This is doing some bizarre equation that I’m not sure about.
As far as I know, BG’s alpha does not appear in those equations because they assume that BG is already premultiplied. (See for example Wikipedia’s article on alpha compositing.)
Premultiplied FG, premultiplied BG:
FG(RGB) + BG(RGB) * (1 - FG(A))
Unpremultiplied FG, unpremultiplied BG. Here we must multiply each color by its respective alpha. This is the equation used in Draft:
FG(RGB) * FG(A) + BG(RGB) * BG(A) * (1 - FG(A))
The output of this equation is premultiplied, so finally Draft performs an unpremultiply. Perhaps this is the step that surprises you?
Ahhh, that makes sense. And yeah, that final unpremult seems loopy. Nobody does that.