topic Hi Giacomo, in Intel® Integrated Performance Primitives

ippiResizeSqrPixel

giacomo_c_ — Thu, 31 Oct 2013 09:18:06 GMT

I use ippiResizeSqrPixel function, which is now (IPP 7.1) deprecated to zoom and move with subpixel precision an image (Ipp32f).

In the process of trying to replace it with the suggested function ippiResizexxx, I found out that the replacement function has limitations.

The former, now deprecated function, did support an explicit zoom factor and destination offset expressed in double and that are no longer present in the new ippiResizeXXX. Now I',m evalutating ippiWarpAffine (with c01 anda c10 coefficients at 0) as a substitute.

What do you suggest?

Thanks,

Giacomo

Hi Giacomo,

Valentin_K_Intel — Fri, 08 Nov 2013 13:01:48 GMT

Hi Giacomo,

Yes, a new resize API has the listed limitations, while ippiWarpAffine can do image transformations with subpixel precision. However there is the difference between ippiWarpAffine and ResizeSqrPixel approaches: the first function considers an image as a grid with pixels as nodes, while the second function considers pixels as "squares".

Best regards, Valentin

Hi Valentin,

giacomo_c_ — Sun, 10 Nov 2013 08:37:50 GMT

Hi Valentin,

thank you for your answer. I can't understand which is the implication of the difference that you describe. The two function operation looks very similar: coordinate transformation (IppiResizeSqr pixel is a particular case of the more general WarpAffine) and resample using interpolation mode assigned. So where the difference that you describe come in?

Best regards, Giacomo

Imagine that you have an

Igor_A_Intel — Tue, 12 Nov 2013 07:14:55 GMT

Imagine that you have an image 13x13 pixels - so it should be clear that each row has 13 pixels but if it's considered as a grid - it has only 12 "distances" between these pixels. Applying ResizeSqrPixel and "old" Resize with 2x size increasing you'll have different outputs - 26 pixels row for the first one and 24 "distances" (25 pixels) for the second one. WarpAffine implementation corresponds to the second approach - so you should take this fact in mind - this is what Valentin has mentioned.

regards, Igor