簡介面向機器視覺初學者與C桌面開發(fā)者的halconmfc模板匹配demo聚焦在Windows界面中完成基于形狀、形狀縮放與灰度的模板匹配驗證。工程把Halcon圖像處理能力嵌入MFC對話框提供圖像加載、匹配模式選擇、參數(shù)設置、執(zhí)行匹配及位置與相似度結(jié)果展示等交互適合學習工業(yè)視覺定位、目標識別與GUI集成的基礎流程。壓縮包共27個文件以8個h和6個cpp源碼為主配合ico、rc等界面資源vcxproj、sln等VS工程配置以及jpg預覽圖、exe可執(zhí)行程序和說明文檔rar整體約11.45MB。從目錄模塊看參數(shù)設置、形狀操作、結(jié)果封裝與主對話框邏輯劃分較清晰便于對照編譯、調(diào)試和二次修改。已有1246人學習可作為Halcon與MFC聯(lián)合開發(fā)模板匹配功能的入門參考。1. 一個能雙擊運行的 exe這個 HalconMFC 模板匹配 demo 到底解決什么問題某五金件產(chǎn)線上工件在傳送帶上隨機偏轉(zhuǎn)角度大概在正負十五度之間晃機械手要過去抓。算法同事在 HDevelop 里半小時就調(diào)通了create_shape_model建模板、find_shape_model拿 Row/Column/Angle 一氣呵成?？烧嬉桓兜焦の徊僮鞴げ豢赡艽蜷_ HDevelop 點運行。問題于是從“怎么匹配”變成“怎么把匹配包成一個能雙擊的 exe”——這正是 Halcon MFC 模板匹配 demo 的位置。它做的事很具體把形狀匹配的建模、查找、結(jié)果顯示、參數(shù)調(diào)節(jié)塞進一個 MFC 對話框程序里對外輸出一個四元組Row、Column、Angle、Score再把匹配到的輪廓疊畫在圖上。適合做課設畢設的、剛從腳本過渡到上位機的、以及要給現(xiàn)場交付獨立程序的人如果你只做純算法研究或者習慣 Python 調(diào)庫這套東西對你價值不大。2. 工程骨架把 Halcon 算子塞進 MFC 的三條路與一次編譯配置2.1 HDevEngine、導出 C、混合調(diào)用先選一條這一步選錯了后面全是返工。三種接法我都在項目里用過差別不在性能在“誰改算法”這件事上。接法做法優(yōu)點代價適合HDevEngine運行時加載 .hdev用HDevEngine執(zhí)行過程算法同事改腳本不用重編 exe多帶一個引擎 dll報錯是腳本行號每次調(diào)用有解析開銷算法還在頻繁迭代、現(xiàn)場要臨時調(diào)參導出 CHDevelop 里“文件→導出 C”生成 .cpp執(zhí)行最快無額外依賴改一行腳本就要重新編譯整個工程算法已經(jīng)凍結(jié)、追求穩(wěn)定交付混合建模和調(diào)參走腳本查找和結(jié)果顯示走 C兼顧兩邊接口要自己設計狀態(tài)要管好我一般會選這個Demo 這種體量直接導出 C 最省事因為模板匹配的調(diào)用鏈很短沒必要為它背一個腳本引擎。但如果你要做“現(xiàn)場工程師拿著 hdev 自己調(diào)對比度”的功能那就得走 HDevEngine并且把腳本里的過程名、輸入輸出參數(shù)用SetProcedure、SetInputIconicParamObject這類接口約定死否則腳本一改接口exe 直接報找不到過程。2.2 VS 工程配置位數(shù)、運行時庫、頭文件順序Halcon 的庫和你的工程必須位數(shù)一致這一條沒有例外。新版本基本只提供 64 位所以 MFC 工程從新建那一刻就該選 x64別等編譯報一堆LNK2019再回頭改。屬性頁里要落的東西位置項值C/C → 常規(guī)附加包含目錄$(HALCONROOT)\include、$(HALCONROOT)\include\halconcpp鏈接器 → 常規(guī)附加庫目錄$(HALCONROOT)\lib\$(HALCONARCH)鏈接器 → 輸入附加依賴項halconcpp.libC/C → 代碼生成運行時庫與 Halcon 保持一致一般/MDRelease、/MDdDebugMFC 使用方式—在共享 DLL 中使用 MFCHALCONROOT和HALCONARCH這兩個環(huán)境變量是安裝時寫進系統(tǒng)的用$(HALCONROOT)引用比自己寫死路徑靠譜換機器不用改工程。頭文件包含順序上有一個老坑windows.h里的min/max宏會和標準庫打架而 MFC 又必然帶進windows.h// pch.h或 stdafx.h里包含順序不要隨意調(diào)換 #define NOMINMAX // 擋掉 windows.h 的 min/max 宏 #include windows.h #include atlconv.h // 后面要用 CT2A 做編碼轉(zhuǎn)換 #include halconcpp/HalconCpp.h // 放在 windows.h 之后避免類型重定義 using namespace HalconCpp; // 只在 cpp 里用別寫進頭文件污染全局NOMINMAX不加std::min之類的調(diào)用會莫名其妙編譯不過using namespace寫進頭文件則會讓所有包含它的 cpp 都被拖進 Halcon 的命名空間后面和 MFC 的CRect、CPoint撞名是遲早的事。部署時別忘了把運行時 dll 拷到 exe 同級目錄halcon.dll、halconcpp.dll是必須的走 HDevEngine 還要加引擎那個 dll。我在項目里放了個拷貝腳本打包前一鍵執(zhí)行# 打包前把運行時 dll 拉到輸出目錄避免現(xiàn)場機器裝沒裝 Halcon 的玄學問題 OUTbin/Release HALCON_BIN$HALCONROOT/bin/$HALCONARCH cp $HALCON_BIN/halcon.dll $OUT/ cp $HALCON_BIN/halconcpp.dll $OUT/ # 只有用 HDevEngine 才需要下面這兩個 # cp $HALCON_BIN/hdevenginecpp.dll $OUT/ # cp $HALCON_BIN/hdevengine.dll $OUT/腳本本身沒什么技術含量價值在于把“哪些 dll 是必需的”這件事固化下來?，F(xiàn)場機器往往裝的是運行版而不是開發(fā)版多拷一個 dll 頂多占幾兆少拷一個就是啟動即崩。2.3 線程模型UI 線程只負責畫算子跑在工作線程MFC 的死穴是 UI 線程不能阻塞超過幾十毫秒而一次find_shape_model在高分辨率圖、多角度、多層金字塔的情況下跑到幾十甚至上百毫秒很常見。連續(xù)采圖時直接在OnBnClickedStart里循環(huán)調(diào)用界面必卡任務管理器里那個“未響應”的標題就是血淚經(jīng)驗。更麻煩的是 Halcon 窗口有線程親和性OpenWindow在哪個線程開的就只能在哪個線程操作它?？缇€程去DispObj輕則不顯示重則直接崩。我一般這么切// 自定義消息工作線程算完把結(jié)果丟回 UI 線程去顯示 #define WM_MATCH_RESULT (WM_USER 100) UINT CMatchDemoDlg::MatchThreadProc(LPVOID pParam) { CMatchDemoDlg* pDlg static_castCMatchDemoDlg*(pParam); HObject ho_Image; HTuple hv_Row, hv_Column, hv_Angle, hv_Score; while (pDlg-m_bRunning) { try { // 1. 取圖這里換成你的相機采集或文件讀取 ReadImage(ho_Image, HTuple(data/part_01.png)); // 2. 匹配hv_ModelID 在 UI 線程建好后傳進來建一次用一輩子 FindShapeModel(ho_Image, pDlg-m_hvModelID, HTuple(-15).TupleRad(), HTuple(30).TupleRad(), 0.6, 1, 0.5, least_squares, 0, 0.8, hv_Row, hv_Column, hv_Angle, hv_Score); // 3. 只傳結(jié)果和圖像句柄不碰任何窗口 pDlg-m_hoLastImage ho_Image; // HObject 是引用計數(shù)賦值是安全的 pDlg-PostMessage(WM_MATCH_RESULT, 0, 0); } catch (HException ex) { // Halcon 異常必須接住否則線程直接終止 pDlg-PostMessage(WM_MATCH_RESULT, 1, 0); } Sleep(10); } return 0; }這段的關鍵點有三個FindShapeModel的NumLevels傳 0 表示用建模時定好的層數(shù)不要在這里另設一個值SubPixel選least_squares比interpolation穩(wěn)代價是慢一點點HObject的賦值是淺拷貝加引用計數(shù)所以把圖像存到對話框成員上不會帶來一次完整的內(nèi)存拷貝但也意味著你在工作線程里對同一個ho_Image再ReadImage一次主線程正在顯示的那張會跟著變——想要每幀獨立就CopyObj一份。UI 線程那邊只做三件事接消息、DispObj、畫十字和矩形框。這樣即使匹配跑到 200 毫秒界面拖動、縮放依然跟手。3. 模板訓練與查找參數(shù)八個建模參數(shù)和四個查找參數(shù)怎么定3.1create_shape_model的參數(shù)一個個說清楚形狀匹配的建模參數(shù)直接決定“能不能找到”查找參數(shù)只決定“找得多準”。順序別搞反。參數(shù)含義常用取值調(diào)錯的表現(xiàn)NumLevels金字塔層數(shù)auto或 06太大丟小特征太小慢AngleStart起始角弧度按工件實際偏轉(zhuǎn)定范圍不夠直接找不到AngleExtent角度跨度弧度同上同上AngleStep角度步長弧度auto或按半徑算太粗定位抖太細建模慢Optimization模板點優(yōu)化方式auto、point_reduction_high高優(yōu)化會犧牲一點點精度Metric極性use_polarity光照反了就全丟Contrast邊緣對比度閾值auto或 2060太高模板點太少MinContrast查找時最低對比度建模值的 1/21/3太高現(xiàn)場找不到Metric這個參數(shù)是最容易被忽略的。默認use_polarity要求待查圖像里邊緣的明暗方向和模板一致如果現(xiàn)場打光方式變了或者工件翻面邊緣極性反了score 會直接掉到 0.1 以下你還以為是角度范圍設小了。另一種是ignore_local_polarity允許局部極性變化魯棒性更好但誤匹配率上升我在有反光鋁件上用過得配合提高MinScore一起用。// 建模先框 ROI再做域縮減最后建形狀模板 HObject ho_ModelRegion, ho_ModelImage; GenRectangle1(ho_ModelRegion, 120.0, 200.0, 380.0, 460.0); // 行1,列1,行2,列2 ReduceDomain(ho_Image, ho_ModelRegion, ho_ModelImage); // 只在 ROI 內(nèi)取邊緣 HTuple hv_ModelID; CreateShapeModel(ho_ModelImage, HTuple(0), // NumLevels0讓 Halcon 自己定 HTuple(-15).TupleRad(), // AngleStart注意單位是弧度 HTuple(30).TupleRad(), // AngleExtent覆蓋 -15°~15° HTuple(auto), // AngleStep HTuple(auto), // Optimization HTuple(use_polarity), // Metric HTuple(auto), // Contrast HTuple(25), // MinContrast現(xiàn)場光照波動大就調(diào)小 hv_ModelID);ReduceDomain這一步不能省。整幅圖去建模板背景里的傳送帶紋路、料盤邊緣全會被當成特征點模板點數(shù)暴漲建模慢、查找更慢而且容易在背景相似的地方誤匹配。ROI 盡量貼著工件外輪廓留 510 像素余量。MinContrast單列出來說是因為它決定了“現(xiàn)場能不能找到”。建模時的Contrast是按當前這張圖的對比度自動算的換一批料、換一個班次的光照對比度可能掉三成。這時候MinContrast如果還等于建模值那些邊緣就被過濾掉模板點剩不下幾個。我一般把它壓到Contrast的三分之一左右寧可多留點噪聲點也別讓模板變成空殼。3.2 金字塔層數(shù)和角度步長不要讓auto替你做決定auto在大多數(shù)場景下是合理的但它有個隱含前提——你的模板 ROI 大小適中。ROI 特別大比如 800×600 的整塊鈑金時auto給出的層數(shù)會偏高最頂層只剩幾十個點粗定位直接飄ROI 特別小比如 30×30 的字符層數(shù)又會偏低查找慢得讓人懷疑人生。角度步長有個可以手算的經(jīng)驗公式模板上離中心最遠的邊緣點半徑記作 r旋轉(zhuǎn) Δθ 后這個點的位移約等于 r·Δθ。要求這個位移不超過 1 個像素就得到 Δθ ≤ 1/r弧度。半徑 150 像素的模板Δθ 差不多 0.0067 弧度也就是 0.38 度。// 由模板 ROI 的等效半徑反推角度步長比 auto 更貼合實際尺寸 double w 260.0, h 160.0; // ROI 寬高像素 double r 0.5 * sqrt(w * w h * h); // 最遠邊緣點半徑 double stepRad 1.0 / r; // 旋轉(zhuǎn)位移不超過 1 像素 double stepDeg stepRad * 180.0 / 3.14159265; stepDeg stepDeg * 0.7; // 留 30% 余量 stepDeg max(0.1, min(1.0, stepDeg)); // 夾到工程可用區(qū)間 HTuple hv_AngleStep HTuple(stepDeg).TupleRad();算完之后可以反過來驗證把AngleStep設成這個值建一次模板再用同一張圖在角度范圍的邊界處比如 14.5 度去查score 應該還在 0.8 以上。如果掉得厲害說明步長還是粗了。這個“邊界自測”是我每次建完模板必做的一步比看任何文檔都直觀。層數(shù)這邊我的習慣是建完模板后打印一下每層的點數(shù)// 檢查金字塔各層剩下多少模板點頂層太少就手動降層數(shù) HTuple hv_NumLevels, hv_Points; GetShapeModelContours(ho_ModelContours, hv_ModelID, 1); // 取第 1 層輪廓 // 更直接的辦法重建一次顯式指定層數(shù)對比匹配耗時和穩(wěn)定性頂層點數(shù)低于 20 個粗定位基本靠運氣這時候要么把NumLevels手動減 12 層要么擴大 ROI 讓特征更豐富。別嫌麻煩這一步省下的時間會在現(xiàn)場調(diào)試時十倍還回來。3.3find_shape_model分數(shù)、重疊和貪心度查找參數(shù)里真正需要動的是四個MinScore、NumMatches、MaxOverlap、Greediness。MinScore是門檻低于它的候選直接丟棄。設太高光照一變就報“未找到”設太低背景里隨便一塊紋理都能湊到 0.4。經(jīng)驗值是 0.60.7 起步等批量驗證過 score 分布之后再收緊。MaxOverlap處理疊件。工件挨在一起時兩個匹配結(jié)果可能重疊 80% 以上其實是同一個目標被重復報了。設成 0.30.5 能有效去重但設太小會把真正緊挨著的兩個工件誤殺。Greediness是搜索的“貪心程度”0 最徹底最慢1 最快但可能漏檢默認 0.9。精密對位場景我一般降到 0.70.8多花 20% 時間換穩(wěn)定性值。// 查找并解析結(jié)果注意返回的是四個 HTuple長度等于匹配個數(shù) HTuple hv_Row, hv_Column, hv_Angle, hv_Score; FindShapeModel(ho_Image, hv_ModelID, HTuple(-15).TupleRad(), HTuple(30).TupleRad(), HTuple(0.6), // MinScore HTuple(3), // NumMatches最多找 3 個 HTuple(0.4), // MaxOverlap去掉重疊候選 HTuple(least_squares), // SubPixel亞像素精度 HTuple(0), // NumLevels0沿用建模層數(shù) HTuple(0.8), // Greediness hv_Row, hv_Column, hv_Angle, hv_Score); // 結(jié)果按 Score 降序排列取第 0 個就是最優(yōu) for (int i 0; i hv_Score.Length(); i) { double row hv_Row[i].D(); // Row 是行坐標也就是 Y double col hv_Column[i].D(); // Column 是列坐標也就是 X double ang hv_Angle[i].D(); // 弧度順時針為正 double scr hv_Score[i].D(); // 這里做你的坐標轉(zhuǎn)換、發(fā)給 PLC }亞像素模式選least_squares它在初步定位后用最小二乘擬合邊緣重復精度能到 0.02 像素級別interpolation快一些但精度差一檔none只在極端追求速度時用。這個參數(shù)和Greediness是速度與精度這組矛盾的兩個旋鈕別同時往快的那頭擰。4. 顯示與坐標從 HObject 到 Picture Control 的像素對齊4.1 把 Halcon 窗口嵌進控件父句柄別傳錯Halcon 的窗口本質(zhì)上是個子窗口OpenWindow的第五個參數(shù)就是父窗口句柄。傳對話框的m_hWnd圖像會蓋住所有控件傳 Picture Control 的句柄圖像才會老老實實待在框里。void CMatchDemoDlg::OpenHalconWindow() { // 重開前必須先關否則每切換一次分辨率就漏一個窗口句柄 if (m_hvWindowHandle.Length() 0) { CloseWindow(m_hvWindowHandle); m_hvWindowHandle HTuple(); } CWnd* pCtrl GetDlgItem(IDC_PIC_DISPLAY); CRect rc; pCtrl-GetClientRect(rc); OpenWindow(0, 0, rc.Width(), rc.Height(), pCtrl-GetSafeHwnd(), // 父句柄只認控件不認對話框 visible, , m_hvWindowHandle); SetWindowAttr(flush, false); // 批量繪制時先不刷最后統(tǒng)一 FlushBuffer }flush設成false是個明顯的性能開關尤其在一幀里要畫幾十個輪廓的時候。設完之后記得在繪制結(jié)尾調(diào)一次FlushBuffer(m_hvWindowHandle)否則畫面不動你會以為程序死了。窗口大小變化時要重開或者用SetWindowExtents調(diào)整。重開更干脆但必須先把舊窗口關掉這一條我吃過虧——早期版本里每次OnSize都OpenWindow一次而不關舊的跑了一下午任務管理器里 GDI 對象數(shù)一路漲到幾萬最后整個界面變成一片白。4.2 三套坐標圖像坐標、控件坐標、屏幕坐標這是新手最容易翻車的地方也是我見過最多“匹配明明對了但框畫偏了”的原因。三套坐標的換算方向必須記死Halcon 的Row對應屏幕上的 Y豎直向下Column對應 X水平向右。寫代碼時row傳給了 X 參數(shù)結(jié)果就是整個框順時針轉(zhuǎn)了 90 度?？丶鴺说脑c在控件左上角MFC 的OnLButtonDown給的point是相對對話框的得先ScreenToClient。圖像坐標和控件坐標之間隔著一個SetPart縮放比例和偏移都在里面。void CMatchDemoDlg::OnLButtonDown(UINT nFlags, CPoint point) { // MFC 給的 point 是相對對話框客戶區(qū)的先轉(zhuǎn)到顯示控件坐標系 CPoint pt point; m_wndDisplay.ScreenToClient(pt); // 取出當前顯示區(qū)域?qū)膱D像范圍 HTuple hv_Row1, hv_Column1, hv_Row2, hv_Column2; GetPart(m_hvWindowHandle, hv_Row1, hv_Column1, hv_Row2, hv_Column2); CRect rc; m_wndDisplay.GetClientRect(rc); // 控件坐標 - 圖像坐標線性映射別在這里加任何經(jīng)驗偏移 double imgRow hv_Row1.D() (hv_Row2.D() - hv_Row1.D()) * pt.y / rc.Height(); double imgCol hv_Column1.D() (hv_Column2.D() - hv_Column1.D()) * pt.x / rc.Width(); // 記下來給 ROI 用 m_dClickRow imgRow; m_dClickCol imgCol; }另一種寫法是直接用GetMposition(m_hvWindowHandle, row, col, window)讓 Halcon 自己算。它更省事但有個前提調(diào)用它的線程必須是開窗的那個線程工作線程里調(diào)會返回一堆 0 或者拋異常。所以我在跨線程的場合一律手算寧可多寫三行。還有一個隱蔽的坑SetPart傳的參數(shù)順序是(Row1, Column1, Row2, Column2)而GenRectangle1的順序是(Row1, Column1, Row2, Column2)看著一致但很多人順手把Column2寫成了Row2結(jié)果顯示區(qū)域變成一個細長條。這種錯誤編譯器不會報只能靠肉眼發(fā)現(xiàn)。4.3 句柄和內(nèi)存的生命周期別指望 GCHalcon 的HObject內(nèi)部是引用計數(shù)理論上離開作用域就釋放。但有兩類東西不在此列一是窗口句柄OpenWindow出來的必須CloseWindow二是HTuple里塞的數(shù)組如果在一個循環(huán)里不停TupleConcat內(nèi)存會一直漲。我的做法是給圖像加一個作用域守衛(wèi)避免在異常路徑上漏掉釋放// HObject 的作用域守衛(wèi)構造時給個空對象析構時強制 ClearObj class HObjScope { public: HObjScope() { m_obj.GenEmptyObj(); } ~HObjScope() { m_obj.ClearObj(); } // 引用計數(shù)歸零底層內(nèi)存立即回收 HObject* operator() { return m_obj; } // 支持 ReadImage(scope, ...) 這種寫法 HObject Get() { return m_obj; } private: HObjScope(const HObjScope); // 禁止拷貝防止引用計數(shù)被意外加一 HObjScope operator(const HObjScope); HObject m_obj; };ClearObj和讓它自然析構的區(qū)別在于時機自然析構要等棧展開異常路徑上如果被catch吞掉又沒重新拋出對象可能活到下一輪循環(huán)。顯式清一下內(nèi)存曲線會平得多。至于查看內(nèi)存任務管理器不夠用我一般掛個性能計數(shù)器看私有字節(jié)跑兩百幀不回落就是有泄漏。5. 避坑與排查模板匹配在 MFC 里翻車的五種現(xiàn)場5.1 Debug 能跑Release 一啟動就崩現(xiàn)象Debug 下匹配正常切到 Release 雙擊 exe要么閃退要么ReadImage返回空、后面一路空指針。原因九成是運行時庫不匹配。工程用/MT靜態(tài)鏈接而halconcpp.lib是按/MD編的兩套 CRT 同時在進程里堆的分配和釋放跨了邊界HObject析構時就會踩到別人的堆。解決C/C → 代碼生成 → 運行時庫Debug 用/MDd、Release 用/MD和 Halcon 保持一致。改完記得全量重編只做增量編譯的話舊的 obj 還帶著老設置。5.2 換個角度就找不到score 掉到 0.3 以下現(xiàn)象工件擺正的時候 score 0.9 穩(wěn)如老狗一轉(zhuǎn)到十幾度就報未找到或者匹配到一個明顯錯誤的位置。原因三個可能按概率排——AngleExtent沒覆蓋實際偏轉(zhuǎn)范圍AngleStep太粗邊界角度上模板和實際錯開了半個像素以上MinContrast設太高轉(zhuǎn)到側(cè)面時邊緣對比度下降模板點被大量過濾。解決先把AngleStart/AngleExtent放寬到實際范圍的兩倍做一次驗證能穩(wěn)定找到再收窄再按 3.2 的公式重算AngleStep最后把MinContrast降到建模Contrast的三分之一試試。三步做完還是不行那就是模板本身特征不足得換 ROI 或者加輔助特征。5.3 界面卡死匹配框畫在了按鈕上現(xiàn)象點開始之后界面卡住幾秒后圖像出來但畫在了對話框左上角蓋住了標題欄和按鈕。原因算子在 UI 線程里同步跑消息泵被堵住同時OpenWindow的父句柄傳成了對話框的m_hWnd而不是 Picture Control 的句柄。解決算子挪到工作線程見 2.3結(jié)果通過PostMessage回主線程繪制父句柄改成控件句柄。改父句柄之后要檢查OnSize控件尺寸變了窗口得跟著調(diào)否則圖像會被裁掉一塊。5.4 跑一兩個小時內(nèi)存持續(xù)上漲現(xiàn)象剛啟動時幾十兆跑一下午漲到一兩個 G最后彈“內(nèi)存不足”。原因OpenWindow之后沒CloseWindow每次重開分辨率或切圖都漏一個循環(huán)里ReadImage出來的HObject掛在成員變量上沒清HTuple在循環(huán)里做TupleConcat累積。解決所有窗口操作成對出現(xiàn)寫一個ResetWindow()統(tǒng)一管圖像用 4.3 的守衛(wèi)HTuple在循環(huán)開頭hv_Result HTuple()重置。掛性能計數(shù)器觀察私有字節(jié)跑兩百幀不回落就是還有漏。5.5 中文路徑的圖讀不進來現(xiàn)象ReadImage拋異常說文件不存在但資源管理器里明明有或者路徑里的中文變成一堆問號。原因MFC 工程默認 UnicodeHTuple接受const char*時按 ANSI 解釋寬字符路徑直接傳進去就是亂碼。解決所有傳給 Halcon 的字符串都過一遍轉(zhuǎn)換CString strPath _T(D:\\圖像\\part_01.png); HTuple hv_File(CT2A(strPath)); // 轉(zhuǎn)成窄字符需要 atlconv.h ReadImage(ho_Image, hv_File);更徹底的辦法是工程目錄和文件名全用英文但現(xiàn)場拷貝過來的圖往往不聽話轉(zhuǎn)換這一步別省。6. 交付前的一次壓測用五十張圖驗證穩(wěn)定性與節(jié)拍模板匹配調(diào)通不等于能交付。我踩過最疼的一次是現(xiàn)場跑了兩小時才開始偶發(fā)漏檢——光照隨時間漂移上午十點以后太陽斜射進車間工件的對比度整體往下掉了三成MinContrast那關就過不去了。從那以后交付前必須跑一輪批量驗證。驗證分三塊缺一不可驗證項做法判據(jù)覆蓋率五十張覆蓋全角度范圍的真實圖逐張跑漏檢 0 張誤匹配 0 張分數(shù)分布統(tǒng)計所有 score 的最小值與均值最小值 MinScore× 1.3重復性同一張固定圖連查 100 次Row/Column 標準差 0.05 像素節(jié)拍連續(xù)跑 500 次取均值單幀耗時 產(chǎn)線節(jié)拍的 1/3最后一項留三倍余量不是保守是給現(xiàn)場的老工控機留的——開發(fā)機是 i7產(chǎn)線上那臺可能是十年前的雙核。批量腳本我一般直接寫在 demo 里加個隱藏的按鈕只在調(diào)試模式下顯示void CMatchDemoDlg::RunBatchTest() { double minScore 1.0, sumMs 0.0; std::vectordouble vRow; int nOk 0, nNg 0; for (int i 1; i 50; i) { CString strPath; strPath.Format(_T(data\\part_%02d.png), i); // 圖按序號命名覆蓋全角度 HTuple hv_File(CT2A(strPath)); HObject ho_Image; ReadImage(ho_Image, hv_File); LARGE_INTEGER t0, t1, freq; QueryPerformanceFrequency(freq); QueryPerformanceCounter(t0); // 計時只包住 FindShapeModel HTuple hv_Row, hv_Column, hv_Angle, hv_Score; FindShapeModel(ho_Image, m_hvModelID, HTuple(-15).TupleRad(), HTuple(30).TupleRad(), 0.6, 1, 0.5, least_squares, 0, 0.8, hv_Row, hv_Column, hv_Angle, hv_Score); QueryPerformanceCounter(t1); sumMs (t1.QuadPart - t0.QuadPart) * 1000.0 / freq.QuadPart; if (hv_Score.Length() 0) { nOk; minScore min(minScore, hv_Score[0].D()); vRow.push_back(hv_Row[0].D()); // 重復性用固定圖另外跑 } else { nNg; } ho_Image.ClearObj(); } // 結(jié)果直接彈個 AfxMessageBox或者寫日志別只在調(diào)試器里看 CString strMsg; strMsg.Format(_T(通過 %d / 失敗 %d / 最低分 %.3f / 平均耗時 %.1f ms), nOk, nNg, minScore, sumMs / 50.0); AfxMessageBox(strMsg); }計時的位置很講究QueryPerformanceCounter要把FindShapeModel單獨包起來別把取圖和繪制也算進去否則測出來的是整個流程的耗時優(yōu)化的時候找不到重點。hv_Score[0]取第一個是因為結(jié)果已經(jīng)按分數(shù)降序這里只關心最優(yōu)的那個。重復性那項要單獨做拿同一張圖重復查 100 次把Row、Column存進std::vector算標準差。如果標準差跑到 0.3 像素以上說明模板的邊緣特征不夠銳利或者Greediness設太高導致每次走的搜索路徑不同。這個指標比 score 更能反映系統(tǒng)的真實精度因為 score 是相對的重復性是絕對的。還有個小技巧把五十張圖的 score 全部打到日志里畫個折線看一眼。如果是一條平線說明模板很穩(wěn)如果中間有個 V 形谷那幾張圖就是薄弱環(huán)節(jié)單獨拎出來分析光照或者遮擋比現(xiàn)場出了問題再回頭查高效得多。我現(xiàn)在的習慣是只要這個 demo 要交給別人用不管對方說得多急批量驗證這一輪必須強制走完日志文件跟 exe 一起打包。不是為了證明什么是因為現(xiàn)場那臺機器和那張圖永遠比實驗室里多一個你想不到的變量。希望幫到你。本文還有配套的精品資源點擊獲取