[Bf-codereview] Alpha premul pipeline cleanup (issue 7018048)

[sergey.vfx at gmail.com]

On 2012/12/28 14:25:43, brechtvl wrote:
> * Are we handling 16 bit PNG images correctly, are they convert from
straight to
> premultiplied on load and vice versa for loading?

16bit png should work now just fine.

Also, i do have pretty finished patch to support saving 16bit PNG from
blender, but that's another story.

> * For TIFF we should also read/write the metadata about the alpha
type?

Eeeh.. Looked into this and ended up with complete misunderstanding of
TIFF logic. With current code if we'll save 8 bit TIFF and load it back,
we'll need to use Straight alpha mode, and for 16 bit TIFF rendered and
opened in blender we'll set alpha to Premul, which correlates with our
assumptions. However, 8 bit TIFF would be opened incorrect in Gimp, but
will show correct in Gwenview (default KDE image browser).

Now, if at save time we'll use unassociated flag for 8 bit tiff, it'll
be displayed correct in Gimp. But we'll need to use Premul alpha mode
when opening it back in blender. And it will also look incorrect in
Gwenview.

So there's something crappy going on here and i can't figure this out
yet.

> * Is the image painting code working correct for premul float and
straight byte?

Float painting seems to behave properly. At least it seems it's behaving
the same way as krita/gimp.

However, byte buffers behaves quite fuzzy. When i do a stroke with white
brush on complete transparent image, i should see the whole stroke being
white in RGB display mode, but it fades up to darkish colors to the
sides of brush. Converting pixels from straight-byte to premul-float in
IMB_rectblend and using IMB_blend_color_float doesn't give correct
result here.

Afraid that's the part of patch where i do need some help because i've
currently run out of ideas what's going on there.

https://codereview.appspot.com/7018048/