arm板（ti5728）匹配速度问题

[laidongd]

系统：Linux version 4.14.79-rt47-ga72bf1418c ，平台：arm板（ti5728），图片尺寸：1280*1024灰度图，生成模板数为360个，单纯匹配花费时间3~4秒，若将模板数减少为120个，匹配时间并未明显减少，大概减少了零点几秒。生成模板是在window7做的，360个模板需要花费几十秒。请问是哪里设置的不对吗？arm板 MIPP test结果：

cmake设置情况：

[laidongd]

修改编译选项，在windows下的匹配速度可以达到200ms左右，生成模板也比较快，但在arm板上匹配时间就是需要耗时3~4秒，

[meiqua]

匹配时间没有随着模板量线性减少，可能是openmp不能用？把openmp关掉看看

[laidongd]

请问是这样关闭openmp吗？关闭后没什么变化
SET(PLATFORM_COMPILE_FLAGS "-mfpu=neon")
SET(PLATFORM_COMPILE_FLAGS "-DMIPP_NO_INTRINSICS") # close SIMD
SET(COMMON_COMPILE_FLAGS " -Wall -Wno-sign-compare")#-fopenmp
#SET(CMAKE_CXX_FLAGS "${PLATFORM_COMPILE_FLAGS} ${COMMON_COMPILE_FLAGS} $ENV{CXXFLAGS}")
#SET(CMAKE_CXX_FLAGS_DEBUG "-O0 -g2 -ggdb")
SET(CMAKE_CXX_FLAGS_RELEASE "-O3")

[meiqua]

直接注释这一行

[laidongd]

结果差不多，也是3秒多。如果需要做一些测试验证，我这边可以配合

[meiqua]

是匹配还是response map要3秒

[laidongd]

construct response map
elasped time:2.35164s
templ match
elasped time:0.763031s

[meiqua]

用opencv做一次sobel要多久？

[laidongd]

执行十次sobel花费0.7s左右，图片尺寸1280*1024

[meiqua]

按我理解response map耗时应该跟10次sobel差不多。可以测下这个函数里每个opencv函数跑的时间，有可能是某个opencv函数特别耗时？

[laidongd]

主要时间花费在quantizedOrientations函数的执行，共执行了两次这个函数，
第一次为ColorGradientPyramid的构造函数中，花费时间如下：
GaussianBlur：0.46435s
Sobel(smoothed, sobel_dx, CV_32F, 1, 0, 3, 1.0, 0.0, BORDER_REPLICATE); //0.13009s
Sobel(smoothed, sobel_dy, CV_32F, 0, 1, 3, 1.0, 0.0, BORDER_REPLICATE); //0.123046s
magnitude = sobel_dx.mul(sobel_dx) + sobel_dy.mul(sobel_dy); //0.237372s
phase(sobel_dx, sobel_dy, sobel_ag, true); //0.152012s
hysteresisGradient(magnitude, angle, sobel_ag, threshold * threshold);//0.179996s
第二次为降采样pyrDown后，执行该函数，所有步骤的执行时间大概为之前的四分之一

[meiqua]

从这里看得出来差不多是10次float sobel，估计是这个板子浮点数运算性能低？

[meiqua]

简单的改法是省省用，把GaussianBlur改Blur，CV_32F改CV_32S，后面都跟着float改int，不太确定phase能不能输出int型。也可以试试这个方法，不过要改的可能比较复杂。

[laidongd]

好的，我尝试一下，不过速度提升应该会比较有限。
能否请教大佬一个问题，在工业上检测零件缺陷，或者测量零件上两部分的间距，因为零件会动，往往需要进行位置和角度的补正，我看一些图像处理软件的做法是：选取参考图像上的某一部分作为参照基准，生成模板，根据该基准模板获取其他图片中零件的相对偏移和旋转，如下图所示，绿色框住的部分就是选取的基准，在windows平台，处理360度的匹配用时仅20ms，不过鲁棒性没有你这个算法好，不知道他们用的是什么算法，不知您对这方面是否有所了解。

[DennisLiu-elogic]

@laidongd
受惠於meiqua許多，讓我替他回答下

