ippiResizeSqrPixel

[Terry_L__Sprout]

I've been using IPP ver 6.0.2.074 and I just upgraded to 6.1.6.056. My application uses ippiResize, which has been deprecated in 6.1. So now I need to use ippiResizeSqrPixel. Regardless of the function used, however, I still get a different behavior than what I got with ver 6.0. I use this function to copy an ROI from the source image into my destination image. The behavior used to be (using factors of 1.0) exactly what I expected, which is the pixels in the src ROI were copied to the dest ROI. The new behavior is much different. Now I get pixels in the intersection of the src ROI and the dest ROI, and the src ROI is always at the top-left (regardless of where I specify it). Somy dest ROIonly gets the pixels within the ROI near the top-left, and it only gets the intersection of the two. I want the entire ROI.

I tried making the src ROI the entire image, thinking I should get the ROI I want, but I still get the same pixels. I think it limits the src ROI to the step size of the dest image.

The documentation mentions that ROIs in the geometry trannsforms is different, and it mentions you only get the intersection. It also says the origin of the src and the dest must be the same. I don't quite understand this. How do these functions work? What am I missing? Do I supply the pointer to the beginning of the src image or do I supply the pointer to the src ROI? Where can I find more information on these functions? Why was the behavior changed? I expect library functions to continue working as they have for the past six or so years. Now I have to figure this out just to get my software working the same as it did before.

Please help.

-Terry

[Ying_H_Intel]

Hi Terry,

I recalled there issome dicussions regarding this in
http://software.intel.com/en-us/forums/showthread.php?t=65400&o=a&s=lr

You may refer to it.If it is still problem, could youplease provide us a small test code to reproduce the problem?

http://software.intel.com/en-us/articles/accelerate-your-application-via-ipp-image-processing-in-parallel-studio-c-code-vs-ipp-resize/
include a msvc 2005 ippiResizeSqrPixel sample

Kind Regards,
Ying

[Terry_L__Sprout]

Hi Ying,

Thank you for your reply. I read the discussions you provided and it basically answered my question regarding what pointer I pass as the src data pointer. The asnwer is to pass the pointer to the src ROI and not the src image. Now the src ROI and dst ROI have the same origin (which is 0,0). I modified my code accordingly and it worked.

I believe this is a bug in the IPP, however. First of all, why provide an IppiRect structure if all the function will use is the width and height? Second, the ROI pointer will not be 32-byte aligned in most cases.

How are the xShift and yShift arguments used?

I actually read your article regarding accelerating your app using resize before I posted my problem. It didn't help since you were resizing the entire image, so the origins for both the src and dst were naturally 0,0. All the samples I've seen use do the same thing. I haven't seen any samples where the origin is NOT 0,0.

Sincerely,
Terry L. Sprout

[Chao_Y_Intel]

Hi Terry,

I attached a picture with shows the xShift and yShift. In the X coordinate, it shifts 10 pixel, and Y pixel, it shifts 30 pixel.

Thanks,
Chao

[Yuri_Tikhomirov__Int]

Hi Terry,

You wrote:
1. "I believe this is a bug in the IPP, however. First of all, why provide an IppiRect structure if all the function will use is the width and height? Second, the ROI pointer will not be 32-byte aligned in most cases."

It is IPP Geometry API specific: http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/ippxe/ipp_manual_lnx/index.htm#IPPI/ippi_ch12/ch12_Intro.htm#interpolation
Someone wants to perform only part of source image. The possible unaligning of pointer isn't problem, the function will be work right.

2. "How are the xShift and yShift arguments used?"

The resize transform is special case of affinne transform and Shift parameters are for image transition.
Besides, using them, we can begin interpolation withnon-wholesource pixel in fact.

Thanks,
Yuri