1 | initial version |

A few suggestions to improve performance are:

select a smaller number of keypoints - let's say 80% of the best ones. Less points to fit, higher the speed. Note also that RANSAC processing time is highly dependent on the quality of the points. If 95% of them are good, it can be 100 times faster than if 60% of them are good. Rejecting from start the ones that seem unfit may help.

fork OpenCV adn rewrite the findHomography internal stuff to work with

`floats`

, instead of`doubles`

(modules/calib32/src/fundam.cpp).`double`

is a killer on mobile platforms. Also, compile OpenCV with`-ffast-math`

to speedup floating point operations. Note that although these changes will likely decrease calculation accuracy, the chance for you to be affected is close to 0.profile the function and see where the most time is spent. If it is the solvePoly function, or a similar polynomial solver, you can speed it up enormously by implementing your own solver, based on Vandermonde matrix properties. Check out this ol' good book by Golub for a reference algorithm

Finally, try to use NEON in your implementation. Check this post for a bit more info (paragraph

**E**): http://answers.opencv.org/question/755/object-detection-slow/#760

2 | No.2 Revision |

A few suggestions to improve performance are:

select a smaller number of keypoints - let's say 80% of the best ones. Less points to fit, higher the speed. Note also that RANSAC processing time is highly dependent on the quality of the points. If 95% of them are good, it can be 100 times faster than if 60% of them are good. Rejecting from start the ones that seem unfit may help.

fork OpenCV

~~adn~~and rewrite the findHomography internal stuff to work with`floats`

, instead of`doubles`

(modules/calib32/src/fundam.cpp).`double`

is a killer on mobile platforms. Also, compile OpenCV with`-ffast-math`

to speedup floating point operations. Note that although these changes will likely decrease calculation accuracy, the chance for you to be affected is close to 0.profile the function and see where the most time is spent. If it is the solvePoly function, or a similar polynomial solver, you can speed it up enormously by implementing your own solver, based on Vandermonde matrix properties. Check out this ol' good book by Golub for a reference algorithm

Finally, try to use NEON in your implementation. Check this post for a bit more info (paragraph

**E**): http://answers.opencv.org/question/755/object-detection-slow/#760

3 | No.3 Revision |

A few suggestions to improve performance are:

select a smaller number of keypoints - let's say 80% of the best ones. Less points to fit, higher the speed. Note also that RANSAC processing time is highly dependent on the quality of the points. If 95% of them are good, it can be 100 times faster than if 60% of them are good. Rejecting from start the ones that seem unfit may help.

fork OpenCV and rewrite the findHomography internal stuff to work with

`floats`

, instead of`doubles`

(modules/calib32/src/fundam.cpp).`double`

is a killer on mobile platforms. Also, compile OpenCV with`-ffast-math`

to speedup floating point operations. Note that although these changes will likely decrease~~calculation~~accuracy, the~~chance for you to be affected is~~effects are minimal or close to 0.profile the function and see where the most time is spent. If it is the solvePoly function, or a similar polynomial solver, you can speed it up enormously by implementing your own solver, based on Vandermonde matrix properties. Check out this ol' good book by Golub for a reference algorithm

Finally, try to use NEON in your implementation. Check this post for a bit more info (paragraph

**E**): http://answers.opencv.org/question/755/object-detection-slow/#760

4 | No.4 Revision |

A few suggestions to improve performance are:

fork OpenCV and rewrite the findHomography internal stuff to work with

`floats`

, instead of`doubles`

(modules/calib32/src/fundam.cpp).`double`

is a killer on mobile platforms. Also, compile OpenCV with`-ffast-math`

to speedup floating point operations. Note that although these changes will likely decrease accuracy, the effects are minimal or close to~~0.~~0. I expect conversion from`double`

to`float`

to be more effective than the compilation flag, although more complicated.**E**): http://answers.opencv.org/question/755/object-detection-slow/#760

Copyright OpenCV foundation, 2012-2018. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.