Is there an alpha bug with PNG files - it renders with PSD !?

Here is a rendering

Left : PSD file with transparent background
Right : PNG file with transparent background

http://f.cl.ly/items/1m3M1D0i0F1h1j3y2l3c/alpha.jpg

Material setting:

Image: Using Alpha
Influence: Color + Alpha
Material: z Transparency set to 0

Use “Premultiply” Klaus

uh… it’s Klaus, right? I remember you from Pixels 3D days.

Hey zavigny,

yes thats me but it is Claas not Klaus. While I am German my name is Dutch. Oh yah the good old Pixels 3D days.
Still miss Shadermaker Pro - that was a very good concept.

Thanks for the tip - it of course works right away, I am curious why this needs to be checked with PNGs and not with PSDs.
I mainly work with PSD and just for a project need to switch to PNG and thus did not encounter this issue before.

Sorry… Claas. I don’t know why PNGs need that either. In fact I have no idea what premultiply actually does. Seems like it might be best to have it on by default, but I don’t know what else it may be affecting, so I wouldn’t want to outguess the developers. Wait…Ok, I went to the Docs before posting and found this:

“Use the PreMultiply button when the foreground image and background images have a combined Alpha that is greater than 1.00; otherwise you will see an unwanted halo effect.”

…and YES! Shadermaker was terrific. The best I ever used.

what confuses me is actually why this options only needs to be activated with PNG and not PSD file as normally both files offer the same input RGB color and transparent value ???

I thought Blender dropped PSD (and GIF too if i remember well) support several versions ago ?

Nope works very well on my side :wink:

I had to check to see if my memory was betraying me and on the blender.org :

For windows it has been decided that we should use FFMPEG for video and to drop quicktime support. This also means some image formats such as GIF and PSD will no longer load.

So i was not yet losing my memory, but it was incomplete, the “no quicktime, no psd and no gif” is only for window OS, that’s probably why it works very well for your system.

In theory theres’s no difference in straight and premultiplied alpha.
Premultiplied alpha is used to cut down the multiplications when displaying, and as the name says, the color value is premultiplied with the alpha value.

Straight Alpha:
target.color = source.color * source.alpha + target.color * (1.0 - source.alpha);

Premultiplied Alpha:
target.color = source.color + target.color * (1.0 - source.alpha);

The “source.color*source.alpha” is simply done beforehand and the result stored in the image.
I’ve put together a small image thingy:

http://gallery.arexma.net/ba/pngalpha/pngalpha_full_tn.jpg

The .xcf (GIMP) for closer inspection :wink:

It’s a shadeless sphere with a blend-texture for z-transparency.

For the PNG problem I am not entirely sure, I’d have to do some reasearch, but IIRC it has something to do with the stored background color in the image. I don’t know how PSD looks, but png and tga, store the background color as well. So the transparent areas are not empty, they have a background color with an alpha value.
If this is interpreted wrong, you get the white borders with straight alpha.

You can see that the straight alpha blends towards a white color as the RGB is completely white, so with the alpha over it blends towards a white.

The premul has the Alpha premultiplied in the RGB and with the alpha over it looks just more right.

You also see that the “sky” is a premultiply as well, with the sky color and you see the blackish border around “premul” and “straight”

So my guess is, that the white borders with straight alpha in png is simply a misinterpretation of whatever is displaying it.

But this is a rather intresting topic, maybe someone has some more profound insight.

arexma hey thanks for this explanation !

Sanctuary I am on OS X the native quite time platform and I guess they left QT and PSD active here. I remember the news about dropping it months ago like you mentioned.