ippiResize_8u_C1R not supporting Lanczos 3?

[thtempelmann]

I've been using ippiResize_8u_C1R() to resize a test picture down to 37% of its original size.

The result is rather disappointing:

When using IPPI_INTER_LANCZOS I get the same bad image that I get with IPPI_INTER_LINEAR, though it takes about 4 times as long: ipp-resize-16.png

With IPPI_INTER_SUPER I get a somewhat OK picture, at least, although it's pretty slow (my own SSE code using the same algo is about 5 times faster): ipp-resize-8.png

I really want to get a good quality result, though, based on Lanczos 3, as seen here: lanczos3.png

Are there any known limitations that explain why IPPI_INTER_LANCZOS does not give the expected quality?

I am using the IPP lib delivered with the OS X version of the compiler package v11.0.059, testing on a 8-core Xeon Mac Pro.

[Vladimir_Dudnik]

Hello,

the ippiResize function will be deprecated in future releases. We recommend you to use ippiResizeSqrPixel function which do support lanczos interpolation.

Regards,
Vladimir

[thtempelmann]

Quoting - Vladimir Dudnik (Intel)

the ippiResize function will be deprecated in future releases. We recommend you to use ippiResizeSqrPixel function which do support lanczos interpolation.

I've tried theippiResizeSqrPixelfunction instead ofippiResize, adding a tmpbuf and zeros for the shift values.

I can see that this enables theCUBIC2P interpolations that the older function did not support, but the Lanczos image still comes out with unsatisfying quality, just as I've shown in my previous post: The picture is about the same as the one I get fromIPPI_INTER_CUBIC.

This still doesn't look right.

[Vladimir_Dudnik]

Could you please provide your test case and source image, so we can look carefully if everything is ok with how you call the function?

Regards,
Vladimir

[thtempelmann]

Quoting - Vladimir Dudnik (Intel)

Could you please provide your test case and source image, so we can look carefully if everything is ok with how you call the function?

I tried out the example provided in Vol2 of the IPP manual and found that it all works as intended by Intel: I get the results as described. So there's no reason to suspect I'm calling it in a wrong way. Plus, the parameters are straight-forward, what can be done wrong there that would lead to sensible results that just provide unsatisfying interpolation results? The code I have here is woven into quite a complex app, and unless you can hint at possible errors I could make, I find it a waste of time to turn it into a demo app that I can send you to try it out yourself - please don't take offense at that.

It's rather obvious to me that the Lanczos algo used by the Resize functions is the culprit here - it apears inferior to the one Apple provides in their vImage lib. Theirs provides a great result where there are hardly any interference patterns where Intel's shows them pretty badly, as shown in the sample images I linked to in my first post.

Here's the original image:http://www.tempel.org/pmwiki/uploads/Main/ImageScalingComparison/orig-fullsize.png

If I scale that down to any factor < 1 (same factor for X and Y), using Lanczos, I see the interference patterns. If I let my browser (Safari 3 on OSX) or Apple's vImage scaler make it smaller, those patterns hardly show, just as it's expected from a Lanczos filter. Are you sure you'd be able to get similar good results with IPP's resize function? Are there any examples to look at?

(I'd like to send you some confidential infos, that I don't want to post publically, but I cannot figure out how to do that here)

[Vladimir_Dudnik]

Thanks for explanation, I just worried about simple test case which engineers can look through immediately rather than re-create resizing application with some assumptions.

I notified Technical Support people who will contact with you directly.

Regards,
Vladimir

[thtempelmann]

Quoting - Vladimir Dudnik (Intel)

I notified Technical Support people who will contact with you directly.

Thank you. Your help is much appreciated. I'm happy to provide some sample code should there be a chance that someone takes a closer look at the issue.