[Bf-committers] Problems with premultiplied alpha channel in 8 bit images

Lukas Tönne lukas.toenne at googlemail.com
Wed Feb 9 22:53:27 CET 2011


The changes to the viewer node were only related to the gl blend mode
when drawing image pixels. Those were rendered with unmodified
background color, which leads to plain addition of colors and
excessive brightness in opaque areas. I changed the blend mode from
(src*alpha + dst) to (src*alpha + dst*(1-alpha)), which should be the
correct blend mode for straight-alpha (!) images. For pre-multiplied
alpha it should be (src + dst*(1-alpha)), but i don't know if there is
any way to determine this from a given image in blender? If there is
no flag or similar to automatically set the correct blend mode, this
could be a fourth user option for image drawing, so users can at least
get the correct display if they know what alpha mode the image uses:

1. color only
2. straight alpha (s*a + d*(1-a))
3. premultiplied (s + d*(1-a))
4. only alpha as b/w

However, this problem is probably not related to the bug described
here (it might just have hidden it from earlier notice). My first
attempt at finding the cause was not successful, but this png issue
sounds promising ...

On Wed, Feb 9, 2011 at 10:20 PM, gespertino at gmail.com
<gespertino at gmail.com> wrote:
> I forgot to link the blend file where I tried to reproduce the bug
> inside the compositor by gamma-correcting alpha channel.
>
> http://ubuntuone.com/p/ROq/
> This forces the bright halo artifact inside compositor and the
> resulting appearance is the same you get when you compose the
> premulled PNGs from blender in other application (or Blender's VSE)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list