做C#视觉工作流的时候最绕不开的一个操作就是把图像里的目标“数清楚”。不管是零件计数、颗粒检测还是缺陷定位我们拿到的往往是一张二值图而真正需要的是一份清单图里有几个目标、每个在哪儿、尺寸多大。这个从“像素集合”变成“目标清单”的过程就是组件连通分析在OpenCV里对应ConnectedComponentsWithStats。很多人会先入为主去用找轮廓结果被断裂边缘折腾到怀疑人生实际上连通组件分析在很多场景下更直接、更稳。这一章我会从API用法、参数含义、工作流整合到现场调试一条线讲完适合正在用OpenCvSharp做视觉方案、想彻底搞懂组件连通怎么落地的朋友。1. 为什么视觉工作流里需要“组件连通”这一步1.1 二值图上的“区域”到底凭什么连在一起先回到最基础的概念。图像经过二值化之后每个像素不是0就是255白色代表前景目标黑色代表背景。现在的问题是一堆白色像素里哪些属于同一个目标答案就看它们是否“相邻”。上下左右相邻、斜对角也相邻凡是能通过这些邻接关系串在一起的白色像素就算同一个区域这个区域在OpenCV里叫连通组件。你可以把二值图想象成一片水域里的岛屿黑色背景是水面白色像素是露出水面的陆地。所谓连通组件分析就是给每一块独立的岛屿发一个编号再量一下每座岛的位置、占地面积和边界框。这个操作本身不涉及任何深度模型也不依赖花哨的特征描述纯粹靠像素之间的关系所以它很快也非常适合作视觉工作流的前置步骤。在C#里OpenCvSharp封装了这个能力核心函数是ConnectedComponentsWithStats。它和轮廓提取有联系但是出发点不同这一点我放在后面专门讲。现在你只需要记住连通组件输出的是一张标签图原图里所有属于同一个目标的像素会被标成同一个整数。1.2 连通组件分析在整个视觉工作流里的位置我接触过不少做视觉方案的朋友大家普遍容易走进一个误区拿到一幅图立刻想的是“先找边缘、再拟合轮廓”好像不经过轮廓就不好意思说自己在做视觉。实际上在工作流里连通的本质是区域分析它的作用是帮我们把“图像信息”转成“业务信息”。典型的流水线是预处理 → 二值化 → 形态学处理 → 连通组件分析 → 按业务规则过滤 → 输出坐标/数量/尺寸。连通组件处在中间偏后的位置它不负责识别目标是什么只负责把独立目标一个个切出来。切出来之后的事情比如筛掉太小的噪点、按宽高比排除长条异物、把每个目标的中心坐标发给机械臂全都以连通组件的结果为起点。所以这一章虽然只讲一个函数但它直接影响整套工作流的稳定性。如果这里分错了后面做匹配、分类、测量都会跟着错。2. C#环境下的连通组件API从二值图到Labels矩阵2.1 一个最小可跑的C#示例在OpenCvSharp里连通组件相关的API其实很简洁。下面这个示例是我在项目里最常用的起步写法输入一张灰度图输出所有组件的统计信息。using OpenCvSharp; // 1. 读图并转灰度 Mat src Cv2.ImRead(sample.png, ImreadModes.Grayscale); // 2. 二值化这里用Otsu自动阈值 Mat binary new Mat(); Cv2.Threshold(src, binary, 0, 255, ThresholdTypes.Otsu); // 3. 用开运算去掉细小的噪声和桥接 Mat kernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.MorphologyEx(binary, binary, MorphTypes.Open, kernel); // 4. 连通组件分析 int componentCount Cv2.ConnectedComponentsWithStats( binary, out var labels, out var stats, out var centroids, PixelConnectivity.Connectivity8, MatType.CV_32S); // 5. 遍历所有组件注意下标从1开始0是背景 for (int i 1; i componentCount; i) { int left stats.Atint(i, 0); int top stats.Atint(i, 1); int width stats.Atint(i, 2); int height stats.Atint(i, 3); int area stats.Atint(i, 4); double centerX centroids.Atdouble(i, 0); double centerY centroids.Atdouble(i, 1); // 这里就能拿到每个目标的矩形框、面积和质心了 }这段代码有很多细节值得展开。先说输出参数labels是标签图尺寸和输入图一样但每个像素存的不是灰度值而是它所属组件的编号stats是统计矩阵每行对应一个组件centroids是质心坐标。这三个输出物是后续所有逻辑的数据基础。2.2 stats与centroids里的每一列都代表什么stats是个二维矩阵第0行永远对应背景也就是标签值为0的像素。从第1行开始才是图像里真正的前景目标。每一行有5列含义是固定的列索引含义说明0Left外接矩形左上角X坐标单位像素1Top外接矩形左上角Y坐标单位像素2Width外接矩形宽度单位像素3Height外接矩形高度单位像素4Area组件实际包含的像素总数这里的Area不是外接矩形的宽乘高而是目标真实占用的像素数量。举个实际例子一个旋转45度的长条零件它的外接矩形可能很大但面积只占外接矩形的一小部分。视觉工作流里判断目标大小优先用Area边界框用来做绘制和裁剪。centroids是CV_64F类型的矩阵也就是double精度每一行两列分别是质心坐标X和Y。注意质心并不是简单的左上角加半宽半高而是按像素面积加权后的几何中心。对于不均匀形状或带有孔洞的目标质心和外接矩形中心往往有明显偏差做定位抓取时要用质心而不是矩形中心。2.3 读取标签数据时最容易踩的坑我第一次用这个函数的时候犯过一个挺蠢的错误直接把labels图显示出来结果整屏几乎全黑。这不是代码坏了而是labels里的像素值就是普通的整数编号比如3、17、208这些值作为灰度去显示绝大多数都在低灰度范围看起来就像一块黑布。要看labels图最好做颜色映射把每个编号映射成随机颜色这样既能直观看出区域划分效果也能快速发现“哪些目标被错误地连成了一个”。我在调试阶段习惯写一个小函数遍历labels像素按标签值赋予不同的BGR颜色。这一步虽然简单却能极大提升排查效率。另外要记住stats.Atint和centroids.Atdouble在目标数量少的时候完全够用但如果组件数量上千逐次At调用会显得很慢。后面工程化那一章我会专门说性能优化这里先留个印象。3. 连通性选择4邻域还是8邻域结果差一个数量级3.1 斜向相邻的物体怎么处理OpenCV里连通组件的邻域定义有两种4邻域只把上下左右四个方向视为相邻8邻域则把斜对角也算上。默认参数通常是8邻域但“默认”不一定是对的。我举个例子。画面里有两个矩形块位置刚好是左上角和右下角对角相碰接触面积只有一个像素。用8邻域判断这两个矩形会被当成同一个组件因为角上的像素斜着也能连过去。用4邻域判断斜对角不在邻域范围内它们就是两个独立组件。如果做的是零件计数这一个小细节就可能让统计结果直接少一半。视觉工作流里很多“粘连”问题并不是目标真的焊在一起了而是斜对角碰了一下。遇到这种情况第一步不是急着上距离变换和分水岭而是先试试把连通性从8改成4往往结果就很干净。3.2 如何根据形态特征反推合适的连通性那到底什么时候用8、什么时候用4我从实际项目里的几个规律出发给一个可参考的判断思路。如果你的目标是圆形颗粒、焊点、细胞这类“点头之交不容易出现”的对象用8邻域通常更符合人眼直觉稍微挨着一点就算连接逻辑上不容易漏。如果目标是矩形的PCB板、方形零件、带规则阵列的元件斜对角接触非常常见用4邻域会更稳。但还有更常见的做法不依赖连通性本身去解决斜碰问题而是在连通之前用形态学开运算把“角碰”的接触点处理掉。开运算的核稍微选大一点就能把斜角接触处的那个桥接像素断开然后继续用8邻域。这两种方案没有绝对优劣我通常是先用8邻域跑一版看labels映射图如果发现明显的斜角合并再决定换4还是加形态学处理。4. 从原始图像到组件过滤一整套可落地的C#视觉工作流4.1 二值化前的预处理顺序不能乱在实际项目中原材料图千差万别很少有一张图拿过来就二值化得很完美。我发现很多人做视觉工作流时容易忽略预处理顺序结果就是二值图里全是碎块连通组件数多到离谱。我习惯的顺序是灰度化 → 滤波 → 二值化 → 形态学 → 连通。先说为什么要先滤波再二值化。如果原图带噪声直接二值化会把噪声变成前景白点后面做形态学处理虽然能去掉一部分但不如在灰度域先用中值滤波或高斯滤波把噪声压下去来得干净。对颗粒类场景我尤其推荐中值滤波它在保留边缘的同时对孤立噪点非常有效。二值化这一步也要根据光照情况选。光照均匀的环境下用Otsu全局阈值效率很高光照不均的情况下全局阈值会把暗处的目标背景全切没这种场合建议用自适应阈值或者顶帽变换我在下一章会展开讲。4.2 用开运算断开“藕断丝连”的桥接而不是直接腐蚀膨胀形态学处理是连通组件分析里最关键的一环很多人喜欢直接用腐蚀或者膨胀但腐蚀会把所有目标边界往里缩膨胀会把相邻目标粘得更紧。真正适合做“断桥”操作的是开运算也就是先腐蚀再膨胀。开运算的好处是它能把比结构元素小的桥接噪声断开同时让大目标的尺寸基本保持。做视觉工作流时我们要保证后续测量到的面积和边界是可信的所以“开运算不改变大目标”这条性质非常宝贵。结构元素的尺寸要按目标最小尺寸去估。如果颗粒最小直径是20像素开运算核取5到8像素是安全的如果核取到25像素那所有小目标都会被当成噪声腐蚀掉。我平时会写一个估算逻辑int minObjectDiameterPx 20; int kernelSize Math.Max(1, minObjectDiameterPx / 3); if (kernelSize % 2 0) kernelSize; Mat kernel Cv2.GetStructuringElement(MorphShapes.Ellipse, new Size(kernelSize, kernelSize));核的类型也有讲究。矩形核适合结构方正的PCB、芯片、砖块类目标椭圆核适合颗粒、细胞、焊点这类圆形目标。这个选择对连通结果的影响很多时候比调阈值更大。4.3 按面积和长宽比过滤统计组件之后怎么筛选目标连通组件分析完成之后你会拿到所有区域的统计信息但其中大部分可能不是你要的目标。常见情况是细小灰尘形成一个10像素的小点产品边缘反光形成一个又细又长的条状区域这些都要在业务层过滤掉。过滤条件我总结成三类面积过滤、宽高比过滤、位置过滤。面积过滤最简单设一个最小面积和一个最大面积小于最小值的通常是噪声大于最大值的可能是不小心把背景或大片异物包进来了。宽高比过滤适合排除长条形杂质比如目标是正方形宽高比在0.5到2之间才算正常超出就当作异物。位置过滤则是在已经知道产品大致位置的情况下使用只在感兴趣区域里收组件。值得提醒的是面积阈值不要拍脑袋定。最可靠的方法是从labels里统计一遍所有组件的面积分布画个直方图目标和噪声的面积往往有明显断层。对于这个断层的位置取中间值作为阈值比凭经验定一个数要稳得多。4.4 一个完整的目标计数Demo代码下面是我在某个计数类项目里用过的完整片段去掉了业务耦合的部分只保留核心工作流。它接收一张灰度图输出每个目标的矩形框、中心和面积。public class ComponentInfo { public int Id; public Rect BoundingRect; public int Area; public Point2d Center; } public ListComponentInfo Analyze(Mat gray, int minArea, int maxArea) { Mat binary new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu); int ksize 3; Mat kernel Cv2.GetStructuringElement(MorphShapes.Ellipse, new Size(ksize, ksize)); Cv2.MorphologyEx(binary, binary, MorphTypes.Open, kernel); int count Cv2.ConnectedComponentsWithStats( binary, out var labels, out var stats, out var centroids, PixelConnectivity.Connectivity8, MatType.CV_32S); var result new ListComponentInfo(); for (int i 1; i count; i) { int area stats.Atint(i, 4); if (area minArea || area maxArea) continue; result.Add(new ComponentInfo { Id i, BoundingRect new Rect( stats.Atint(i, 0), stats.Atint(i, 1), stats.Atint(i, 2), stats.Atint(i, 3)), Area area, Center new Point2d( centroids.Atdouble(i, 0), centroids.Atdouble(i, 1)) }); } return result; }返回的列表直接就是业务数据后面无论是绘制结果、写JSON还是控制运动机构都非常顺手。5. 实战翻车现场粘连、光照不均与噪声的处置链路5.1 场景一斜对角接触导致区域数明显少于实际数之前做一个零件数量统计的项目画面里有一批矩形零件摆放得比较随意。程序跑出来数量只有人工数的一半我当时第一反应是阈值没调好于是反复调Otsu的上下限但结果一直不对。后来我把labels映射成随机颜色看真相是有两个零件斜对角恰好贴在一起默认的8邻域把它们算成了一个区域。这类问题在矩形目标里太常见了因为矩形角点之间的接触只需要一个像素就足够连通。解决办法只有两步要么把连通性改成4要么在连通之前用核稍大一点的开运算断开接触点。我按照最小零件尺寸的1/4取了核开运算跑完之后区域数量瞬间恢复正常。这个坑给到我的教训是看到计数偏少的时候不要只怀疑阈值要先看labels图确认到底有没有区域合并。形态学处理往往比反复调阈值更高效。5.2 场景二照明不均导致断裂与合并同时出现光线不均匀是视觉项目里最常见的干扰源。全局二值化在亮区和暗区的分割点完全不一样结果亮区的目标被连成大片暗区的目标碎成好几块。这种情况用Otsu很难处理因为它只有一个阈值。我的处理方案分成两步。第一步二值化改用自适应阈值OpenCvSharp里对应AdaptiveThreshold它根据每个像素邻域的亮度动态算阈值对光照渐变很管用。第二步做完连通之后再按面积分布拆出真正的目标区域因为断裂和合并产生的碎块与巨型块面积数据会明显偏离正常目标的范围。自适应阈值本身会保留更多细节所以前面的形态学开运算千万不要省。这个场景里最容易犯的错是“为了修断裂不断缩小开运算核结果合并问题越来越严重”。要记住断裂和合并是两种相反的病需要同时处理用滤波解决噪声用开运算断桥用自适应阈值应对光照不均最终让连通组件前面的输入图尽量干净。5.3 场景三细小噪声形成“桥”把不相干区域连成一大片有时候画面里没有太多噪声但两个本来独立的目标之间有一条细微的灰线在二值化之后恰好变成了白色桥接。这个桥可能只有两三个像素宽却足以让两个目标变成一个连通组件。这种情况我在导线类、划线类产品上见过很多次。排查的时候先把labels图放大看如果合并区域的连接处明显有一条细长的“脖子”那基本就是桥接噪声。处理方式是开运算核的直径必须大于桥的宽度。桥是2像素就取3像素核桥是5像素就得取7像素左右的核。注意核不能无限放大一旦超过目标本身尺寸就把目标也腐蚀没了。对于那些桥比目标还要粗的严重粘连连通组件分析本身已经不太够用这种场景一般要上距离变换加分水岭属于后面章节的内容。最后的排查手段我用下面这个表格做了个总结分享给遇到类似问题的人现象可能原因处理方向组件数偏少明显有区域被合并斜对角接触或细桥连接换4邻域或用开运算断桥组件数偏多目标碎成多块光照不均、全局阈值失效用自适应阈值或顶帽变换出现大量极小区域灰度噪声被二值化放大先做中值/高斯滤波再用面积过滤目标区域之间大面积粘连前景桥太粗开运算无效后面章节的距离变换分水岭6. 同任务的两条路线connectedComponents 与 findContours 如何取舍6.1 findContours与connectedComponents的关系很多C#视觉开发者一开始学的是FindContours用它做目标边界提取后来又开始用ConnectedComponentsWithStats难免会困惑这两个函数看起来都能把目标分割出来到底有什么区别从原理上讲轮廓提取走的是“边界追踪”它从二值图里找到一个边界点然后沿着边界的邻接关系走一圈最终得到一组有序点集。连通组件分析走的是“区域标记”它给每个像素贴上所属区域的标签目标本身是一整块像素集合。轮廓是区域的表皮连通组件是区域的骨架加上整块肉两者描述的是同一个对象的两个维度。这也解释了一个现象同样的二值图FindContours非常在意边缘是否连续只要边界断个口一个目标就会被拆成多个轮廓ConnectedComponentsWithStats看的是像素连通关系即使边缘粗糙只要内部像素连在一起它仍然是同一个组件。在C#视觉工作流里处理大量不规则目标时连通组件明显更皮实。6.2 什么时候该用轮廓什么时候该用连通组件我的建议不是二选一而是按后续需求来选。如果业务只需要数量、质心、面积、外接矩形比如计数、密度统计、零件定位优先用连通组件一步到位代码量少出错率低。如果业务需要做形状匹配、多边形拟合、弧长计算、轮廓点序列输出那必须用FindContours因为连通组件输出的是标签矩阵不含有序的边界点。举个例子判断一个目标到底是圆还是方你需要的是边界点的形状信息这时候用轮廓提取然后算圆度、凸包、最小外接圆更合适。但要判断图里有多少个目标、每个目标在不在规定区域内用连通组件就够了不需要轮廓。6.3 两种方案结合使用的一个思路项目中我经常把两个函数配合起来用。先用ConnectedComponentsWithStats把每个目标切成独立组件再针对每一个组件的外接矩形区域单独做一次FindContours。这样既省掉了全图轮廓互相干扰的问题又能拿到每个目标的精确轮廓点。for (int i 1; i count; i) { Rect roi new Rect( stats.Atint(i, 0), stats.Atint(i, 1), stats.Atint(i, 2), stats.Atint(i, 3)); using (Mat single new Mat(binary, roi)) { Cv2.FindContours(single, out var contours, out var hierarchy, RetrievalModes.External, ContourApproximationModes.ApproxSimple); // contours[0] 就是这个目标在ROI里的轮廓点序列 } }这样做的好处是边界干净、归属明确缺点是要多做一次ROI拷贝。如果目标数量很大可以用labels矩阵生成掩膜避免频繁拷贝整块ROI。这个优化点放到工程化那部分讲。7. 工程化要点性能、内存与跨帧复用的经验7.1 避免每帧重新分配Mat视觉工作流一旦从离线图片变成在线视频性能就成了硬指标。最容易忽略的就是内存分配每帧图像都new三个Mat出来labels、stats、centroids用一次扔一次。C#的GC压力会被快速放大导致偶发卡顿。正确的做法是把这三个Mat对象定义在循环外面作为复用缓冲区。ConnectedComponentsWithStats每次调用会重新填充这些Mat的内容所以复用不会有脏数据问题。我的经验是只要不受多线程同时访问影响复用缓冲区能把内存分配次数降一个数量级。这一点在写OpenCvSharp代码时尤其重要因为OpenCV底层的Mat对象指向的是非托管内存C#的finalizer虽然会帮忙回收但频繁分配和释放仍然有风险。与其依赖GC不如从一开始就管好对象生命周期。7.2 大批量组件时的数据读取优化stats.Atint(i, j)逐次调用看起来简单但每调一次都要做类型转换和边界检查。当一张图里有几千个组件时这个开销会被放大到肉眼可见。我做过一次对比5000个组件用At逐个读取比批量拷贝慢好几倍。优化方法是把stats整体一次性拷贝到二维数组里再走普通数组遍历。OpenCvSharp的Mat提供了GetArray之类的批量读取接口具体调用要看版本但思路是一样的能批量就不要逐点。同理labels这种大尺寸矩阵也能用类似方式批量读取但一般不需要全图遍历只在定位到组件后按需访问即可。还需要注意labels是CV_32S类型每个元素占4字节1080p全图就是8MB多4K图接近35MB。如果同时处理多路相机内存会涨得很快此时尽量在全图范围内缩小ROI或者先降采样找大目标再回到原分辨率做精细处理。7.3 Release模式与多线程注意事项同一个连通组件代码Debug模式下跑得慢一开Release模式就快很多这是OpenCvSharp项目的常见现象。我这里要强调的不仅仅是编译配置还有C#里JIT的影响。第一次调用OpenCV函数会有冷启动开销所以性能测试至少要把前几帧预热掉。多线程方面OpenCV大部分图像处理函数本身线程安全只要每个线程用自己独立的Mat输入输出就没有问题。但labels、stats复用时要注意不要让两个线程同时往同一组Mat里写。我的做法是每个工作线程独立维护一组缓冲区线程之间只传业务结果不共享中间图像。这样既能吃到多核红利又不会出现数据互相覆盖的诡异问题。7.4 写在最后的实操体会如果你跟我一样是从轮廓那套方案转过来的刚开始看着labels图可能会觉得不习惯——每个区域只是一个整数编号好像信息量不大。但把它想成“给每个目标发工号牌”就很容易理解编号之后每个目标的位置、面积、边界都从这张工号牌上顺藤摸瓜拿得到。这套流程里我最想提醒的就是预处理顺序和连通性选择。很多现场问题看上去是连通组件函数不给力实际上是你没在前面把图像收拾干净。先确认labels映射图里的每个区域是否符合业务认知再谈参数调整绝大多数问题都能在这个环节被发现。把组件连通这一步吃透后面再接触分割和分类就会顺很多。 
长河君 · 2026/10/18 9:42:05 · 阅读 1.2k OpenCvSharp连通组件分析：从二值图到目标清单的完整实践
做C#视觉工作流的时候最绕不开的一个操作就是把图像里的目标“数清楚”。不管是零件计数、颗粒检测还是缺陷定位我们拿到的往往是一张二值图而真正需要的是一份清单图里有几个目标、每个在哪儿、尺寸多大。这个从“像素集合”变成“目标清单”的过程就是组件连通分析在OpenCV里对应ConnectedComponentsWithStats。很多人会先入为主去用找轮廓结果被断裂边缘折腾到怀疑人生实际上连通组件分析在很多场景下更直接、更稳。这一章我会从API用法、参数含义、工作流整合到现场调试一条线讲完适合正在用OpenCvSharp做视觉方案、想彻底搞懂组件连通怎么落地的朋友。1. 为什么视觉工作流里需要“组件连通”这一步1.1 二值图上的“区域”到底凭什么连在一起先回到最基础的概念。图像经过二值化之后每个像素不是0就是255白色代表前景目标黑色代表背景。现在的问题是一堆白色像素里哪些属于同一个目标答案就看它们是否“相邻”。上下左右相邻、斜对角也相邻凡是能通过这些邻接关系串在一起的白色像素就算同一个区域这个区域在OpenCV里叫连通组件。你可以把二值图想象成一片水域里的岛屿黑色背景是水面白色像素是露出水面的陆地。所谓连通组件分析就是给每一块独立的岛屿发一个编号再量一下每座岛的位置、占地面积和边界框。这个操作本身不涉及任何深度模型也不依赖花哨的特征描述纯粹靠像素之间的关系所以它很快也非常适合作视觉工作流的前置步骤。在C#里OpenCvSharp封装了这个能力核心函数是ConnectedComponentsWithStats。它和轮廓提取有联系但是出发点不同这一点我放在后面专门讲。现在你只需要记住连通组件输出的是一张标签图原图里所有属于同一个目标的像素会被标成同一个整数。1.2 连通组件分析在整个视觉工作流里的位置我接触过不少做视觉方案的朋友大家普遍容易走进一个误区拿到一幅图立刻想的是“先找边缘、再拟合轮廓”好像不经过轮廓就不好意思说自己在做视觉。实际上在工作流里连通的本质是区域分析它的作用是帮我们把“图像信息”转成“业务信息”。典型的流水线是预处理 → 二值化 → 形态学处理 → 连通组件分析 → 按业务规则过滤 → 输出坐标/数量/尺寸。连通组件处在中间偏后的位置它不负责识别目标是什么只负责把独立目标一个个切出来。切出来之后的事情比如筛掉太小的噪点、按宽高比排除长条异物、把每个目标的中心坐标发给机械臂全都以连通组件的结果为起点。所以这一章虽然只讲一个函数但它直接影响整套工作流的稳定性。如果这里分错了后面做匹配、分类、测量都会跟着错。2. C#环境下的连通组件API从二值图到Labels矩阵2.1 一个最小可跑的C#示例在OpenCvSharp里连通组件相关的API其实很简洁。下面这个示例是我在项目里最常用的起步写法输入一张灰度图输出所有组件的统计信息。using OpenCvSharp; // 1. 读图并转灰度 Mat src Cv2.ImRead(sample.png, ImreadModes.Grayscale); // 2. 二值化这里用Otsu自动阈值 Mat binary new Mat(); Cv2.Threshold(src, binary, 0, 255, ThresholdTypes.Otsu); // 3. 用开运算去掉细小的噪声和桥接 Mat kernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.MorphologyEx(binary, binary, MorphTypes.Open, kernel); // 4. 连通组件分析 int componentCount Cv2.ConnectedComponentsWithStats( binary, out var labels, out var stats, out var centroids, PixelConnectivity.Connectivity8, MatType.CV_32S); // 5. 遍历所有组件注意下标从1开始0是背景 for (int i 1; i componentCount; i) { int left stats.Atint(i, 0); int top stats.Atint(i, 1); int width stats.Atint(i, 2); int height stats.Atint(i, 3); int area stats.Atint(i, 4); double centerX centroids.Atdouble(i, 0); double centerY centroids.Atdouble(i, 1); // 这里就能拿到每个目标的矩形框、面积和质心了 }这段代码有很多细节值得展开。先说输出参数labels是标签图尺寸和输入图一样但每个像素存的不是灰度值而是它所属组件的编号stats是统计矩阵每行对应一个组件centroids是质心坐标。这三个输出物是后续所有逻辑的数据基础。2.2 stats与centroids里的每一列都代表什么stats是个二维矩阵第0行永远对应背景也就是标签值为0的像素。从第1行开始才是图像里真正的前景目标。每一行有5列含义是固定的列索引含义说明0Left外接矩形左上角X坐标单位像素1Top外接矩形左上角Y坐标单位像素2Width外接矩形宽度单位像素3Height外接矩形高度单位像素4Area组件实际包含的像素总数这里的Area不是外接矩形的宽乘高而是目标真实占用的像素数量。举个实际例子一个旋转45度的长条零件它的外接矩形可能很大但面积只占外接矩形的一小部分。视觉工作流里判断目标大小优先用Area边界框用来做绘制和裁剪。centroids是CV_64F类型的矩阵也就是double精度每一行两列分别是质心坐标X和Y。注意质心并不是简单的左上角加半宽半高而是按像素面积加权后的几何中心。对于不均匀形状或带有孔洞的目标质心和外接矩形中心往往有明显偏差做定位抓取时要用质心而不是矩形中心。2.3 读取标签数据时最容易踩的坑我第一次用这个函数的时候犯过一个挺蠢的错误直接把labels图显示出来结果整屏几乎全黑。这不是代码坏了而是labels里的像素值就是普通的整数编号比如3、17、208这些值作为灰度去显示绝大多数都在低灰度范围看起来就像一块黑布。要看labels图最好做颜色映射把每个编号映射成随机颜色这样既能直观看出区域划分效果也能快速发现“哪些目标被错误地连成了一个”。我在调试阶段习惯写一个小函数遍历labels像素按标签值赋予不同的BGR颜色。这一步虽然简单却能极大提升排查效率。另外要记住stats.Atint和centroids.Atdouble在目标数量少的时候完全够用但如果组件数量上千逐次At调用会显得很慢。后面工程化那一章我会专门说性能优化这里先留个印象。3. 连通性选择4邻域还是8邻域结果差一个数量级3.1 斜向相邻的物体怎么处理OpenCV里连通组件的邻域定义有两种4邻域只把上下左右四个方向视为相邻8邻域则把斜对角也算上。默认参数通常是8邻域但“默认”不一定是对的。我举个例子。画面里有两个矩形块位置刚好是左上角和右下角对角相碰接触面积只有一个像素。用8邻域判断这两个矩形会被当成同一个组件因为角上的像素斜着也能连过去。用4邻域判断斜对角不在邻域范围内它们就是两个独立组件。如果做的是零件计数这一个小细节就可能让统计结果直接少一半。视觉工作流里很多“粘连”问题并不是目标真的焊在一起了而是斜对角碰了一下。遇到这种情况第一步不是急着上距离变换和分水岭而是先试试把连通性从8改成4往往结果就很干净。3.2 如何根据形态特征反推合适的连通性那到底什么时候用8、什么时候用4我从实际项目里的几个规律出发给一个可参考的判断思路。如果你的目标是圆形颗粒、焊点、细胞这类“点头之交不容易出现”的对象用8邻域通常更符合人眼直觉稍微挨着一点就算连接逻辑上不容易漏。如果目标是矩形的PCB板、方形零件、带规则阵列的元件斜对角接触非常常见用4邻域会更稳。但还有更常见的做法不依赖连通性本身去解决斜碰问题而是在连通之前用形态学开运算把“角碰”的接触点处理掉。开运算的核稍微选大一点就能把斜角接触处的那个桥接像素断开然后继续用8邻域。这两种方案没有绝对优劣我通常是先用8邻域跑一版看labels映射图如果发现明显的斜角合并再决定换4还是加形态学处理。4. 从原始图像到组件过滤一整套可落地的C#视觉工作流4.1 二值化前的预处理顺序不能乱在实际项目中原材料图千差万别很少有一张图拿过来就二值化得很完美。我发现很多人做视觉工作流时容易忽略预处理顺序结果就是二值图里全是碎块连通组件数多到离谱。我习惯的顺序是灰度化 → 滤波 → 二值化 → 形态学 → 连通。先说为什么要先滤波再二值化。如果原图带噪声直接二值化会把噪声变成前景白点后面做形态学处理虽然能去掉一部分但不如在灰度域先用中值滤波或高斯滤波把噪声压下去来得干净。对颗粒类场景我尤其推荐中值滤波它在保留边缘的同时对孤立噪点非常有效。二值化这一步也要根据光照情况选。光照均匀的环境下用Otsu全局阈值效率很高光照不均的情况下全局阈值会把暗处的目标背景全切没这种场合建议用自适应阈值或者顶帽变换我在下一章会展开讲。4.2 用开运算断开“藕断丝连”的桥接而不是直接腐蚀膨胀形态学处理是连通组件分析里最关键的一环很多人喜欢直接用腐蚀或者膨胀但腐蚀会把所有目标边界往里缩膨胀会把相邻目标粘得更紧。真正适合做“断桥”操作的是开运算也就是先腐蚀再膨胀。开运算的好处是它能把比结构元素小的桥接噪声断开同时让大目标的尺寸基本保持。做视觉工作流时我们要保证后续测量到的面积和边界是可信的所以“开运算不改变大目标”这条性质非常宝贵。结构元素的尺寸要按目标最小尺寸去估。如果颗粒最小直径是20像素开运算核取5到8像素是安全的如果核取到25像素那所有小目标都会被当成噪声腐蚀掉。我平时会写一个估算逻辑int minObjectDiameterPx 20; int kernelSize Math.Max(1, minObjectDiameterPx / 3); if (kernelSize % 2 0) kernelSize; Mat kernel Cv2.GetStructuringElement(MorphShapes.Ellipse, new Size(kernelSize, kernelSize));核的类型也有讲究。矩形核适合结构方正的PCB、芯片、砖块类目标椭圆核适合颗粒、细胞、焊点这类圆形目标。这个选择对连通结果的影响很多时候比调阈值更大。4.3 按面积和长宽比过滤统计组件之后怎么筛选目标连通组件分析完成之后你会拿到所有区域的统计信息但其中大部分可能不是你要的目标。常见情况是细小灰尘形成一个10像素的小点产品边缘反光形成一个又细又长的条状区域这些都要在业务层过滤掉。过滤条件我总结成三类面积过滤、宽高比过滤、位置过滤。面积过滤最简单设一个最小面积和一个最大面积小于最小值的通常是噪声大于最大值的可能是不小心把背景或大片异物包进来了。宽高比过滤适合排除长条形杂质比如目标是正方形宽高比在0.5到2之间才算正常超出就当作异物。位置过滤则是在已经知道产品大致位置的情况下使用只在感兴趣区域里收组件。值得提醒的是面积阈值不要拍脑袋定。最可靠的方法是从labels里统计一遍所有组件的面积分布画个直方图目标和噪声的面积往往有明显断层。对于这个断层的位置取中间值作为阈值比凭经验定一个数要稳得多。4.4 一个完整的目标计数Demo代码下面是我在某个计数类项目里用过的完整片段去掉了业务耦合的部分只保留核心工作流。它接收一张灰度图输出每个目标的矩形框、中心和面积。public class ComponentInfo { public int Id; public Rect BoundingRect; public int Area; public Point2d Center; } public ListComponentInfo Analyze(Mat gray, int minArea, int maxArea) { Mat binary new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu); int ksize 3; Mat kernel Cv2.GetStructuringElement(MorphShapes.Ellipse, new Size(ksize, ksize)); Cv2.MorphologyEx(binary, binary, MorphTypes.Open, kernel); int count Cv2.ConnectedComponentsWithStats( binary, out var labels, out var stats, out var centroids, PixelConnectivity.Connectivity8, MatType.CV_32S); var result new ListComponentInfo(); for (int i 1; i count; i) { int area stats.Atint(i, 4); if (area minArea || area maxArea) continue; result.Add(new ComponentInfo { Id i, BoundingRect new Rect( stats.Atint(i, 0), stats.Atint(i, 1), stats.Atint(i, 2), stats.Atint(i, 3)), Area area, Center new Point2d( centroids.Atdouble(i, 0), centroids.Atdouble(i, 1)) }); } return result; }返回的列表直接就是业务数据后面无论是绘制结果、写JSON还是控制运动机构都非常顺手。5. 实战翻车现场粘连、光照不均与噪声的处置链路5.1 场景一斜对角接触导致区域数明显少于实际数之前做一个零件数量统计的项目画面里有一批矩形零件摆放得比较随意。程序跑出来数量只有人工数的一半我当时第一反应是阈值没调好于是反复调Otsu的上下限但结果一直不对。后来我把labels映射成随机颜色看真相是有两个零件斜对角恰好贴在一起默认的8邻域把它们算成了一个区域。这类问题在矩形目标里太常见了因为矩形角点之间的接触只需要一个像素就足够连通。解决办法只有两步要么把连通性改成4要么在连通之前用核稍大一点的开运算断开接触点。我按照最小零件尺寸的1/4取了核开运算跑完之后区域数量瞬间恢复正常。这个坑给到我的教训是看到计数偏少的时候不要只怀疑阈值要先看labels图确认到底有没有区域合并。形态学处理往往比反复调阈值更高效。5.2 场景二照明不均导致断裂与合并同时出现光线不均匀是视觉项目里最常见的干扰源。全局二值化在亮区和暗区的分割点完全不一样结果亮区的目标被连成大片暗区的目标碎成好几块。这种情况用Otsu很难处理因为它只有一个阈值。我的处理方案分成两步。第一步二值化改用自适应阈值OpenCvSharp里对应AdaptiveThreshold它根据每个像素邻域的亮度动态算阈值对光照渐变很管用。第二步做完连通之后再按面积分布拆出真正的目标区域因为断裂和合并产生的碎块与巨型块面积数据会明显偏离正常目标的范围。自适应阈值本身会保留更多细节所以前面的形态学开运算千万不要省。这个场景里最容易犯的错是“为了修断裂不断缩小开运算核结果合并问题越来越严重”。要记住断裂和合并是两种相反的病需要同时处理用滤波解决噪声用开运算断桥用自适应阈值应对光照不均最终让连通组件前面的输入图尽量干净。5.3 场景三细小噪声形成“桥”把不相干区域连成一大片有时候画面里没有太多噪声但两个本来独立的目标之间有一条细微的灰线在二值化之后恰好变成了白色桥接。这个桥可能只有两三个像素宽却足以让两个目标变成一个连通组件。这种情况我在导线类、划线类产品上见过很多次。排查的时候先把labels图放大看如果合并区域的连接处明显有一条细长的“脖子”那基本就是桥接噪声。处理方式是开运算核的直径必须大于桥的宽度。桥是2像素就取3像素核桥是5像素就得取7像素左右的核。注意核不能无限放大一旦超过目标本身尺寸就把目标也腐蚀没了。对于那些桥比目标还要粗的严重粘连连通组件分析本身已经不太够用这种场景一般要上距离变换加分水岭属于后面章节的内容。最后的排查手段我用下面这个表格做了个总结分享给遇到类似问题的人现象可能原因处理方向组件数偏少明显有区域被合并斜对角接触或细桥连接换4邻域或用开运算断桥组件数偏多目标碎成多块光照不均、全局阈值失效用自适应阈值或顶帽变换出现大量极小区域灰度噪声被二值化放大先做中值/高斯滤波再用面积过滤目标区域之间大面积粘连前景桥太粗开运算无效后面章节的距离变换分水岭6. 同任务的两条路线connectedComponents 与 findContours 如何取舍6.1 findContours与connectedComponents的关系很多C#视觉开发者一开始学的是FindContours用它做目标边界提取后来又开始用ConnectedComponentsWithStats难免会困惑这两个函数看起来都能把目标分割出来到底有什么区别从原理上讲轮廓提取走的是“边界追踪”它从二值图里找到一个边界点然后沿着边界的邻接关系走一圈最终得到一组有序点集。连通组件分析走的是“区域标记”它给每个像素贴上所属区域的标签目标本身是一整块像素集合。轮廓是区域的表皮连通组件是区域的骨架加上整块肉两者描述的是同一个对象的两个维度。这也解释了一个现象同样的二值图FindContours非常在意边缘是否连续只要边界断个口一个目标就会被拆成多个轮廓ConnectedComponentsWithStats看的是像素连通关系即使边缘粗糙只要内部像素连在一起它仍然是同一个组件。在C#视觉工作流里处理大量不规则目标时连通组件明显更皮实。6.2 什么时候该用轮廓什么时候该用连通组件我的建议不是二选一而是按后续需求来选。如果业务只需要数量、质心、面积、外接矩形比如计数、密度统计、零件定位优先用连通组件一步到位代码量少出错率低。如果业务需要做形状匹配、多边形拟合、弧长计算、轮廓点序列输出那必须用FindContours因为连通组件输出的是标签矩阵不含有序的边界点。举个例子判断一个目标到底是圆还是方你需要的是边界点的形状信息这时候用轮廓提取然后算圆度、凸包、最小外接圆更合适。但要判断图里有多少个目标、每个目标在不在规定区域内用连通组件就够了不需要轮廓。6.3 两种方案结合使用的一个思路项目中我经常把两个函数配合起来用。先用ConnectedComponentsWithStats把每个目标切成独立组件再针对每一个组件的外接矩形区域单独做一次FindContours。这样既省掉了全图轮廓互相干扰的问题又能拿到每个目标的精确轮廓点。for (int i 1; i count; i) { Rect roi new Rect( stats.Atint(i, 0), stats.Atint(i, 1), stats.Atint(i, 2), stats.Atint(i, 3)); using (Mat single new Mat(binary, roi)) { Cv2.FindContours(single, out var contours, out var hierarchy, RetrievalModes.External, ContourApproximationModes.ApproxSimple); // contours[0] 就是这个目标在ROI里的轮廓点序列 } }这样做的好处是边界干净、归属明确缺点是要多做一次ROI拷贝。如果目标数量很大可以用labels矩阵生成掩膜避免频繁拷贝整块ROI。这个优化点放到工程化那部分讲。7. 工程化要点性能、内存与跨帧复用的经验7.1 避免每帧重新分配Mat视觉工作流一旦从离线图片变成在线视频性能就成了硬指标。最容易忽略的就是内存分配每帧图像都new三个Mat出来labels、stats、centroids用一次扔一次。C#的GC压力会被快速放大导致偶发卡顿。正确的做法是把这三个Mat对象定义在循环外面作为复用缓冲区。ConnectedComponentsWithStats每次调用会重新填充这些Mat的内容所以复用不会有脏数据问题。我的经验是只要不受多线程同时访问影响复用缓冲区能把内存分配次数降一个数量级。这一点在写OpenCvSharp代码时尤其重要因为OpenCV底层的Mat对象指向的是非托管内存C#的finalizer虽然会帮忙回收但频繁分配和释放仍然有风险。与其依赖GC不如从一开始就管好对象生命周期。7.2 大批量组件时的数据读取优化stats.Atint(i, j)逐次调用看起来简单但每调一次都要做类型转换和边界检查。当一张图里有几千个组件时这个开销会被放大到肉眼可见。我做过一次对比5000个组件用At逐个读取比批量拷贝慢好几倍。优化方法是把stats整体一次性拷贝到二维数组里再走普通数组遍历。OpenCvSharp的Mat提供了GetArray之类的批量读取接口具体调用要看版本但思路是一样的能批量就不要逐点。同理labels这种大尺寸矩阵也能用类似方式批量读取但一般不需要全图遍历只在定位到组件后按需访问即可。还需要注意labels是CV_32S类型每个元素占4字节1080p全图就是8MB多4K图接近35MB。如果同时处理多路相机内存会涨得很快此时尽量在全图范围内缩小ROI或者先降采样找大目标再回到原分辨率做精细处理。7.3 Release模式与多线程注意事项同一个连通组件代码Debug模式下跑得慢一开Release模式就快很多这是OpenCvSharp项目的常见现象。我这里要强调的不仅仅是编译配置还有C#里JIT的影响。第一次调用OpenCV函数会有冷启动开销所以性能测试至少要把前几帧预热掉。多线程方面OpenCV大部分图像处理函数本身线程安全只要每个线程用自己独立的Mat输入输出就没有问题。但labels、stats复用时要注意不要让两个线程同时往同一组Mat里写。我的做法是每个工作线程独立维护一组缓冲区线程之间只传业务结果不共享中间图像。这样既能吃到多核红利又不会出现数据互相覆盖的诡异问题。7.4 写在最后的实操体会如果你跟我一样是从轮廓那套方案转过来的刚开始看着labels图可能会觉得不习惯——每个区域只是一个整数编号好像信息量不大。但把它想成“给每个目标发工号牌”就很容易理解编号之后每个目标的位置、面积、边界都从这张工号牌上顺藤摸瓜拿得到。这套流程里我最想提醒的就是预处理顺序和连通性选择。很多现场问题看上去是连通组件函数不给力实际上是你没在前面把图像收拾干净。先确认labels映射图里的每个区域是否符合业务认知再谈参数调整绝大多数问题都能在这个环节被发现。把组件连通这一步吃透后面再接触分割和分类就会顺很多。