如何加快我的Android-openCV应用程序的速度? [英] How can I speed Up my Android-openCV application?
问题描述
我在使用SURF描述符的地方实现了openCV应用程序.代码工作正常，如下所示:
我减小输入视频流的大小以加快速度
capture.set(Highgui.CV_CAP_PROP_FRAME_WIDTH, display.getWidth());
capture.set(Highgui.CV_CAP_PROP_FRAME_HEIGHT, display.getHeight());
capture.retrieve(mRgba, Highgui.CV_CAP_ANDROID_COLOR_FRAME_RGBA);
try{
//-- Step 1: Detect the keypoints using SURF Detector
surfDetector.detect( mRgba, vector1 );
for (KeyPoint t : vector1)
Core.circle(mRgba, t.pt, 10, new Scalar(100, 100,100));
//-- Step 2: Calculate descriptors (feature vectors)
//extractor.compute(mRgba, vector1, descriptor1);
//-- Draw matches
//Mat img_matches;
//drawMatches( mRgba, vector1, mRgba, vector1, matches, img_matches );
}catch(Exception e){
Log.e( "ERROR", e.toString());
}
但是计算仍然太慢，因此我需要找到另一种降低输入视频流质量的方法.或者，如果您知道另一种加快速度的方法，请随时与我分享；)
感谢您的时间&答案
但是计算仍然太慢，所以我需要找到另一个 降低输入视频流质量的方法.
该问题的真正答案更接近您无能为力！"比其他任何事情都重要.我们必须承认，手机还没有任何台式机那样强大的处理能力.世界上大多数Android手机仍在使用该系统的早期版本，而最重要的是:它们是单核设备，时钟频率低于1GHz，内存有限，等等.
尽管如此，总会有一些事情可以做，而在性能上几乎没有变化，可以提高速度.
现在，我还在GalaxyS上计算OpenCV SURF，在320x240的图像中，我对200个功能的帧速率为1.5 fps，而粗麻线阈值为1500.我承认这是糟糕的性能，但就我而言，我只是偶尔需要计算一次特征，因为我正在测量光流以进行跟踪.但是，非常奇怪的是，每4-5秒只能获得1帧.
1)首先，在我看来，您正在使用VideoCapture获取摄像机帧.好吧，我不是.我正在使用Android相机实现.我没有检查如何在OpenCV的Java端口中实现VideoCapture，但它似乎比某些教程中的实现要慢.但是，由于我没有测试过，因此我不能百分百确定.是吗?
2)将本机呼叫减少到最小. Java OpenCV本机调用非常耗时.另外，请遵循 Android-OpenCV最佳做法页面中指定的所有准则. .如果您有多个本地调用，请将它们全部合并到一个JNI调用中.
3)您还应该减小图像尺寸并增加SURF粗略阈值.但是，这将减少检测到的特征的数量，但是出于识别和匹配的目的，它们将变得更强大，更强大.如果您说SURF是更强大的检测器(它也是最慢的，并且已申请专利)，那您是对的.但是，如果这不是您的死锁，我建议您使用新的ORB检测器，它是Brief的一种变体，在旋转方面表现更好.但是，ORB有一些缺点，例如，检测到的关键点数量有限并且缩放不变性很差. 这是一个非常有趣的特征检测器算法比较报告.这也表明，SURF检测器在新的OpenCV 2.3.1版本中速度较慢，这可能是由于算法的某些更改而导致的，从而提高了鲁棒性.
4)现在，有趣的地方.已经广泛报道了ARM处理器体系结构(大多数Android手机都基于该处理器)，因为它处理浮点计算的速度较慢，而功能检测器算法在很大程度上依赖于该算法.已经有非常有趣的讨论关于此问题，许多人说您应该尽可能使用定点计算.新的armv7-neon架构提供了更快的浮点计算，但并非所有设备都支持它.要检查您的设备是否支持它，请运行adb shell cat proc/cpuinfo.您还可以使用NEON指令(LOCAL_ARM_NEON := true)来编译本机代码，但是我怀疑这样做是否有好处，因为显然很少有OpenCV例程是经过NEON优化的.因此，提高速度的唯一方法是使用NEON内在函数重建代码(这对我来说是完全未开发的基础，但是您可能会发现它值得一看).在android.opencv组中建议未来的OpenCV版本将具有更多NEON优化的库.这可能很有趣，但是我不确定是否值得为此工作或等待更快的CPU和使用GPU计算的优化系统.请注意，Android系统< 3.0 请勿使用内置的硬件加速
5)如果您出于学术目的而这样做，请说服您的大学为您购买更好的设备^^.最终，这可能是更快进行SURF功能检测的最佳选择.另一种选择是重写算法.我知道英特尔实验室中的一些人做到了，但取得了一些成功，但是显然他们不会分享. 坦率地说，在调查了这个问题几周后，我意识到，对于我的特定需求(并且由于我既不是计算机科学工程师也不是算法专家)，等待几个月才能获得更好的设备比敲击我的头有更多的价值.在墙上剖析算法并开发近汇编代码.
最诚挚的问候和好运！
I have implemented an openCV applicationWhere I use SURF descriptor. It is working fine the code looks like this:
I reduce the input video stream size to speed it up
capture.set(Highgui.CV_CAP_PROP_FRAME_WIDTH, display.getWidth());
capture.set(Highgui.CV_CAP_PROP_FRAME_HEIGHT, display.getHeight());
capture.retrieve(mRgba, Highgui.CV_CAP_ANDROID_COLOR_FRAME_RGBA);
try{
//-- Step 1: Detect the keypoints using SURF Detector
surfDetector.detect( mRgba, vector1 );
for (KeyPoint t : vector1)
Core.circle(mRgba, t.pt, 10, new Scalar(100, 100,100));
//-- Step 2: Calculate descriptors (feature vectors)
//extractor.compute(mRgba, vector1, descriptor1);
//-- Draw matches
//Mat img_matches;
//drawMatches( mRgba, vector1, mRgba, vector1, matches, img_matches );
}catch(Exception e){
Log.e( "ERROR", e.toString());
}
But the calculation is still way too slow, so I need to find another method to reduce input video stream qualllity. Or If you know another method to speed it up feel free to share it with me ;)
Thanks for your time & answers
But the calculation is still way too slow, so I need to find another method to reduce input video stream qualllity.
The real answer to this question is much closer to "there isn't much you can do!" than to anything else. We have to acknowledge that mobile phones do not have yet strong processing capabilities like any desktop. The majority of Android phones in the world are still using previous versions of the system and most important of all: they are single-core devices, they are clocked at speeds lower than 1GHz, they have limited memory, bla bla...
Nevertheless, there is always something you can do to improve speed with little changes in performance.
Now, I am also computing OpenCV SURF on the GalaxyS and I have a frame rate of 1.5 fps for 200 features with hessian threshold at 1500 in a 320x240 image. I admit it is crappy performance, but in my case I only have to compute features every once in a while, since I am measuring optical flow for tracking purposes. However, it is very weird that you can only get only 1 frame every 4-5 seconds.
1) First, it seems to me that you are using VideoCapture to obtain the camera frames. Well, I am not. I am using the Android camera implementation. I did not check how VideoCapture is implemented in the Java port of OpenCV, but it appears to be slower than using the implementation in some of the tutorials. However, I can't be 100% sure about this, since I haven't tested it. Did you?
2) Reduce native calls to the minimum possible. Java OpenCV native calls are time-expensive. Also, follow all the guidelines specified in the Android-OpenCV best practices page. If you have multiple native calls, join them all in a single JNI call.
3) You should also reduce the image size and increase the SURF hessian threshold. This will, however, reduce the number of detected features, but they will be stronger and more robust for the purpose of recognition and matching. You are right when you say that the SURF is the more robust detector (it also is the slowest, and it is patented). But, if this is not a dead lock for you, I would recommend to use the new ORB detector, a variant of BRIEF which performs better in terms of rotation. ORB has disadvantages though, such as the limited number of detected keypoints and bad scale-invariance. This is a very interesting feature detector algorithms comparison report. It also suggests SURF detector is slower in the new OpenCV 2.3.1 version, probably due to some changes in the algorithm, for increased robustness.
4) Now the fun bits. The ARM processor architecture (in which most of the Android phones are based) has been widely reported for its slowness handling floating point calculations, in which feature detector algorithms rely heavily. There have been very interesting discussions about this issue, and many say you should use fixed-point calculations whenever possible. The new armv7-neon architecture provides faster floating point calculations, but not all devices support it. To check if your device does support it, run adb shell cat proc/cpuinfo. You can also compile your native code with NEON directives (LOCAL_ARM_NEON := true) but I doubt this will do any good, since apparently few OpenCV routines are NEON optimized. So, the only way to increase speed with this, is to rebuild the code with NEON intrinsics (this is completely unexplored ground for me, but you might find it worth looking). In the android.opencv group it was suggested that future OpenCV releases will have more NEON-optimized libraries. This could be interesting, however I am not sure if it is worth working on it or wait for faster CPUs and optimized systems using GPU computing. Note that Android systems < 3.0 do not use built-in hardware acceleration.
5) If you are doing this for academic purposes, convince your university to buy you a better device ^^. This might ultimately be the best option for faster SURF feature detection. Another option is to rewrite the algorithms. I am aware some guys in the Intel labs did it, with some success but, obviously they won't share it. Honestly, after investigating this issue for a few weeks, I realised that for my specific needs, (and since I am no computer science engineer nor an algorithms expert) there is more value on waiting a few months for better devices, than banging my head on the wall dissecting the algorithms and developing near-assembly code.
Best regards and good luck!
这篇关于如何加快我的Android-openCV应用程序的速度?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
