Color space conversion happens under premultiplied alpha

[LoadingByte]

As far as I can infer from the code and have observed empirically, zimg premultiplies alpha before performing color space conversion. This has unexpected consequences when the conversion is nonlinear. For example, when we instruct zimg to convert the straight-alpha sample $[R, G, B, \alpha]$ from a gamma 2.2 TRC to a linear TRC, it performs the following steps:

• Alpha is multiplied in: $[\alpha R, \alpha G, \alpha B, \alpha]$
• Gamma 2.2 is unapplied: $\left[ (\alpha R)^{2.2}, (\alpha G)^{2.2}, (\alpha B)^{2.2}, \alpha \right]$
• Alpha is divided out: $\left[ \frac{(\alpha R)^{2.2}}{\alpha}, \frac{(\alpha G)^{2.2}}{\alpha}, \frac{(\alpha B)^{2.2}}{\alpha}, \alpha \right] = \left[ \alpha^{1.2} R^{2.2}, \alpha^{1.2} G^{2.2}, \alpha^{1.2} B^{2.2}, \alpha \right]$

This behavior caught me by surprise, and it seems strange and unintuitive. I don't feel like the alpha should creep into the chroma when just converting color spaces. And to further increase the confusion, the amount of alpha that creeps in depends on the color spaces between which you're converting.

I'm not an expert in the field though, so I wanted to ask you: is this intended behavior, or a bug?

[LoadingByte]

After some more reading, all sources indeed seem to agree that color space conversion should happen under straight alpha. So I think I'm not going insane.

Still, I wonder why no one has reported this bug in zimg before, especially seeing zimg's popularity (thanks for the amazing library btw!). Maybe it's a regression? I tested on 3.0.4, but looking at the code, the problem is still there in 3.0.5 and the latest master HEAD.