我參考過許多工業用函式庫，Halcon(德國)、Cognex(美國、所屬公司及客戶曾經採用)、Euresys(歐洲..?，朋友公司是用這家做檢測)、光道(台灣廠商，目前所屬公司採用)、MIM(台灣新興廠商，台北科技大學教授創立)
就我所知，除了Halcon、Congnex有Shape Based Matching外，其他廠牌用的是NCC (normalized cross correlation)匹配。
NCC公式簡單，實現也容易，但精度比起SBM較低，但要達到這些廠商的水平，勢必得加上金字塔、SIMD以及搜尋策略，搜尋策略要寫的高效是個難題。
我是意外跨領域到電腦視覺的新手，交流交流

[laidongd]

@DennisLiu-elogic ，谢谢你的解答。
ncc的策略我有用过，匹配360度的模板的话，在我的虚拟机里都需要十几秒，ncc采用的是滑动模板匹配的策略，还需要对每个patch进行归一化，逐一计算模板中的所有像素，计算量比题主这个根据梯度提取特征点的方法计算量大太多了。
上面说的是对应opencv的matchTemplate函数，但我看有些人使用matchShapes来匹配轮廓，速度很快，但稳定性似乎不太好

[DennisLiu-elogic]

@laidongd
形狀匹配的精隨在於梯度的操作，不是形狀本身 (形心、重心、矩...等)，matchShape估計是沒用的
以matchShape當關鍵字去找也會發現都是基礎的教學文章

你使用matchTemplate會這麼慢估計是沒有用金字塔，每次SourceImg(大圖)傳進去都做一次fft
使用NCC分為兩種流程 : 1. 旋轉來源 2. 旋轉樣板
若你使用2，可以改下opencv的source code，大圖只做一次fft，省了359次fft (source)的時間

[laidongd]

受教了，谢谢二位大佬。@meiqua @DennisLiu-elogic

[LvMeng01]

@laidongd
受惠於meiqua許多，讓我替他回答下

我參考過許多工業用函式庫，Halcon(德國)、Cognex(美國、所屬公司及客戶曾經採用)、Euresys(歐洲..?，朋友公司是用這家做檢測)、光道(台灣廠商，目前所屬公司採用)、MIM(台灣新興廠商，台北科技大學教授創立)
就我所知，除了Halcon、Congnex有Shape Based Matching外，其他廠牌用的是NCC (normalized cross correlation)匹配。
NCC公式簡單，實現也容易，但精度比起SBM較低，但要達到這些廠商的水平，勢必得加上金字塔、SIMD以及搜尋策略，搜尋策略要寫的高效是個難題。
我是意外跨領域到電腦視覺的新手，交流交流

金字塔的目的是让模板匹配算法具有尺度不变性？

[meiqua]

@LvMeng01 不是，用来提升速度

[LvMeng01]

@LvMeng01 不是，用来提升速度

懂了！先在小尺度上面找到大致位置，然后在精确位置！

[DennisLiu-elogic]

@LvMeng01 不是，用来提升速度

懂了！先在小尺度上面找到大致位置，然后在精确位置！

尺度不變也必須結合金字塔使用，否則多一個scale耗時就增加一倍，太慢了

[LvMeng01]

@LvMeng01 不是，用来提升速度

懂了！先在小尺度上面找到大致位置，然后在精确位置！

尺度不變也必須結合金字塔使用，否則多一個scale耗時就增加一倍，太慢了

谢谢，解惑

[LvMeng01]

@DennisLiu-elogic @meiqua
日常使用时，发现一个问题，为什么模板匹配在降采样后，能寻找到目标的概率增加了呢？
或者说，100100的模板，在10001000的样本上寻找目标，若是同时降采样5倍，能找到目标的概率增加，并且得分也增加了！
或许，我形容的不太准备，抱歉了

[meiqua]

@LvMeng01 正常的，因为目标变小，orientation spread不变，可容忍的变形就相对大了，得分会变高

[LvMeng01]

@DennisLiu-elogic ，谢谢你的解答。
ncc的策略我有用过，匹配360度的模板的话，在我的虚拟机里都需要十几秒，ncc采用的是滑动模板匹配的策略，还需要对每个patch进行归一化，逐一计算模板中的所有像素，计算量比题主这个根据梯度提取特征点的方法计算量大太多了。
上面说的是对应opencv的matchTemplate函数，但我看有些人使用matchShapes来匹配轮廓，速度很快，但稳定性似乎不太好

您好，ShapeMatching的精髓是图像梯度信息，opencv中matchTemplate借助的图像像素点信息，从稳定性的角度那个算法更好一点？

[meiqua]

梯度稳定性会好一点，因为梯度信息量多一些