Solved: possible bug when resizing images with transparency - Page 2

David_N_ · ‎07-03-2017

Hello,

In the post here, you indicated that IPP resizing supported transparency. For the most part it seems to work okay, but there are problems around the border.

In the attached file "in.png" there are circles that are 100% opaque (alpha 255) and the rest of the image is 100% transparent (alpha value is 0). The pixel values around the circles are black with 0 alpha, and the rest of the transparent area is white with zero alpha.

When you resize the image using IppResizeLinear, based on the resize_mt example and the code here. to 50% of the size you see a grey border (see attached resize_mt_out.png). Somehow, the black pixels are "bleeding" into the resized image, even though the black pixels are 100% transparent and should not contribute to the final resized image.

In some cases, the borders of the resized circles have some transparency, and become semi-transparent in the original color that they were (black arrow in bleedexample.png) and others are semi transparent with black (red arrow in bleedExample.png).

Is this a bug, or is there something we can do about this? It definately seems to me that pixels that were 100% transparent in the original image should not contribute anything to the resized image.

We saw the same effect with cubic filter as well

BMart1 · ‎07-05-2017

I am dealing with RGBA images that either have fully transparent or fully opaque pixels. After premultiplication, the fully transparent pixels should all have values of (0,0,0,0) and the fully opaque pixels will be untouched.

Correct.

Since I am resizing the image, I don't have a "source" and "destination" image as described in your previous link so I presume premultiplication will just do the multiplication on the source image based on its own alpha value.

Correct. Note that before saving the resized image back to .png you will have to undo the premultiplication.

So if I make a 50x50 image that is all (0,0,0,0) except for a 14 pixel red rectangle in the middle that is (255,0,0,255). This is starting off as effectively "premultiplied". Is that correct?

Correct.

Then I shrink that by 3 in each dimension (i.e. ippResize to 1/3 the size). I would naively expect that inside the shrunk rectangle it would be (255,0,0,255).

Correct

However, since 14 does not divide equally by 3, I would expect pixels on the border to be semi-transparent.

Actually, proper downsampling with the antialiasing resize functions will read several input pixels to generate each output pixel. Normally linear resizing uses two pixels to generate each output pixel. Since you are shrinking by a factor of 3, ResizeAntialiasingLinear will read 6 input pixels. You can avoid this by having your non transparent pixels be a multiple of 3 and also start at a multiple of 3 and disabling antialiasing or using supersampling. It won't look as good.

On the border of the shrunk rectangle it would be (255,0,0,x) where x is the transparency of that pixel as determined by whatever filter I was using. It should not vary in the RGB portion, which should always be (255,0,0) but may have different values in the alpha pixel depending on the filter.

No. Border pixels will be (x, 0, 0, x).

View solution in original post

Zhen_Z_Intel · ‎07-06-2017

Hi,

The formula for AlphaComp with Over is : C_r= α_A*A_r+(1- α_A)* α_B*B_r , α_C= α_A+(1- α_A)* α_B

But the formula for AlphaComp with OverPremul is : C_r=A_r+(1- α_A)*α_B*B_r that means image B pre-multiply with (1- α_A)*α_B and add to image A.

And the AlphaPremul is actually each cannel os image pre-multiply with its alpha value: C_r=α_A*A_r

Best regards,
Fiona

David_N_ · ‎07-07-2017

Hi Fiona,

I understand that now, but the issue was the expectation. The documentation for alphaComp says

This function performs an image compositing operation on RGBA images using alpha values of both images. The compositing is done by overlaying pixels (r_A, g_A,b_A, α_A) from the foreground image pSrc1 with pixels (r_B,g_B,b_B, α_B) from the background image pSrc2 to produce pixels (r_C,g_C,b_C, α_C) in the resultant image pDst. The alpha values are assumed to be normalized to the range [0..1].

As such, I expected that if I pass in (256,0,0,128) and do AlphaComp with (0,0,0,0) with ippAlphaOver I would simply get back (256,0,0,128) since blending against a transparent image should do nothing.

However, if you do it you get back (128,0,0,128). That is because AlphaComp seems to always return the results as premultiplied Alpha. I understand that you have listed the equations in the documentation, and the equations (at least for ippAlphaOver) result in -premultiplied alpha.

Updating the documentation like

This function performs an image compositing operation on RGBA images using alpha values of both images. The compositing is done by overlaying pixels (r_A, g_A,b_A, α_A) from the foreground image pSrc1 with pixels (r_B,g_B,b_B, α_B) from the background image pSrc2 to produce pixels (r_C,g_C,b_C, α_C) in the resultant image pDst. The alpha values are assumed to be normalized to the range [0..1]. The resulting pixels in pDst will be in pre-multiplied alpha convention.

Would be helpful