Strange white overlay, when resizing some images with alpha channel

[qarmin]

When testing differences of resizing in image-rs and fast_image_resize, I found that with some images wtih alpha channel, image-rs output is looking strange with additional whitish border

Left - original
Middle - fast_image_resize (5.1.2)
Right - image-rs (0.25.5)

Files - F.zip

I used this test project to test differences

https://github.com/qarmin/img_hash/blob/master/tools/test_resize_diff/src/main.rs

[awxkee]

You have to associate (premultiply) alpha before resampling and unassociate alpha after the operation if needed, this is required for correct blending.
Alpha association/unassociation currently is not supported in resizing.
To avoid artifacts in high-frequency regions of the image do not associate alpha if this is not necessary, or fill background with constant color ( and this one have some drawbacks ).

[awxkee]

Also, I'd like to note that because hashing is involved, this implementation is not deterministic, just like in fast-image-resize.
Even fast-image-resize uses the fixed point only for convolution of common u8, u16 images, it does use non deterministic methods to compute filter weights.
The results are implementation-defined, so you can't reliably use them for hashing.
To get deterministic results across all platforms, you need to use deterministic methods only. For example, using only power-of-2 scaling allows deterministic halving or multiplying by a power of 2.
Neither fast-image-resize nor the image crate (or others) do so.

[kornelski]

At very least the resize docs should warn about scaling alpha without premultiplication.

It's unfortunate that Pixel/GenericImage can't define whether the alpha is already premultiplied or not. It would be nice if resize could handle this properly by default.

[awxkee]

We implemented with @Shnatsel more or less reasonable solution for alpha premultiplication in #2223.

However, I don't think there is any agreement on its integration into the existing pipelines.