简介本资源是一个基于C#与OpenCvSharp实现的文字图像预处理项目面向图像处理初学者、OCR开发人员及文档数字化工程师聚焦于扫描件或低质量文字图像中干扰线条如表格线、划线、边框的精准去除显著提升后续OCR识别准确率。压缩包共94个文件包含10个核心C#源码文件如frmMain.cs、1个Visual Studio解决方案.sln、6个可执行程序.exe及配套DLL库如OpenCvSharp.dll、OpenCvSharpExtern.dll另有配置文件.config、资源文件.resx、.png、.jpg和调试符号.pdb整体35.46MB结构完整开箱即用。已有163人学习下载。读者可直接运行Demo程序观察线条去除前后对比效果深入理解二值化、形态学腐蚀/膨胀、霍夫直线检测、连通域分析等关键算法在C#中的工程化实现并参考完整项目目录组织方式与OpenCvSharp API调用范式快速复用于票据识别、古籍修复、试卷去线等实际场景。1. 先看问题本质线条和文字在二值图里到底差在哪做C#图像处理的同行应该都遇到过这个需求扫描件或者截图里有一堆横线、下划线、表格线压在文字上直接丢给OCR识别结果断字、粘连、误识别一堆准确率掉到没法看。有人说直接把线抠掉不就行了真上手试过就知道这条路没那么好走。先说结论线条不是不能抠而是不能硬抠。用像素填充或单纯阈值把线条区域涂白会在文字笔画上留下大量白色断口。文字横和竖交叉的地方线条一盖过去笔画就缺了一段后续识别直接崩。所以这个项目真正要解决的不是把线去掉而是去线的同时尽量保留文字笔画。先看图里的二值化之后到底发生了什么事。假设一张白底黑字的扫描票据上面有一根横穿数字的粗下划线。Otsu二值化之后文字是黑像素0线条也是黑像素0它们连成一片。如果直接按坐标删掉线条所在行等于把和线条重叠的笔画一起删了这肯定不行。问题的本质在于线条和文字在像素灰度层面很相似但在几何结构上差异非常大。线条通常是一个方向上连续延伸的长条形结构宽度相对均匀长度可以横跨整个图而文字笔画虽然也有方向性但笔画长度有上限并且存在大量端点、交叉点、拐角。这个结构差异就是我们可以下手的地方——用形态学操作把线条挑出来再用图像修复把线条区域补回合理的文字背景。很多人第一反应是用霍夫变换检测直线然后画线覆盖掉。这个思路对于干净图像上的单根线条有效但表格场景下线条多、长短不一、还有倾斜霍夫变换的调参能让你调一整天。更麻烦的是检出直线之后你不知道该填充什么内容填白色会断字填周围颜色会糊成一片。所以这个项目里我走的是另一条路形态学提取线条掩膜 图像修复Inpainting这也是目前去线类预处理里最稳、最可控的方案。2. 两条路线的取舍先看哪种方案不会把文字搞坏实际调研下来业界做去线留字主要有三个方向形态学方案、频率域方案和深度学习方法。展开说说各自的适用场景和缺陷这样你在自己的项目里选型时心里有数。方案原理优点缺点适用场景形态学开运算提取线条 Inpaint用长条形结构元检测方向性线条生成掩膜后用邻域像素重建实现简单、可控性强、不需要训练数据、OpenCvSharp原生支持对斜线、曲线、非均匀宽度线条需要多组核横竖线为主、印刷体、扫描文档频率域滤波傅里叶变换把周期性横线在频谱上对应的亮斑滤除对规律的印刷底纹、横线纹理效果极好只对周期性强、重复性高的纹理有效单根离散线无效扫描摩尔纹、网点底纹深度学习语义分割训练网络把线条和文字分开泛化能力最强斜线曲线都能处理需要标注数据、训练成本高、部署体积大手写笔记、复杂背景、线条形态不固定你会发现在处理表单、票据、试卷扫描件这类最常见的业务场景时形态学 Inpaint 是投入产出比最高的组合。原因有二。第一这些图像里的线条绝大多数是印刷的横线、竖线和表格线方向规则、宽度稳定正好是形态学最擅长处理的对象。第二OpenCvSharp 里MorphologyEx和Inpaint都是原生封装的接口几十行代码就能跑起来不需要引额外的重量级依赖。那形态学为什么能区分线条和文字这个问题我用一个不严谨但容易懂的类比来解释。开运算可以理解为拿一个指定形状的刷子去图像里滚动比对形状匹配的留下不匹配的抹掉。当刷子是一根横着的长条时图像里横跨整行的线条和刷子高度匹配会被保留文字里的竖笔画和这个横条刷子在形态上差太多会被当作噪声清除掉。这就是形态学提取线条的基本原理。不过形态学方案有一个先天短板提取出来的线条掩膜只能告诉你哪些区域像线条并不能直接恢复被线条遮住的文字。所以必须搭配Inpaint图像修复来解决补什么的问题。Inpaint会用掩膜周围的像素信息按照一定的扩散逻辑估计出被遮住区域应该有的内容。对于压在文字上的细线条修复算法往往能根据笔画上下两端的走势把断掉的地方补回去视觉上看起来就像线条不存在一样。3. 用 OpenCvSharp 实现一套完整的去线流程这一节是核心直接给出能跑的代码。我的开发环境是 .NET 8 OpenCvSharp4.Windows 4.9.0NuGet 安装这两个包就行OpenCvSharp4 OpenCvSharp4.Windows3.1 预处理到底该注意什么第一步读取图像建议用灰度模式读入using var gray Cv2.ImRead(input.png, ImreadModes.Grayscale);接下来二值化。这里有一个非常隐蔽的坑如果你的图是白底黑字那文字和线条在灰度图上是暗像素背景是亮像素。做形态学提取线条时我们期望目标对象是白色前景所以必须做反转二值化。用 Otsu 自动找阈值using var binary new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu | ThresholdTypes.BinaryInv);BinaryInv这一下把黑字变成了白色像素255白底变成了黑色0。为什么要这样因为形态学开运算提取线条时前景必须是白色核的膨胀和腐蚀都是针对前景像素计算的。如果你用了Binary而不是BinaryInv提取出来的线条会是背景里的白色裂纹完全不是一回事。这个顺序我在代码评审里见到好几个人劈叉过。如果图像存在光照不均比如扫描件中间亮、边缘暗Otsu 的全局阈值会失效。这时可以换成自适应阈值using var binary new Mat(); Cv2.AdaptiveThreshold(gray, binary, 255, AdaptiveThresholdTypes.GaussianC, ThresholdTypes.BinaryInv, blockSize: 51, C: 10);blockSize决定局部窗口大小一般取 41 到 61 之间取奇数。这块我放到后面参数怎么调的章节细说。3.2 用长条形核提取横线和竖线形态学提取线条的关键在于核的设计。要提取横向线条就构造一个很长但只有一行高的矩形核int lineLength Math.Max(gray.Cols, gray.Rows) / 15; using var horizontalKernel Cv2.GetStructuringElement( MorphShapes.Rect, new Size(lineLength, 1)); using var horizontalLines new Mat(); Cv2.MorphologyEx(binary, horizontalLines, MorphTypes.Open, horizontalKernel);Size(lineLength, 1)就是一个横着的长条。MorphTypes.Open是开运算即先腐蚀后膨胀。开运算的作用是把图像中无法完整容纳这个长条核的前景结构全部抹掉只留下和核的形状方向一致的长横条。文字里的横笔画虽然也是横向的但它们的长度远小于这个核长腐蚀阶段就会被抹掉所以剩下的基本就是贯穿全图的横线。垂直方向同理只把核旋转 90 度using var verticalKernel Cv2.GetStructuringElement( MorphShapes.Rect, new Size(1, lineLength)); using var verticalLines new Mat(); Cv2.MorphologyEx(binary, verticalLines, MorphTypes.Open, verticalKernel);得到横线和竖线两张掩膜图之后用按位或合成一张总线条掩膜using var lines new Mat(); Cv2.BitwiseOr(horizontalLines, verticalLines, lines);这里我用BitwiseOr而不是AddWeighted避免两幅图重叠区域出现像素值相加超过 255 的问题。合成后lines图中白色的地方就是识别出来的线条区域。3.3 掩膜后处理与 Inpaint 修复直接拿lines去做修复效果往往不够好。因为二值化边缘会有锯齿、线条和文字粘连处会留下小毛刺掩膜可能有少量空洞。先用一次膨胀把掩膜边缘扩大一点让修复区域覆盖更完整using var kernel3 Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.Dilate(lines, lines, kernel3, iterations: 1);iterations: 1是经验值膨胀太多会把文字笔画也吞进去。对大多数扫描件来说膨胀 1 次刚好能把线条边缘的过渡区包住又不会扩散到文字上。然后读取彩色原图执行修复using var color Cv2.ImRead(input.png, ImreadModes.Color); using var result new Mat(); Cv2.Inpaint(color, lines, result, inpaintRadius: 3, InpaintMethod.Telea);inpaintRadius是修复算法的邻域半径数值越大修复区域向外扩展得越远但图像越模糊。3 到 5 是比较稳妥的区间后面我会给出根据线条宽度确定的估算公式。整套代码串起来就是一个干净的静态方法public static Mat RemoveLines(string imagePath, double kernelLengthFactor 15.0) { using var gray Cv2.ImRead(imagePath, ImreadModes.Grayscale); using var binary new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu | ThresholdTypes.BinaryInv); int lineLength (int)Math.Max(gray.Cols, gray.Rows) / kernelLengthFactor; using var hKernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(lineLength, 1)); using var vKernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(1, lineLength)); using var hLines new Mat(); using var vLines new Mat(); Cv2.MorphologyEx(binary, hLines, MorphTypes.Open, hKernel); Cv2.MorphologyEx(binary, vLines, MorphTypes.Open, vKernel); using var lines new Mat(); Cv2.BitwiseOr(hLines, vLines, lines); using var kernel3 Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.Dilate(lines, lines, kernel3); var color Cv2.ImRead(imagePath, ImreadModes.Color); var result new Mat(); Cv2.Inpaint(color, lines, result, 3, InpaintMethod.Telea); return result; }使用的时候using var cleaned RemoveLines(scan.png); Cv2.ImWrite(scan_clean.png, cleaned);跑通这个 Demo 大概只需要十分钟但到这一步只是能跑。真正让人头疼的是参数怎么调、各种奇怪图像怎么应对这些才是决定这个工具能不能真的上线的关键。4. 参数不是玄学从图像尺寸和线条宽度反推我见过不少人在形态学方案上栽跟头栽的原因几乎都集中在参数上。大部分博客给的是lineLength col / 30这种拍脑袋经验值。这套值在 demo 图上可能有效换一张图就完全失灵。原因是形态学核的长度直接决定了线条提取的灵敏度它应该由线条本身的特点决定而不是由图像尺寸的固定比例决定。这里分解成两个参数来看。4.1 核长度必须大于线段最大断裂间隙一个矩形核要能完整容纳一条线才能在线条被腐蚀掉之后通过膨胀恢复出来。也就是说核的长度必须大于线条上最宽的那个缺口。扫描图像里线条偶尔会有噪点、断点如果核长 30 像素而线条中间有一处 40 像素的缺损开运算就会把这根线从中间断成两截后续 Inpaint 就补不干净。更合理的策略是核长度 图像长边 / 12 到 / 18 之间。对一个 1200 x 800 的扫描件除以 15 大约是 80 像素。这个长度足以覆盖大部分 2~3 像素宽线条上的小断裂又不会长到把文字里的长横笔画误判成线条。具体可以在 12 到 20 之间二分搜索哪个值让 Inpaint 之后文字断笔最少就用哪个。4.2 核宽度决定是否误伤文字笔画Size(lineLength, 1)里的第二个参数1表示核只有一行高。这个值对线条提取影响极大。真实场景里线条宽度可能从 1 像素到 10 像素不等如果是细下划线宽 1~2 像素核宽 1 没问题如果是表格边框线打印出来可能有 3~5 像素核宽 1 会导致开运算后线条残缺如果核宽大于线条实际宽度就会把和线条重叠的文字笔画一起包进去产生挖掉一块肉的效果。所以处理前先统计线条的实际宽度方法很简单在二值图上遍历线条所在行的黑色像素连续段长度取众数。或者目测一下直接用Size(lineLength, 3)这种保守值。我自己的经验是先按宽度 1 跑一次看结果里线条是否断断了就把核宽加到 3 或 5直到横线整体连续同时文字没有被明显掏空。4.3 Inpaint 半径与膨胀次数inpaintRadius取多少和线条宽度强相关。如果线条宽 3 像素掩膜膨胀 1 次后修复区域向外扩了大概 1 像素总修复区域宽约 5 像素此时半径 3 足够。半径太大会让修复结果出现明显的模糊斑块太小则补不齐笔画。推荐经验公式inpaintRadius ≈ (lineWidth 2) / 2如果线条宽度为 3半径取 3宽度为 5半径取 4。InpaintMethod我默认用Telea它是基于快速行进法的对细线条修复速度快、边缘过渡自然。另一个选项NSNavier-Stokes对宽区域的修复结果更平滑但速度慢文字笔画交叉处容易出现糊成一片的情况。我的建议是细线条用 Telea宽线条或者大块污渍用 NS但大部分场景 Telea 就够了。4.4 一个自动估算参数的暴力搜索思路如果参数实在难调别死磕理论推导直接用脚本搜。你可以写一个循环让lineLength取 20、40、60、80、100kernelWidth取 1、3、5分别跑一遍结果图存成序列图人眼选效果最好的。或者更高级一点把结果图重新二值化之后统计黑像素的连通域数量——文字笔画断裂越多连通域数量越多选连通域数量最少的那组参数。这个思路虽然土但在做批量预处理时非常省力。5. 实战中的疑难杂症斜线、阴影、彩色线条、断笔到这一步标准横竖线条已经能处理得比较干净了。但真实项目里永远不按教科书出牌我挑了四个高频问题展开讲讲每个都是从实际项目里撞出来的。5.1 斜线怎么提取两组对角核开运算的核是矩形的只能沿横、竖两个方向检测。遇到 45 度角的删除线或者斜体文字上的划线横竖核基本无能为力。处理方式很直接加两组对角方向的长条形核。OpenCvSharp 里没有直接生成斜向结构元的 API但可以通过GetStructuringElement配合旋转来构造。或者更简单的方法先把图像旋转 45 度提取线条再旋转回来最后把掩膜对齐到原图。这个方法听起来笨但胜在稳定配合仿射变换的 API 实现起来也不复杂。要注意的是对角核的宽度和长度设置要更保守因为文字笔画中斜向成分比如撇捺很多核太短会把撇捺当成线条核太长则完全提取不到斜线。我一般取核长为图像短边的 1/8宽度还是 3并且会对提取到的掩膜做一次连通域面积过滤去掉面积过小的碎片。5.2 光照不均用自适应阈值救场有一次处理一批历史档案的扫描件纸张年代久远中间泛黄两侧偏暗。Otsu 阈值在这类图上表现非常差中间的文字被砍断两侧的背景没分干净形态学提取出来的线条到处都是断裂口。当时切到AdaptiveThreshold后问题立刻缓解。自适应阈值的关键参数是blockSize。这个窗口必须大于线条宽度的两倍同时小于文字笔画之间的典型间距。对于 300 DPI 的 A4 扫描件字体一般是 10~12 磅笔画宽度 2~3 像素blockSize取 51、C取 10 是比较合理的起点。C是自适应阈值时减去的常数越大越不容易把阴影误判为前景但太大又会把较淡的文字整个丢掉。5.3 彩色线条先做通道拆分如果线条是红色的而你直接转灰度再二值化红线和黑字在灰度图上可能亮度接近很不好分。这时应该先利用颜色信息。方法一在 RGB 三个通道上分别跑一遍提取流程哪个通道的线条掩膜最干净就选哪个。红色线条通常 B 通道压得很暗和黑字对比度较低反而容易提取。方法二转换到 HSV 颜色空间通过Cv2.InRange按H通道的颜色范围圈出红色区域生成掩膜。彩色文字识别场景下方法一更省事因为不需要预先知道线条颜色方法二适合线条颜色固定且明确的产品需求。5.4 文字与线条交叉处的断笔问题这是整个流程里最无解但也最能体现调优水平的地方。形态学提取线条时文字笔画和线条连成一片开运算后线条保留下来了但笔画在线条上的那一小段也被当成了线条的一部分。Inpaint 虽说可以重建但如果笔画被吃掉的长度太大周围的像素信息不足以推断出原来的笔画走向断笔就出现了。遇到这种情况我的操作顺序是这样的先不要急着上 Inpaint而是把掩膜lines在交叉点区域做一次局部腐蚀把线条掩膜在文字笔画附近收缩一点。可以用一个简单办法实现对lines做DistanceTransform小于 3 的区域保留大于 3 的区域收缩一圈。这样修复区域缩小文字笔画被误伤的几率就小了。也可以换一个思路先提取线条然后在原图上把线条区域涂成背景色再多迭代几次中值滤波填补空洞。这种方法处理交叉点断笔的效果不如 Inpaint 自然但胜在速度快适合对 OCR 结果要求不那么高的场景。6. 把这套逻辑接进真实 OCR 管线后的经验最后聊聊这个去线工具放到完整识别链路上的位置以及我在几个项目里收获的工程经验。6.1 放在预处理哪个环节通常 OCR 管线的顺序是图像读取 - 去噪 - 倾斜矫正 -去线- 二值化 - 版面分析 - 文字识别。去线要在倾斜矫正之后因为倾斜的表格线经过旋转后方向才规整形态学核才能对齐。如果先去了线再做倾斜矫正矫正过程中插值算法会把残存的线条边缘虚化导致二值化后出现一条模糊的影子反而影响识别。6.2 批量处理时的输出与监控批量处理几十万张票据的时候不要只输出一张结果图就完事。我在工程里会同时输出三份中间产物原图、线条掩膜、结果图。掩膜是用来排查问题的关键只要发现识别率异常先看掩膜——是线条没提干净还是文字笔画被误伤一目了然。这个习惯帮我省了大量调参时间。6.3 性能优化方向Inpaint算法本身不慢但在大图4000 x 3000上逐张处理还是挺吃 CPU 的。如果对速度敏感有两个优化方向。第一Inpaint 前把掩膜外的区域用ROI感兴趣区域裁出来只在含线条的小块上做修复性能能提升一个量级第二如果线条掩膜覆盖面积很小可以先用Cv2.Resize缩小图像做修复再放大回原尺寸视觉差异可以忽略。还有一点要提醒OpenCvSharp 里的Mat对象要记得及时Dispose。整个去线流程会产生二值图、横线图、竖线图、掩膜图、结果图至少五六个Mat长循环里不释放内存跑几百张图就会出现OutOfMemory。用using或者using var是最省心的做法。我最早接触这个需求时也想过直接上深度学习后来发现一套形态学 Inpaint 的组合处理印刷体文档能达到 95% 以上的效果代码不到一百行部署没有任何额外依赖。对大部分业务系统来说这就是性价比最高的解。你如果手头正好有类似的去线需求可以先把我上面这段代码跑通再根据自己图像的特点调核长度和膨胀次数遇到斜线就加对角核遇到光照不均就切自适应阈值。动手试两张图你会比看十篇理论文章收获更多。本文还有配套的精品资源点击获取 C#图像处理实战：利用OpenCvSharp形态学与Inpainting去除扫描件线条，提升OCR识别率
简介本资源是一个基于C#与OpenCvSharp实现的文字图像预处理项目面向图像处理初学者、OCR开发人员及文档数字化工程师聚焦于扫描件或低质量文字图像中干扰线条如表格线、划线、边框的精准去除显著提升后续OCR识别准确率。压缩包共94个文件包含10个核心C#源码文件如frmMain.cs、1个Visual Studio解决方案.sln、6个可执行程序.exe及配套DLL库如OpenCvSharp.dll、OpenCvSharpExtern.dll另有配置文件.config、资源文件.resx、.png、.jpg和调试符号.pdb整体35.46MB结构完整开箱即用。已有163人学习下载。读者可直接运行Demo程序观察线条去除前后对比效果深入理解二值化、形态学腐蚀/膨胀、霍夫直线检测、连通域分析等关键算法在C#中的工程化实现并参考完整项目目录组织方式与OpenCvSharp API调用范式快速复用于票据识别、古籍修复、试卷去线等实际场景。1. 先看问题本质线条和文字在二值图里到底差在哪做C#图像处理的同行应该都遇到过这个需求扫描件或者截图里有一堆横线、下划线、表格线压在文字上直接丢给OCR识别结果断字、粘连、误识别一堆准确率掉到没法看。有人说直接把线抠掉不就行了真上手试过就知道这条路没那么好走。先说结论线条不是不能抠而是不能硬抠。用像素填充或单纯阈值把线条区域涂白会在文字笔画上留下大量白色断口。文字横和竖交叉的地方线条一盖过去笔画就缺了一段后续识别直接崩。所以这个项目真正要解决的不是把线去掉而是去线的同时尽量保留文字笔画。先看图里的二值化之后到底发生了什么事。假设一张白底黑字的扫描票据上面有一根横穿数字的粗下划线。Otsu二值化之后文字是黑像素0线条也是黑像素0它们连成一片。如果直接按坐标删掉线条所在行等于把和线条重叠的笔画一起删了这肯定不行。问题的本质在于线条和文字在像素灰度层面很相似但在几何结构上差异非常大。线条通常是一个方向上连续延伸的长条形结构宽度相对均匀长度可以横跨整个图而文字笔画虽然也有方向性但笔画长度有上限并且存在大量端点、交叉点、拐角。这个结构差异就是我们可以下手的地方——用形态学操作把线条挑出来再用图像修复把线条区域补回合理的文字背景。很多人第一反应是用霍夫变换检测直线然后画线覆盖掉。这个思路对于干净图像上的单根线条有效但表格场景下线条多、长短不一、还有倾斜霍夫变换的调参能让你调一整天。更麻烦的是检出直线之后你不知道该填充什么内容填白色会断字填周围颜色会糊成一片。所以这个项目里我走的是另一条路形态学提取线条掩膜 图像修复Inpainting这也是目前去线类预处理里最稳、最可控的方案。2. 两条路线的取舍先看哪种方案不会把文字搞坏实际调研下来业界做去线留字主要有三个方向形态学方案、频率域方案和深度学习方法。展开说说各自的适用场景和缺陷这样你在自己的项目里选型时心里有数。方案原理优点缺点适用场景形态学开运算提取线条 Inpaint用长条形结构元检测方向性线条生成掩膜后用邻域像素重建实现简单、可控性强、不需要训练数据、OpenCvSharp原生支持对斜线、曲线、非均匀宽度线条需要多组核横竖线为主、印刷体、扫描文档频率域滤波傅里叶变换把周期性横线在频谱上对应的亮斑滤除对规律的印刷底纹、横线纹理效果极好只对周期性强、重复性高的纹理有效单根离散线无效扫描摩尔纹、网点底纹深度学习语义分割训练网络把线条和文字分开泛化能力最强斜线曲线都能处理需要标注数据、训练成本高、部署体积大手写笔记、复杂背景、线条形态不固定你会发现在处理表单、票据、试卷扫描件这类最常见的业务场景时形态学 Inpaint 是投入产出比最高的组合。原因有二。第一这些图像里的线条绝大多数是印刷的横线、竖线和表格线方向规则、宽度稳定正好是形态学最擅长处理的对象。第二OpenCvSharp 里MorphologyEx和Inpaint都是原生封装的接口几十行代码就能跑起来不需要引额外的重量级依赖。那形态学为什么能区分线条和文字这个问题我用一个不严谨但容易懂的类比来解释。开运算可以理解为拿一个指定形状的刷子去图像里滚动比对形状匹配的留下不匹配的抹掉。当刷子是一根横着的长条时图像里横跨整行的线条和刷子高度匹配会被保留文字里的竖笔画和这个横条刷子在形态上差太多会被当作噪声清除掉。这就是形态学提取线条的基本原理。不过形态学方案有一个先天短板提取出来的线条掩膜只能告诉你哪些区域像线条并不能直接恢复被线条遮住的文字。所以必须搭配Inpaint图像修复来解决补什么的问题。Inpaint会用掩膜周围的像素信息按照一定的扩散逻辑估计出被遮住区域应该有的内容。对于压在文字上的细线条修复算法往往能根据笔画上下两端的走势把断掉的地方补回去视觉上看起来就像线条不存在一样。3. 用 OpenCvSharp 实现一套完整的去线流程这一节是核心直接给出能跑的代码。我的开发环境是 .NET 8 OpenCvSharp4.Windows 4.9.0NuGet 安装这两个包就行OpenCvSharp4 OpenCvSharp4.Windows3.1 预处理到底该注意什么第一步读取图像建议用灰度模式读入using var gray Cv2.ImRead(input.png, ImreadModes.Grayscale);接下来二值化。这里有一个非常隐蔽的坑如果你的图是白底黑字那文字和线条在灰度图上是暗像素背景是亮像素。做形态学提取线条时我们期望目标对象是白色前景所以必须做反转二值化。用 Otsu 自动找阈值using var binary new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu | ThresholdTypes.BinaryInv);BinaryInv这一下把黑字变成了白色像素255白底变成了黑色0。为什么要这样因为形态学开运算提取线条时前景必须是白色核的膨胀和腐蚀都是针对前景像素计算的。如果你用了Binary而不是BinaryInv提取出来的线条会是背景里的白色裂纹完全不是一回事。这个顺序我在代码评审里见到好几个人劈叉过。如果图像存在光照不均比如扫描件中间亮、边缘暗Otsu 的全局阈值会失效。这时可以换成自适应阈值using var binary new Mat(); Cv2.AdaptiveThreshold(gray, binary, 255, AdaptiveThresholdTypes.GaussianC, ThresholdTypes.BinaryInv, blockSize: 51, C: 10);blockSize决定局部窗口大小一般取 41 到 61 之间取奇数。这块我放到后面参数怎么调的章节细说。3.2 用长条形核提取横线和竖线形态学提取线条的关键在于核的设计。要提取横向线条就构造一个很长但只有一行高的矩形核int lineLength Math.Max(gray.Cols, gray.Rows) / 15; using var horizontalKernel Cv2.GetStructuringElement( MorphShapes.Rect, new Size(lineLength, 1)); using var horizontalLines new Mat(); Cv2.MorphologyEx(binary, horizontalLines, MorphTypes.Open, horizontalKernel);Size(lineLength, 1)就是一个横着的长条。MorphTypes.Open是开运算即先腐蚀后膨胀。开运算的作用是把图像中无法完整容纳这个长条核的前景结构全部抹掉只留下和核的形状方向一致的长横条。文字里的横笔画虽然也是横向的但它们的长度远小于这个核长腐蚀阶段就会被抹掉所以剩下的基本就是贯穿全图的横线。垂直方向同理只把核旋转 90 度using var verticalKernel Cv2.GetStructuringElement( MorphShapes.Rect, new Size(1, lineLength)); using var verticalLines new Mat(); Cv2.MorphologyEx(binary, verticalLines, MorphTypes.Open, verticalKernel);得到横线和竖线两张掩膜图之后用按位或合成一张总线条掩膜using var lines new Mat(); Cv2.BitwiseOr(horizontalLines, verticalLines, lines);这里我用BitwiseOr而不是AddWeighted避免两幅图重叠区域出现像素值相加超过 255 的问题。合成后lines图中白色的地方就是识别出来的线条区域。3.3 掩膜后处理与 Inpaint 修复直接拿lines去做修复效果往往不够好。因为二值化边缘会有锯齿、线条和文字粘连处会留下小毛刺掩膜可能有少量空洞。先用一次膨胀把掩膜边缘扩大一点让修复区域覆盖更完整using var kernel3 Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.Dilate(lines, lines, kernel3, iterations: 1);iterations: 1是经验值膨胀太多会把文字笔画也吞进去。对大多数扫描件来说膨胀 1 次刚好能把线条边缘的过渡区包住又不会扩散到文字上。然后读取彩色原图执行修复using var color Cv2.ImRead(input.png, ImreadModes.Color); using var result new Mat(); Cv2.Inpaint(color, lines, result, inpaintRadius: 3, InpaintMethod.Telea);inpaintRadius是修复算法的邻域半径数值越大修复区域向外扩展得越远但图像越模糊。3 到 5 是比较稳妥的区间后面我会给出根据线条宽度确定的估算公式。整套代码串起来就是一个干净的静态方法public static Mat RemoveLines(string imagePath, double kernelLengthFactor 15.0) { using var gray Cv2.ImRead(imagePath, ImreadModes.Grayscale); using var binary new Mat(); Cv2.Threshold(gray, binary, 0, 255, ThresholdTypes.Otsu | ThresholdTypes.BinaryInv); int lineLength (int)Math.Max(gray.Cols, gray.Rows) / kernelLengthFactor; using var hKernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(lineLength, 1)); using var vKernel Cv2.GetStructuringElement(MorphShapes.Rect, new Size(1, lineLength)); using var hLines new Mat(); using var vLines new Mat(); Cv2.MorphologyEx(binary, hLines, MorphTypes.Open, hKernel); Cv2.MorphologyEx(binary, vLines, MorphTypes.Open, vKernel); using var lines new Mat(); Cv2.BitwiseOr(hLines, vLines, lines); using var kernel3 Cv2.GetStructuringElement(MorphShapes.Rect, new Size(3, 3)); Cv2.Dilate(lines, lines, kernel3); var color Cv2.ImRead(imagePath, ImreadModes.Color); var result new Mat(); Cv2.Inpaint(color, lines, result, 3, InpaintMethod.Telea); return result; }使用的时候using var cleaned RemoveLines(scan.png); Cv2.ImWrite(scan_clean.png, cleaned);跑通这个 Demo 大概只需要十分钟但到这一步只是能跑。真正让人头疼的是参数怎么调、各种奇怪图像怎么应对这些才是决定这个工具能不能真的上线的关键。4. 参数不是玄学从图像尺寸和线条宽度反推我见过不少人在形态学方案上栽跟头栽的原因几乎都集中在参数上。大部分博客给的是lineLength col / 30这种拍脑袋经验值。这套值在 demo 图上可能有效换一张图就完全失灵。原因是形态学核的长度直接决定了线条提取的灵敏度它应该由线条本身的特点决定而不是由图像尺寸的固定比例决定。这里分解成两个参数来看。4.1 核长度必须大于线段最大断裂间隙一个矩形核要能完整容纳一条线才能在线条被腐蚀掉之后通过膨胀恢复出来。也就是说核的长度必须大于线条上最宽的那个缺口。扫描图像里线条偶尔会有噪点、断点如果核长 30 像素而线条中间有一处 40 像素的缺损开运算就会把这根线从中间断成两截后续 Inpaint 就补不干净。更合理的策略是核长度 图像长边 / 12 到 / 18 之间。对一个 1200 x 800 的扫描件除以 15 大约是 80 像素。这个长度足以覆盖大部分 2~3 像素宽线条上的小断裂又不会长到把文字里的长横笔画误判成线条。具体可以在 12 到 20 之间二分搜索哪个值让 Inpaint 之后文字断笔最少就用哪个。4.2 核宽度决定是否误伤文字笔画Size(lineLength, 1)里的第二个参数1表示核只有一行高。这个值对线条提取影响极大。真实场景里线条宽度可能从 1 像素到 10 像素不等如果是细下划线宽 1~2 像素核宽 1 没问题如果是表格边框线打印出来可能有 3~5 像素核宽 1 会导致开运算后线条残缺如果核宽大于线条实际宽度就会把和线条重叠的文字笔画一起包进去产生挖掉一块肉的效果。所以处理前先统计线条的实际宽度方法很简单在二值图上遍历线条所在行的黑色像素连续段长度取众数。或者目测一下直接用Size(lineLength, 3)这种保守值。我自己的经验是先按宽度 1 跑一次看结果里线条是否断断了就把核宽加到 3 或 5直到横线整体连续同时文字没有被明显掏空。4.3 Inpaint 半径与膨胀次数inpaintRadius取多少和线条宽度强相关。如果线条宽 3 像素掩膜膨胀 1 次后修复区域向外扩了大概 1 像素总修复区域宽约 5 像素此时半径 3 足够。半径太大会让修复结果出现明显的模糊斑块太小则补不齐笔画。推荐经验公式inpaintRadius ≈ (lineWidth 2) / 2如果线条宽度为 3半径取 3宽度为 5半径取 4。InpaintMethod我默认用Telea它是基于快速行进法的对细线条修复速度快、边缘过渡自然。另一个选项NSNavier-Stokes对宽区域的修复结果更平滑但速度慢文字笔画交叉处容易出现糊成一片的情况。我的建议是细线条用 Telea宽线条或者大块污渍用 NS但大部分场景 Telea 就够了。4.4 一个自动估算参数的暴力搜索思路如果参数实在难调别死磕理论推导直接用脚本搜。你可以写一个循环让lineLength取 20、40、60、80、100kernelWidth取 1、3、5分别跑一遍结果图存成序列图人眼选效果最好的。或者更高级一点把结果图重新二值化之后统计黑像素的连通域数量——文字笔画断裂越多连通域数量越多选连通域数量最少的那组参数。这个思路虽然土但在做批量预处理时非常省力。5. 实战中的疑难杂症斜线、阴影、彩色线条、断笔到这一步标准横竖线条已经能处理得比较干净了。但真实项目里永远不按教科书出牌我挑了四个高频问题展开讲讲每个都是从实际项目里撞出来的。5.1 斜线怎么提取两组对角核开运算的核是矩形的只能沿横、竖两个方向检测。遇到 45 度角的删除线或者斜体文字上的划线横竖核基本无能为力。处理方式很直接加两组对角方向的长条形核。OpenCvSharp 里没有直接生成斜向结构元的 API但可以通过GetStructuringElement配合旋转来构造。或者更简单的方法先把图像旋转 45 度提取线条再旋转回来最后把掩膜对齐到原图。这个方法听起来笨但胜在稳定配合仿射变换的 API 实现起来也不复杂。要注意的是对角核的宽度和长度设置要更保守因为文字笔画中斜向成分比如撇捺很多核太短会把撇捺当成线条核太长则完全提取不到斜线。我一般取核长为图像短边的 1/8宽度还是 3并且会对提取到的掩膜做一次连通域面积过滤去掉面积过小的碎片。5.2 光照不均用自适应阈值救场有一次处理一批历史档案的扫描件纸张年代久远中间泛黄两侧偏暗。Otsu 阈值在这类图上表现非常差中间的文字被砍断两侧的背景没分干净形态学提取出来的线条到处都是断裂口。当时切到AdaptiveThreshold后问题立刻缓解。自适应阈值的关键参数是blockSize。这个窗口必须大于线条宽度的两倍同时小于文字笔画之间的典型间距。对于 300 DPI 的 A4 扫描件字体一般是 10~12 磅笔画宽度 2~3 像素blockSize取 51、C取 10 是比较合理的起点。C是自适应阈值时减去的常数越大越不容易把阴影误判为前景但太大又会把较淡的文字整个丢掉。5.3 彩色线条先做通道拆分如果线条是红色的而你直接转灰度再二值化红线和黑字在灰度图上可能亮度接近很不好分。这时应该先利用颜色信息。方法一在 RGB 三个通道上分别跑一遍提取流程哪个通道的线条掩膜最干净就选哪个。红色线条通常 B 通道压得很暗和黑字对比度较低反而容易提取。方法二转换到 HSV 颜色空间通过Cv2.InRange按H通道的颜色范围圈出红色区域生成掩膜。彩色文字识别场景下方法一更省事因为不需要预先知道线条颜色方法二适合线条颜色固定且明确的产品需求。5.4 文字与线条交叉处的断笔问题这是整个流程里最无解但也最能体现调优水平的地方。形态学提取线条时文字笔画和线条连成一片开运算后线条保留下来了但笔画在线条上的那一小段也被当成了线条的一部分。Inpaint 虽说可以重建但如果笔画被吃掉的长度太大周围的像素信息不足以推断出原来的笔画走向断笔就出现了。遇到这种情况我的操作顺序是这样的先不要急着上 Inpaint而是把掩膜lines在交叉点区域做一次局部腐蚀把线条掩膜在文字笔画附近收缩一点。可以用一个简单办法实现对lines做DistanceTransform小于 3 的区域保留大于 3 的区域收缩一圈。这样修复区域缩小文字笔画被误伤的几率就小了。也可以换一个思路先提取线条然后在原图上把线条区域涂成背景色再多迭代几次中值滤波填补空洞。这种方法处理交叉点断笔的效果不如 Inpaint 自然但胜在速度快适合对 OCR 结果要求不那么高的场景。6. 把这套逻辑接进真实 OCR 管线后的经验最后聊聊这个去线工具放到完整识别链路上的位置以及我在几个项目里收获的工程经验。6.1 放在预处理哪个环节通常 OCR 管线的顺序是图像读取 - 去噪 - 倾斜矫正 -去线- 二值化 - 版面分析 - 文字识别。去线要在倾斜矫正之后因为倾斜的表格线经过旋转后方向才规整形态学核才能对齐。如果先去了线再做倾斜矫正矫正过程中插值算法会把残存的线条边缘虚化导致二值化后出现一条模糊的影子反而影响识别。6.2 批量处理时的输出与监控批量处理几十万张票据的时候不要只输出一张结果图就完事。我在工程里会同时输出三份中间产物原图、线条掩膜、结果图。掩膜是用来排查问题的关键只要发现识别率异常先看掩膜——是线条没提干净还是文字笔画被误伤一目了然。这个习惯帮我省了大量调参时间。6.3 性能优化方向Inpaint算法本身不慢但在大图4000 x 3000上逐张处理还是挺吃 CPU 的。如果对速度敏感有两个优化方向。第一Inpaint 前把掩膜外的区域用ROI感兴趣区域裁出来只在含线条的小块上做修复性能能提升一个量级第二如果线条掩膜覆盖面积很小可以先用Cv2.Resize缩小图像做修复再放大回原尺寸视觉差异可以忽略。还有一点要提醒OpenCvSharp 里的Mat对象要记得及时Dispose。整个去线流程会产生二值图、横线图、竖线图、掩膜图、结果图至少五六个Mat长循环里不释放内存跑几百张图就会出现OutOfMemory。用using或者using var是最省心的做法。我最早接触这个需求时也想过直接上深度学习后来发现一套形态学 Inpaint 的组合处理印刷体文档能达到 95% 以上的效果代码不到一百行部署没有任何额外依赖。对大部分业务系统来说这就是性价比最高的解。你如果手头正好有类似的去线需求可以先把我上面这段代码跑通再根据自己图像的特点调核长度和膨胀次数遇到斜线就加对角核遇到光照不均就切自适应阈值。动手试两张图你会比看十篇理论文章收获更多。本文还有配套的精品资源点击获取