Slow ippiDistance

Slow ippiDistance

Why ippiDistance is so slow?

For theChebyshev metric,my straightfoward C++ implementation easily outperforms ippiDistance and gives the same result.... The only difference is that output of my "Distance Transform" is "Ipp8u" with saturation to 255 (this saturation limit israrely reached in practice). But ippiDistance's output is "Ipp32f", which, IMO, is an overkill for most popular metrics.

Message Edited by karabas on 05-12-2004 10:17 AM

6 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

Could you please add slightly more details?

What exactly function name, and what is your environment (processor, OS), what was the conditions forcomparison?


CPU: Pentium 4 with 512MB DDR400 (IPP v4.0 detects the CPU as ippCpuP4HT), Windows 2000

Function name: ippiDistanceTransform_3x3_8u32f_C1R Type of distance: "30" - 3x3 aperture for infinify norm.

Image size: 1376x1030.This black and white image contains around 200 30x30 good objects and lots of small noise objects.

I guess the reason why IPP version is slower is that it uses additional memory buffer, which is 4 times larger than the image itself and also requires integer to FP conversion.

While I perform C++ distance transform in-place. Naturally, Id like to request in-place version of Distance Transform. The difference in speed is not dramatic and can be explained by the reasons mentioned above. So in fact this is not a bug and, as you recommended, I will probably forward this to Technical Support as a feature request.


I consulted with developers, they tell this function has no strong optimization yet, but we have plan to improve performance of this function. Also, we are interested to know, what is more preferable from your point of view, to have 8u or 16u data for this function?

I think your suggestion to have in-place function is good, so please do not forget to submit this feature request.


> what is more preferable from your point of view, to have 8u or 16u data for this function?

I think more peopleneed 8u version than 16u, since objects whose size is more than 512 pixels are quite rare in practice at this point.

Butas typical image size and resoltiongrow(thanks to advances in vision hardware)16u output may become more important....

Anyway,it would be good to have both 8u and 16u for completness...

Message Edited by karabas on 05-14-2004 11:05 AM

Thank you, I will bring your info to our developers.


Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi