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, [email protected] <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
