[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]:x64-windows@2.5.14.0 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:
![image](https://github.com/user-attachments/assets/358f154b-0def-49eb-b5b7-255801ae89fc)

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:

![image](https://github.com/user-attachments/assets/a0006d71-7047-458b-a0ab-65602c004e49)

[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?