簡(jiǎn)介面向 C# 開發(fā)者的 OpenCvSharp4.1 官方例程合集適合已具備一定 .NET 基礎(chǔ)、希望對(duì)照官方示例學(xué)習(xí) OpenCV 4.1 圖像處理與計(jì)算機(jī)視覺 API 的讀者。包內(nèi)共 176 個(gè)文件以 60 個(gè) cs 源碼和少量 vb 示例為主體輔以 jpg、png、bmp 等示例圖像、mp4 演示視頻、項(xiàng)目配置、解決方案及 prototxt 等模型描述文件壓縮包約 37.25MB目錄按示例與工程文件組織便于檢索和直接運(yùn)行調(diào)試。已有 13192 人學(xué)習(xí)下載說明其在 C# 視覺入門與示例查閱場(chǎng)景中具有一定參考價(jià)值。讀者可從中獲得圖像讀寫、二值化處理等基礎(chǔ)案例的完整工程結(jié)構(gòu)對(duì)照源碼理解 OpenCvSharp 的調(diào)用方式、參數(shù)設(shè)置與常見排錯(cuò)思路也可將其作為課程實(shí)驗(yàn)、項(xiàng)目原型或自有應(yīng)用的起步模板。1. OpenCvSharp4.1 例程包到底裝了什么先跑通再拆原理拿到 OpenCvSharp4.1 官方例程的第一晚我建議先別動(dòng)代碼原樣跑一遍比讀十頁文檔管用。它是 OpenCV 4.1 的 C# 封裝配套示例集合覆蓋 Mat 讀寫與像素訪問、色彩空間轉(zhuǎn)換、濾波與邊緣檢測(cè)、輪廓分析、攝像頭取流和視頻寫出再往外一圈是 WinForms/WPF 的顯示封裝。適合兩類人想把手上 Python 視覺腳本遷到 C# 桌面端的開發(fā)者以及需要在 .NET 項(xiàng)目里嵌圖像處理、又不想自己寫 P/Invoke 的工程師。下面按「跑通—拆解—調(diào)參—排錯(cuò)」的順序把拆包時(shí)的判斷和參數(shù)選擇寫清楚能照著復(fù)現(xiàn)。2. 環(huán)境搭起來四個(gè)包的職責(zé)邊界與第一個(gè)出圖的 Mat 程序例程包本身不帶運(yùn)行環(huán)境能不能跑起來幾乎全看 NuGet 引用對(duì)不對(duì)。這一章先把包結(jié)構(gòu)講清楚再建一個(gè)最小工程驗(yàn)證鏈路通不通最后講 Mat 的內(nèi)存模型——這塊不清楚后面所有例程都會(huì)以內(nèi)存暴漲的形式還回來。2.1 四個(gè)包的職責(zé)邊界與常見引錯(cuò)OpenCvSharp 的包拆得很細(xì)職責(zé)基本是這樣的包名作用缺了它會(huì)怎樣OpenCvSharp4托管層 APIMat、Cv2、VideoCapture 等編譯期就報(bào)找不到類型OpenCvSharp4.runtime.win原生 OpenCvSharpExtern.dll 與 ffmpeg 視頻解碼庫編譯能過運(yùn)行時(shí) DllNotFoundExceptionOpenCvSharp4.ExtensionsMat 與 System.Drawing.Bitmap 互轉(zhuǎn)WinForms 顯示這一環(huán)斷掉OpenCvSharp4.WpfExtensionsMat 與 WPF BitmapSource 互轉(zhuǎn)WPF 下拿不到 WriteableBitmap關(guān)鍵點(diǎn)在于版本對(duì)齊托管包和 runtime 包必須是同一個(gè) 4.1 分支版本。C# 側(cè)調(diào)用的導(dǎo)出函數(shù)簽名跟著托管包走原生 OpenCvSharpExtern.dll 的導(dǎo)出表跟著 runtime 包走兩者錯(cuò)位最典型的癥狀是EntryPointNotFoundException而且報(bào)錯(cuò)信息指向一個(gè)看起來毫不相干的函數(shù)名第一次遇上會(huì)以為是包壞了。另一個(gè)硬約束是位數(shù)。原生 dll 分 x86 和 x64進(jìn)程位數(shù)必須一致。C# 工程默認(rèn)是 AnyCPU在 64 位系統(tǒng)上跑成 64 位進(jìn)程但一旦勾了「首選 32 位」進(jìn)程變成 32 位加載 x64 的 dll 直接失敗。我一般做法是顯式把 PlatformTarget 釘死成 x64不給運(yùn)行時(shí)留選擇余地。2.2 從零建工程三條命令加一個(gè) csproj用命令行建工程最快避免在 IDE 里點(diǎn)來點(diǎn)去點(diǎn)到某個(gè)默認(rèn)選項(xiàng)上。# 建一個(gè)控制臺(tái)工程名字隨便起 dotnet new console -n MatDemo cd MatDemo # 托管包與原生運(yùn)行庫包版本都跟 4.1 分支對(duì)齊 dotnet add package OpenCvSharp4 -v 4.1.* dotnet add package OpenCvSharp4.runtime.win -v 4.1.*版本號(hào)這里用4.1.*浮動(dòng)寫法具體補(bǔ)丁號(hào)以包管理器里 4.1 分支實(shí)際的最新版為準(zhǔn)不要跨大版本混裝。工程文件里再補(bǔ)一行平臺(tái)目標(biāo)Project SdkMicrosoft.NET.Sdk PropertyGroup OutputTypeExe/OutputType TargetFrameworknetcoreapp3.1/TargetFramework PlatformTargetx64/PlatformTarget !-- 釘死位數(shù)避免 AnyCPU 在 32 位上翻車 -- AllowUnsafeBlockstrue/AllowUnsafeBlocks !-- 例程里有指針遍歷像素的寫法 -- /PropertyGroup /ProjectAllowUnsafeBlocks不是必須但例程里訪問像素有幾個(gè)地方用的是Mat.DataPointer加unsafe指針先開著能省一次重編譯。目標(biāo)框架方面4.1 這一代在 .NET Framework 4.6.1 以上和 .NET Core 3.x 上都能跑桌面端拿 WinForms/WPF 做殼的選前者也行邏輯基本不用改。2.3 第一個(gè)能出圖的程序Mat 從讀到顯示不要一上來就跑最復(fù)雜的那個(gè)例程先用二十行代碼確認(rèn)讀圖、處理、顯示、保存四條通路都通。using OpenCvSharp; // 讀圖flags 決定通道數(shù)Color 是 3 通道 BGR using var src Cv2.ImRead(sample.jpg, ImreadModes.Color); if (src.Empty()) { // 路徑錯(cuò)、文件損壞、編碼不受支持都會(huì)走到這里提前退出比后面崩在 CvtColor 里好排查 Console.WriteLine(讀圖失敗檢查路徑或換個(gè)格式); return; } // 灰度與邊緣中間結(jié)果都放在獨(dú)立的 Mat 里方便單獨(dú)保存查看 using var gray new Mat(); Cv2.CvtColor(src, gray, ColorConversionCodes.BGR2GRAY); using var edges new Mat(); Cv2.Canny(gray, edges, 50, 150); // 顯示窗口名不要用中文部分平臺(tái)的 highgui 對(duì)寬字符支持不一致 Cv2.ImShow(src, src); Cv2.ImShow(edges, edges); Cv2.WaitKey(0); // 0 表示無限等待按鍵阻塞在這一行直到窗口有輸入 Cv2.DestroyAllWindows(); // 不調(diào)用的話后續(xù)循環(huán)里 ImShow 會(huì)不停新建窗口幾個(gè)參數(shù)值得記一下ImreadModes.Color強(qiáng)制三通道即使原圖是灰度或帶 alpha 也會(huì)被轉(zhuǎn)成 3 通道Canny的三個(gè)參數(shù)分別是輸入、輸出和兩個(gè)閾值后文會(huì)專門講怎么定這兩個(gè)數(shù)WaitKey(0)返回按鍵碼傳 0 是無限等傳 1 就是等 1 毫秒視頻播放循環(huán)里必須傳非零值這一點(diǎn)后面還會(huì)碰到。這段代碼能跑通說明托管包、原生 dll、highgui 三條鏈路都在位。跑不通的話問題基本就落在第 5 章那幾條上。2.4 Mat 的內(nèi)存模型為什么到處都在 usingMat 對(duì)象本身在托管堆上像素?cái)?shù)據(jù)在非托管內(nèi)存里靠引用計(jì)數(shù)管理。GC 只管得到那個(gè)殼管不到像素緩沖區(qū)所以Dispose必須顯式調(diào)用using寫法是最省心的方式。更麻煩的是 Mat 支持視圖從一個(gè) Mat 上切一塊 ROI新 Mat 和原 Mat 共享同一片像素內(nèi)存。using var src Cv2.ImRead(sample.jpg, ImreadModes.Color); // 這個(gè) Mat 只是視圖不拷貝像素指向 src 內(nèi)部的一塊區(qū)域 using var roi new Mat(src, new Rect(100, 100, 200, 200)); // Clone 才是真正申請(qǐng)新內(nèi)存、復(fù)制像素 using var copy roi.Clone(); roi.SetTo(Scalar.All(0)); // src 上的對(duì)應(yīng)區(qū)域一起變黑 // copy 不受影響搞不清這一點(diǎn)常見后果是「我明明只改了縮略圖原圖也花了」。判斷方法很簡(jiǎn)單構(gòu)造函數(shù)帶new Rect(...)或者new Range(...)的那種多半是視圖帶.Clone()、.CopyTo()的才是獨(dú)立內(nèi)存。寫循環(huán)處理時(shí)視圖的好處是省內(nèi)存壞處是生命周期互相牽連——視圖還沒釋放原 Mat 的引用計(jì)數(shù)就降不到零那片內(nèi)存就一直掛著。至于例程目錄怎么讀我的習(xí)慣是按依賴關(guān)系從簡(jiǎn)到繁來而不是按字母序典型分組覆蓋內(nèi)容建議順序基礎(chǔ)圖像ImRead/ImWrite、像素訪問、Mat 運(yùn)算第一圖像處理色彩空間、閾值、濾波、形態(tài)學(xué)、邊緣第二輪廓與幾何FindContours、包圍盒、多邊形擬合第三視頻與攝像頭VideoCapture、VideoWriter、幀循環(huán)第四界面與顯示W(wǎng)inForms/WPF 控件綁定、縮放與刷新第五檢測(cè)類級(jí)聯(lián)分類器、DNN 推理加載最后包內(nèi)實(shí)際目錄可能略有出入但依賴關(guān)系不會(huì)變。先把基礎(chǔ)圖像那組跑完能省掉后面大量「到底是 API 用錯(cuò)還是環(huán)境沒通」的反復(fù)猜。3. 例程逐類拆解ImRead、CvtColor、Canny、FindContours 的參數(shù)怎么定這一章是例程包里最值錢的部分也是大多數(shù)人跑完就跳過、后面寫業(yè)務(wù)代碼時(shí)又回頭翻的部分。圖像處理的參數(shù)沒有萬能值但每一個(gè)都有可以量化的定法下面按調(diào)用鏈順序講。3.1 讀寫與色彩空間通道順序和 HSV 的取值范圍OpenCV 的默認(rèn)通道順序是 BGR不是 RGB。C# 里從 Bitmap 轉(zhuǎn)過來、或者從攝像頭抓幀色序都是 BGR直接送給 WPF 或 WinForms 顯示會(huì)和原圖對(duì)不上藍(lán)色發(fā)紅。轉(zhuǎn)換方式在顯示環(huán)節(jié)做不要在算法入口做。using var src Cv2.ImRead(sample.jpg, ImreadModes.Color); using var hsv new Mat(); Cv2.CvtColor(src, hsv, ColorConversionCodes.BGR2HSV); // HSV 里 H 在 OpenCV 中被壓到 0~179不是 0~360 // 所以要取「紅色」范圍得用 0~10 和 170~179 兩段而不是 0~30 和 330~360 using var mask1 new Mat(); using var mask2 new Mat(); Cv2.InRange(hsv, new Scalar(0, 80, 60), new Scalar(10, 255, 255), mask1); Cv2.InRange(hsv, new Scalar(170, 80, 60), new Scalar(179, 255, 255), mask2); using var redMask mask1 | mask2; // 兩段合并三個(gè)參數(shù)的含義H 是色相OpenCV 為了塞進(jìn) 8 位無符號(hào)數(shù)除以了 2所以上限是 179S 是飽和度0 到 255低于 80 的基本是灰白區(qū)域V 是明度低于 60 接近純黑。這三個(gè)下限不是隨手寫的室內(nèi)弱光場(chǎng)景 V 要往下調(diào)到 40 左右否則暗部目標(biāo)全丟強(qiáng)光過曝場(chǎng)景 S 要往下調(diào)否則高光區(qū)域飽和度被壓扁。ImreadModes那幾個(gè)常用值也順便記一下Color強(qiáng)制三通道Grayscale單通道Unchanged保留原始通道和位深——讀 16 位 TIFF 或帶 alpha 的 PNG 時(shí)只有Unchanged不會(huì)丟數(shù)據(jù)其余模式都會(huì)做隱式轉(zhuǎn)換精度掉了自己都不知道。3.2 濾波與邊緣兩個(gè)閾值到底怎么定高斯模糊的核尺寸必須是奇數(shù)傳偶數(shù)會(huì)直接拋異常。sigma 傳 0 表示由核尺寸反推這是最常用的組合因?yàn)槭謩?dòng)調(diào) sigma 和核尺寸兩個(gè)參數(shù)很容易互相打架。using var src Cv2.ImRead(sample.jpg, ImreadModes.Grayscale); // ksize 必須是奇數(shù)sigmaX 傳 0 由 ksize 推導(dǎo) using var blur new Mat(); Cv2.GaussianBlur(src, blur, new Size(5, 5), 0); // Canny 的雙閾值低于低閾值直接判非邊緣高于高閾值直接判邊緣中間地帶看連通性 using var edges new Mat(); Cv2.Canny(blur, edges, 50, 150);兩個(gè)閾值的經(jīng)典比例是 1:2 到 1:3問題在于絕對(duì)數(shù)值隨場(chǎng)景變化極大。一個(gè)可量化的定法是用灰度均值做基準(zhǔn)Cv2.MeanStdDev(blur, out Scalar mean, out Scalar stddev); // 以均值上下浮動(dòng) 33% 作為雙閾值再夾到合法區(qū)間 double lower Math.Max(0, (1.0 - 0.33) * mean.Val0); double upper Math.Min(255, (1.0 0.33) * mean.Val0); using var autoEdges new Mat(); Cv2.Canny(blur, autoEdges, lower, upper); Console.WriteLine($lower{lower:F1}, upper{upper:F1});MeanStdDev輸出兩個(gè) Scalar這里只取第一個(gè)通道的Val0灰度圖正好只有這一個(gè)通道有意義。0.33 這個(gè)系數(shù)來自經(jīng)驗(yàn)偏低會(huì)把紋理噪聲都拉成邊緣偏高會(huì)丟掉弱對(duì)比輪廓。調(diào)試階段建議把算出來的兩個(gè)數(shù)打印出來下次遇到同類場(chǎng)景直接從這組數(shù)起步比盲調(diào)快得多。模糊核尺寸和 Canny 是聯(lián)動(dòng)的。核太大細(xì)邊緣在模糊階段就沒了怎么調(diào)閾值都找不回來核太小噪聲進(jìn)到 Canny 里閾值再高也會(huì)有零星碎邊。常見做法是先用 5×5 起步邊緣太碎把核加到 7×7邊緣太粗回到 3×3。3.3 形態(tài)學(xué)與輪廓hierarchy 和面積過濾形態(tài)學(xué)的兩個(gè)基本操作是開運(yùn)算和閉運(yùn)算前者去小噪點(diǎn)后者補(bǔ)小孔洞結(jié)構(gòu)元素尺寸決定能處理多大的缺陷。// 開運(yùn)算先腐蝕后膨脹去掉細(xì)小噪點(diǎn) using var kernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); using var opened new Mat(); Cv2.MorphologyEx(edges, opened, MorphTypes.Open, kernel); // 閉運(yùn)算先膨脹后腐蝕填補(bǔ)輪廓內(nèi)部的小斷裂 using var closed new Mat(); Cv2.MorphologyEx(opened, closed, MorphTypes.Close, kernel);GetStructuringElement的形狀參數(shù)里Rect適合矩形目標(biāo)Ellipse適合圓形或自然目標(biāo)Cross適合細(xì)線狀結(jié)構(gòu)。尺寸必須是奇數(shù)3×3 是最常用的起點(diǎn)處理的是像素級(jí)的毛刺要到 7×7 以上才能填補(bǔ)肉眼可見的缺口但同時(shí)會(huì)把相鄰目標(biāo)粘在一起這一步要拿實(shí)際圖反復(fù)看。找輪廓的簽名里有三個(gè)容易記錯(cuò)的點(diǎn)// 輸入圖建議傳 clone雖然 OpenCV 3.2 之后 FindContours 不再修改輸入但跨版本保險(xiǎn) using var input closed.Clone(); Cv2.FindContours( input, out Point[][] contours, out HierarchyIndex[] hierarchy, RetrievalModes.External, // 只要最外層輪廓 ContourApproximationModes.ApproxSimple); // 壓縮共線點(diǎn)只保留拐點(diǎn) foreach (var contour in contours) { double area Cv2.ContourArea(contour); if (area 200) continue; // 面積過濾去掉噪點(diǎn)輪廓 Rect box Cv2.BoundingRect(contour); double perimeter Cv2.ArcLength(contour, true); // 面積與周長(zhǎng)平方的比值可以粗略判斷形狀緊致程度接近圓的目標(biāo)這個(gè)值偏大 Console.WriteLine($area{area:F0} box{box} perimeter{perimeter:F0}); }RetrievalModes的選擇直接影響結(jié)果External只返回最外層適合數(shù)目標(biāo)個(gè)數(shù)Tree返回完整層級(jí)父子關(guān)系存在HierarchyIndex的Parent、FirstChild字段里適合做嵌套結(jié)構(gòu)分析比如找某個(gè)外框里面的小孔。ApproxSimple會(huì)把一條直線上的中間點(diǎn)全部壓縮掉點(diǎn)數(shù)能降一個(gè)數(shù)量級(jí)做面積和周長(zhǎng)計(jì)算時(shí)精度損失可以忽略但如果你要拿點(diǎn)集做模板匹配就得換成ApproxNone。面積閾值 200 這個(gè)數(shù)不是固定的它和圖像分辨率強(qiáng)相關(guān)。判斷方法先把所有輪廓面積打印出來排序噪點(diǎn)通常集中在個(gè)位數(shù)到幾十真實(shí)目標(biāo)會(huì)有一兩個(gè)明顯的數(shù)量級(jí)跳躍閾值就取在跳躍中間。4. 攝像頭與視頻鏈路VideoCapture 打開失敗、幀循環(huán)與 WPF 渲染圖像處理是靜態(tài)的視頻鏈路是動(dòng)態(tài)的問題類型完全不同。靜態(tài)圖調(diào)不通最多是結(jié)果不對(duì)視頻鏈路調(diào)不通就是黑屏、卡死、內(nèi)存一路漲。這一章把取流、幀循環(huán)、界面刷新、寫出四段拆開。4.1 VideoCapture 打開失敗的排查順序// 第二個(gè)參數(shù)指定后端Windows 上 DSHOW 兼容性最好MSMF 打開更快但設(shè)備兼容性略差 using var cap new VideoCapture(0, VideoCaptureAPIs.DSHOW); if (!cap.IsOpened()) { Console.WriteLine(打開攝像頭失敗); return; } // 分辨率要在打開之后、讀幀之前設(shè)置順序反了很多設(shè)備會(huì)靜默忽略 cap.Set(VideoCaptureProperties.FrameWidth, 1280); cap.Set(VideoCaptureProperties.FrameHeight, 720); cap.Set(VideoCaptureProperties.FPS, 30); // 設(shè)置不一定生效讀回來確認(rèn)實(shí)際值 Console.WriteLine($實(shí)際 {cap.FrameWidth}x{cap.FrameHeight} {cap.Fps});排查順序我一般是這樣先確認(rèn)設(shè)備索引0 是默認(rèn)攝像頭多設(shè)備時(shí)逐個(gè)試 0 到 3再看后端DSHOW和MSMF換著試某些采集卡只認(rèn)其中一個(gè)然后看是不是被別的程序占用攝像頭是獨(dú)占資源另一個(gè)進(jìn)程開著預(yù)覽就搶不到最后看分辨率設(shè)了一個(gè)設(shè)備不支持的尺寸有的驅(qū)動(dòng)會(huì)直接失敗而不是回退到最近的可用值。Set之后再Get一遍確認(rèn)這一步能省掉大量「代碼明明設(shè)了 1080p 為什么出來是 640」的困惑。4.2 幀循環(huán)的寫法與退出條件using var frame new Mat(); while (true) { // Read 內(nèi)部是 Grab Retrieve返回 false 表示流結(jié)束或取幀失敗 if (!cap.Read(frame) || frame.Empty()) { Console.WriteLine(取幀失敗可能是設(shè)備斷開或文件讀完); break; } // 處理放在這里注意不要在里面 new 大對(duì)象循環(huán)里每幀分配會(huì)觸發(fā)頻繁 GC Cv2.CvtColor(frame, frame, ColorConversionCodes.BGR2GRAY); Cv2.ImShow(live, frame); // 這里必須是 1 而不是 0傳 0 會(huì)阻塞到按鍵視頻就變成逐幀步進(jìn)了 if (Cv2.WaitKey(1) 27) break; // 27 是 ESC }循環(huán)體里有三個(gè)細(xì)節(jié)Read復(fù)用了同一個(gè)frame對(duì)象不會(huì)每幀新建 Mat這是有意的避免每幀分配非托管內(nèi)存WaitKey(1)除了控制播放節(jié)奏還負(fù)責(zé)處理 highgui 的窗口消息不調(diào)用的話窗口會(huì)假死退出條件除了 ESC還要考慮流自然結(jié)束所以Read的返回值必須判斷不能只靠異常。文件播放時(shí)節(jié)奏控制另說。攝像頭是實(shí)時(shí)的WaitKey(1)就夠播本地視頻想按原速回放得按 FPS 算延時(shí)WaitKey((int)(1000 / fps))直接傳 1 會(huì)快放。4.3 在 WinForms 和 WPF 上刷新畫面Cv2.ImShow只適合調(diào)試真做工具得嵌到界面里。WinForms 用 PictureBox轉(zhuǎn)換靠 Extensions 包// WinForms每幀轉(zhuǎn)成 Bitmap 塞給 PictureBox var bmp OpenCvSharp.Extensions.BitmapConverter.ToBitmap(frame); // 上一幀的 Image 必須手動(dòng)釋放否則 GDI 句柄會(huì)一路漲到系統(tǒng)上限 var old pictureBox1.Image; pictureBox1.Image bmp; old?.Dispose();WPF 走的是另一條路轉(zhuǎn)成WriteableBitmap直接綁到 Image 控件// WPF需要 OpenCvSharp4.WpfExtensions var wb OpenCvSharp.WpfExtensions.WriteableBitmapConverter.ToWriteableBitmap(frame); imageControl.Source wb;WPF 這里有個(gè)跨線程的坑取流通常放在后臺(tái)線程但給Image.Source賦值必須在 UI 線程。最省事的做法是后臺(tái)線程只負(fù)責(zé)處理和轉(zhuǎn)換轉(zhuǎn)好的WriteableBitmap通過Dispatcher.BeginInvoke拋回 UI 線程賦值。BeginInvoke而不是Invoke是因?yàn)橥降却趲矢叩臅r(shí)候會(huì)把后臺(tái)線程拖住反而掉幀。性能上還有一條BitmapConverter.ToBitmap每幀都會(huì)新建一個(gè) Bitmap30fps 下每秒 30 次分配加釋放GC 壓力不小。分辨率上到 1080p 以后建議改成預(yù)分配一個(gè)固定尺寸的 Bitmap用LockBits直接寫像素雖然代碼多幾行但幀率會(huì)穩(wěn)很多。4.4 VideoWriter 的編碼與尺寸約束// 四字符編碼XVID 兼容性好MJPG 文件大但幾乎所有播放器都認(rèn) using var writer new VideoWriter( out.avi, FourCC.XVID, 25, // 幀率要和寫入節(jié)奏一致 new Size(1280, 720), // 必須與每幀尺寸完全一致 true); // 是否彩色 if (!writer.IsOpened()) { Console.WriteLine(VideoWriter 初始化失敗多半是編碼器不可用); return; } // 寫幀 writer.Write(frame); // 結(jié)束必須釋放否則文件尾索引不完整播放器打不開 writer.Release();三個(gè)硬約束幀尺寸必須和構(gòu)造時(shí)完全一致差一個(gè)像素都會(huì)靜默丟幀最后得到一個(gè) 0 字節(jié)或者時(shí)長(zhǎng)對(duì)不上的文件幀率參數(shù)只寫進(jìn)文件頭不影響實(shí)際寫入速度寫快了就是快放FourCC.XVID在部分精簡(jiǎn)版系統(tǒng)上可能找不到對(duì)應(yīng)編碼器這時(shí)換FourCC.MJPG它是 Motion-JPEG幾乎不會(huì)失敗代價(jià)是文件體積大好幾倍。5. 避坑與排查五個(gè)把人勸退的現(xiàn)場(chǎng)例程跑不通的原因高度集中下面五條按我遇到的頻率排序每條都按現(xiàn)象、原因、解決三段寫。5.1 原生庫加載失敗與位數(shù)不匹配現(xiàn)象編譯通過一運(yùn)行就拋DllNotFoundException: OpenCvSharpExtern或者BadImageFormatException。原因前者是 runtime 包沒裝或者原生 dll 沒被復(fù)制到輸出目錄后者是位數(shù)不匹配32 位進(jìn)程去加載 64 位 dll。還有一種隱蔽情況機(jī)器上裝過別的 OpenCV 版本系統(tǒng) PATH 里有同名 dll加載到了錯(cuò)誤的那份。解決先看輸出目錄下有沒有OpenCvSharpExtern.dll和opencv_videoio_ffmpeg*.dll沒有就重新裝 runtime 包并清理重建有的話用dumpbin /headers看一眼架構(gòu)把 PlatformTarget 顯式設(shè)成 x64不要依賴 AnyCPU 的默認(rèn)行為排查 PATH 污染必要時(shí)在代碼里顯式指定原生庫搜索目錄。5.2 讀視頻返回空幀與中文路徑現(xiàn)象VideoCapture的IsOpened()返回 true但Read一直返回 false或者ImRead對(duì)某些圖片一直返回空 Mat換個(gè)路徑就好了。原因視頻打不開多半是缺 ffmpeg 解碼庫runtime 包里帶的那份沒被復(fù)制過去圖片讀不到基本是路徑含非 ASCII 字符原生層的文件打開用的是窄字符接口編碼一錯(cuò)就找不到文件。解決視頻先確認(rèn) ffmpeg 的 dll 在輸出目錄圖片路徑要么改成純英文要么用Cv2.ImDecode(File.ReadAllBytes(path), ImreadModes.Color)繞開原生文件接口——這個(gè)寫法把讀文件交給 .NET解碼交給 OpenCV中文路徑問題直接消失我在所有交付項(xiàng)目里都這么處理。5.3 Mat 未釋放導(dǎo)致內(nèi)存一路漲現(xiàn)象跑幾分鐘內(nèi)存從幾百兆漲到幾個(gè) G任務(wù)管理器里非托管內(nèi)存持續(xù)增長(zhǎng)GC 也壓不下去。原因Mat 的像素?cái)?shù)據(jù)在非托管內(nèi)存里GC 只回收托管殼不回收像素緩沖區(qū)。循環(huán)里new Mat()而不Dispose或者用 ROI 視圖把原 Mat 的引用計(jì)數(shù)釘住都會(huì)造成泄漏。另一種常見情況是異常路徑跳過了Dispose。解決所有 Mat 一律用using包括臨時(shí)中間結(jié)果循環(huán)里復(fù)用同一個(gè) Mat 而不是每幀新建用Cv2.GetTickCount之類的手段做壓力測(cè)試跑一千幀看內(nèi)存是否穩(wěn)定視圖用完立刻釋放需要保留就Clone出獨(dú)立內(nèi)存。5.4 WaitKey 不調(diào)用導(dǎo)致窗口假死現(xiàn)象ImShow的窗口白屏、拖動(dòng)沒反應(yīng)、點(diǎn)關(guān)閉按鈕也關(guān)不掉整個(gè)進(jìn)程像卡住了。原因highgui 的窗口消息要靠WaitKey驅(qū)動(dòng)不調(diào)用它窗口只是創(chuàng)建了但不進(jìn)消息循環(huán)。這一條在新手代碼里出現(xiàn)頻率極高屬于典型的「玄學(xué)」問題——代碼看不出錯(cuò)就是不響應(yīng)。解決任何ImShow之后必須跟一個(gè)WaitKey靜態(tài)圖用WaitKey(0)視頻循環(huán)用WaitKey(1)程序退出前調(diào)DestroyAllWindows()如果是在后臺(tái)線程里顯示注意 highgui 的窗口操作要放在同一個(gè)線程里跨線程調(diào)用會(huì)出現(xiàn)更難查的問題。5.5 WPF 圖像不更新與跨線程異?，F(xiàn)象后臺(tái)線程更新了 Mat界面上的圖一動(dòng)不動(dòng)或者直接拋「調(diào)用線程無法訪問此對(duì)象因?yàn)榱硪粋€(gè)線程擁有該對(duì)象」。原因WPF 的 UI 元素有線程親和性后臺(tái)線程不能直接賦值Image.Source另一種情況是每幀都賦了新的WriteableBitmap但 UI 線程被別的邏輯占滿渲染隊(duì)列積壓看上去就是不刷新。解決轉(zhuǎn)換在后臺(tái)做賦值用Dispatcher.BeginInvoke拋回 UI 線程WriteableBitmap可以復(fù)用同一個(gè)實(shí)例改內(nèi)容后調(diào)Lock/AddDirtyRect/Unlock比每幀新建省一大截如果幀率還是上不去檢查是不是把耗時(shí)處理放在了 UI 線程。6. 把例程改成自己的工具一條可復(fù)用的處理管線例程的價(jià)值不在代碼本身在它給出了每條調(diào)用鏈的標(biāo)準(zhǔn)寫法。真正落地時(shí)把這些散落的調(diào)用收成一個(gè)管線類參數(shù)從配置文件讀比每次復(fù)制粘貼強(qiáng)得多。我一般的組織方式是一個(gè)IImageStep接口加若干實(shí)現(xiàn)管線負(fù)責(zé)串聯(lián)每步的開關(guān)和參數(shù)寫在配置里public interface IImageStep { string Name { get; } Mat Process(Mat input); // 返回新 Mat調(diào)用方負(fù)責(zé)釋放 } public sealed class Pipeline { private readonly ListIImageStep _steps new(); public void Add(IImageStep step) _steps.Add(step); public Mat Run(Mat src) { var current src.Clone(); // 入口先 Clone避免改到調(diào)用方的圖 foreach (var step in _steps) { var next step.Process(current); current.Dispose(); // 上一步的中間結(jié)果立刻釋放 current next; } return current; } }這套寫法的好處是每步都能單獨(dú)開關(guān)、單獨(dú)計(jì)時(shí)。加一個(gè)Stopwatch包在Process外面跑一遍就知道瓶頸在哪一步多數(shù)時(shí)候是形態(tài)學(xué)或者大核模糊而不是看起來最復(fù)雜的輪廓分析。步驟關(guān)鍵參數(shù)調(diào)參依據(jù)灰度轉(zhuǎn)換通道順序 BGR2GRAY輸入若是 RGB 要先轉(zhuǎn)序高斯模糊ksize 奇數(shù)、sigma 為 0邊緣碎就加大核Canny高低閾值 1:21:3用灰度均值 ±33% 起步形態(tài)學(xué)開核 3×3 到 7×7噪點(diǎn)尺寸決定核大小輪廓過濾面積閾值按面積分布的數(shù)量級(jí)跳躍取驗(yàn)證方法我固定用兩步一是拿一張標(biāo)準(zhǔn)圖跑全流程把每一步的中間結(jié)果ImWrite出來存成序列肉眼過一遍找出哪一步開始不對(duì)二是跑一千幀壓力測(cè)試看內(nèi)存曲線是否平穩(wěn)、單幀耗時(shí)是否在預(yù)算內(nèi)。這兩步走完參數(shù)才敢往業(yè)務(wù)里帶。血淚經(jīng)驗(yàn)是別在管線里做隱式轉(zhuǎn)換。初期為了省事我在某一步里直接把 BGR 當(dāng) RGB 處理單測(cè)看不出來上線后所有顏色判定的閾值全偏排查了大半天。從那以后我每接一個(gè) C# 視覺需求都會(huì)先把中間結(jié)果落盤、把每步耗時(shí)打出來再談?wù){(diào)參。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取