[BUG]Issue on transparent background with ImageBufAlgo.over

[VeroniqueHuang]

Describe the bug
While using ImageBugAlgo.over(fg, bg)
If fg is a half transparent image with a fully transparent background, the background part show a color on it.

OpenImageIO version and dependencies
I used pip install joon-oiio
ran vcpkg install openimageio[pybind11,freetype] and followed the instruction in this git repository
Bug tested on openimageio[core,pybind11,freetype]:[email protected]
openimageio_version 20514

To Reproduce
Steps to reproduce the behavior:

1. Install oiio as said above
2. "fg.png" should be a half transparent image with a fully transparent background
3. In a python file, run this code :

import oiio
from oiio import ImageBufAlgo, ImageBuf

fg = ImageBuf("fg.png")
bg = ImageBuf("bg.png")

if fg.spec().alpha_channel < 0 :
    RGB = ImageBufAlgo.channels (fg, (0, 1, 2))
    fg = ImageBufAlgo.channels (RGB, ("R", "G", "B", 1.0),("R", "G", "B", "A"))


if bg.spec().alpha_channel < 0 :
    RGB = ImageBufAlgo.channels (bg, (0, 1, 2))
    bg = ImageBufAlgo.channels (RGB, ("R", "G", "B", 1.0),("R", "G", "B", "A"))

composite = ImageBufAlgo.over (fg, bg)
composite.write("image.png")

Output:

5. The fb.png should just be on top of the bg.png, instead fg.png show some color where the pixel should be transparent.

Evidence

• In some previous version, if I run the same code, I get a correct output, with the fg.png background being fully transparent as it should. Tested and working on OpenImageIo version 20414
• openimageio_version 20414
• Expected result:

[lgritz]

Can you provide links to the exact png files that exhibit the error?

[VeroniqueHuang]

Sure
Fg image
And then for the background image you can try with any other image

[lgritz]

PNGs used for compositing situations always really confuse me. They are both sRGB transfer function and "unassociated alpha", both of which are ill advised when dealing with alpha, IMHO. Among other things this use of unassociated alpha is simply incapable of representing pixels that are very transparent while still adding light in the foreground ("glow elements" and the like), which very well may be what we're dealing with.

Like I said, it confuses me, so I admit that there's at least a 50/50 chance that everything I'm about to say is extremely wrong. But here's my thought process, I'm sure we can get to the bottom of it together. Also, we recently fixed some bugs with dealing with PNGs that have alpha < 1.0, so I'm only testing against main where it's "fixed." (Grain of salt: maybe I broke it rather than fixed it? Certainly possible.)

Let's try a synthetic test first, using a 50% opaque yellow square, and a very very dim and transparent yellow square which you should barely see. I'm using --autocc to ensure that PNGs are converted to linear color space upon read (for math), also PNGs being written are properly converted to sRGB.

# Ground truth: Linear, associated alpha
oiiotool --autocc --create 512x462 4 -box:fill=1:color=.5,.5,0,.5 150,500,300,300 -o half.exr
oiiotool --autocc --create 512x462 4 -box:fill=1:color=.02,.02,0,.02 150,150,300,300 -o dim.exr

# PNG: sRGB, unassociated alpha
oiiotool --autocc --create 512x462 4 -box:fill=1:color=.5,.5,0,.5 150,150,300,300 -o half.png
oiiotool --autocc --create 512x462 4 -box:fill=1:color=.02,.02,0,.02 150,150,300,300 -o dim.png

# Make some comps
oiiotool --autocc half.exr bg.png -over -o half-exr.png
oiiotool --autocc dim.exr bg.png -over -o dim-exr.png
oiiotool --autocc half.png bg.png -over -o half-png.png
oiiotool --autocc dim.png bg.png -over -o dim-png.png

Basically looks right to me.

On the other hand, when I use your files, I get

oiiotool --autocc fg.png bg.png -over -o weird.png

Weird, right?

Here's a screen cap of my displaying it on its own, using Apple's Preview.app (that is, no OIIO involved at all):

That kind of looks to me like it's adding quite a bit of light all around, not that it's totally transparent between the rays, if you know what I mean.

Which makes me wonder... how sure are we (and how can we be sure) that this FILE is correct?

[VeroniqueHuang]

It is, but I do believe that is the problem is fixed like that, when I see the image on my computer (Windows) it show me a 'correct' image, and the main problem was the background on the side that were supposed to be fully transparent.

Can you update the repository ?
Thanks !

[lgritz]

Doesn't it look like the sun image you're using in your examples is not the same image as the one you sent us? So are we comparing apples to apples? The sun image you sent has an outline and some kind of reflective/shaded appearance, whereas the one you keep posting does not. Are those different images? So I'm not sure if we're really testing the same thing. Can you either send us the file you're really using, or else test on your end using the same file you sent to us? I don't think we've yet established that the behavior is incorrect for the particular values in the file.

[lgritz]

Hi, just pinging this issue. I'm still confused about whether there's really a bug here and if we've got a proper apples-to-apples test.