Imprecision in IppiAlphaCompC_8u_C3R

[gol]

Whatever the values of the 2 alpha's in IppiAlphaCompC_8u_C3R (except 0 & 255, most likely because it simply bypasses/optimizes processing), the result always has each RGB component decreased by 1.

Most likely it's an imprecision somewhere, but it's quite annoying as it's common to blend 2 similar images in order to fade their difference. That is, take an image, store a copy of it, paint over that image, blend both and normally what's in common won't change, while the difference will be alphablended. Using IppiAlphaCompC, what's in common WILL change (each RGB value -1).

I've compensated the result by increasing each RGB component, it works more or less, just not on pure black.

Note that the Windows AlphaBlend from the GDI properly blends (while it too takes an alpha value in 0..255, not 256 which would be a better choice IMHO).

Another solution would be to draw the second bitmap in a 32bit RGBA, and then blend it with the original, but sadly I'm not finding a function to composite a 32bit image with a 24bit one (is there any?). I know I can convert the 24bit image to 32 back & forth, but it's gonna cost CPU. Alphablend in the GDI can properly blend an RGBA with an RGB, btw. Sadly the GDI usually costs a lot more overhead CPU thanfor the processing itself. This method also doesn't allow some kinds of processing, for example you would'nt be able to fadesomething ClearType-rasterised as it would require 3 alpha channels.

[Chao_Y_Intel]

Hello,

This function takes integers operations, and does not use any rounding. That's why it may create some data decrease:

For example, for the following code:

Ipp8u imga[2*2*3]= {10,10,10,10,10,10,10,10,10,10,10,10,};

Ipp8u imgb[2*2*3]= {10,10,10,10,10,10,10,10,10,10,10,10,};

Ipp8u imgc[2*2*3];

IppiSize roi = {2, 2 };

ippiAlphaCompC_8u_C3R( imga, 2*3, 255/2 , imgb, 2*3, 255, imgc, 2*3, roi, ippAlphaOver );

the value for imgc is '9', not '10'.

You can check ippi.h to learn how the value is computed for this function:

// OVER aA*A+(1-aA)*aB*B A+(1-aA)*B aA+(1-aA)*aB

// Here 1 corresponds significance VAL_MAX, multiplication is performed

// with scaling

// X * Y => (X * Y) / VAL_MAX

value = 10*127/255 + (((255-127)*255)/255)*10/255 = 10*127/255 + 128*10/255 = 4 + 5 = 9

To get the value you want, it looks that you need some functions that can take float alpha parameters, and get the round result.

Thanks,

Chao

[gol]

Mmh ok, so it works on purpose on bytes within the algo. I think it's too bad that it doesn't try to preserve as much precision as possible, working on packed 16bit MMX temporarily (that's what I do in my own code).
I mean IMHO the data types should more describe the sources/targets than the algo that's used.

I once posted about the lack of a function to filla rectangle with color & alpha, as this could be done in 2 separate steps (multiply then add), but losing precision, here too it's something that could exist as 1 function that preserves as much accuracy as possible.

Or maybe it's the kind of function that would benefit from a Hint parameter, accurate would be full precision, fast would mean working on bytes.

Same thing for the alpha's, I think that's too bad that they don't all take float alphas whatever the source/target format. It's especially annoying with bytes for which the alpha is 0..255 & not 0..256 (I use 0..256 in my own algos, makes more sense IMHO).

[Chao_Y_Intel · Accepted solution]

Hi,

Thanks for your feedback. I submitted a feature request to support float point alpha value in IppiAlphaCompC function. This can help remove the accuracy problem on this function.

Regards,

Chao

[gol]

I'm not sure I fully understand what you mean, but it's not really a matter of providing more accuracy for the alpha's. Well that would be good too, but it's a change in the processing itself that's required.

That is, alphablending an image with itself, with one alpha being 255, should be able to result in the exact same image (assuming that 255=full opacity like the manual says, and not 256). So even without adding anything new to the published SDK, the problem could be fixed.

But yes, I'm all for all integer-formatted functions to use floating point parameters, in general.

Thanks

[j_miles]

I can only second the opinion on the source types vs. the precision of the algorithm. The function should calculate with a better precision so that weird rounding artefacts are avoided. Sometimes there will be performance considerations but then it should be an option (via a parameter, e.g. as the suggest hint parameter, or another function) instead of a forced choice. In this case, it is particularly problematic that one cannot overlay an image onto itself without rounding artefacts.

Do you know if the same rounding problem applies to the per-pixel alpha blending functions, i.e. ippiAlphaComp_xx?

Thanks.

- Jay

[Chao_Y_Intel]

Hi Jay,

For per-pixel alpha blending functions, it also works in such way. We could consider changing such behavior in the functions, but we have concern that may affect other users , who are using the function. See if there is more feedback from the users.

Thanks,

Chao