This forum is disabled, please visit https://forum.opencv.org
 | 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:
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 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.
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
