Halcon 里跟图像对比度相关的算子就那么几个但真正在产线上把图像调得既能稳定分割、又能长期跑住的人并不多。我见过太多项目调试阶段把图像拉得漂漂亮亮验收时换一批料、换一盏灯阈值就全线崩溃。问题往往不在算子用得对不对而在于动手之前没想清楚这一次我要增强的到底是全局灰度跨度、局部纹理起伏还是边缘锐度。这三件事在 Halcon 里对应完全不同的算子组合参数逻辑也完全不一样混着用就必然出问题。下面我按自己这些年做低对比度检测的实战顺序把这件事从头捋一遍从灰度分布的数学含义讲到算子选型、参数计算、效果验证和落地踩坑尽量把每一步“为什么这么干”都说透。1. 先分清三种“对比度”否则算子一定会用错1.1 一次低对比度字符检测引出的基本问题前几年接过一个字符识别的活儿材质是深色哑光表面打浅色喷码肉眼看着还行但采出来的图里字符笔画和背景的灰度均值只差 8 个灰阶左右背景均值 88笔画均值 96。当时第一版直接上threshold阈值卡在 92结果字符断成一截一截笔画边缘全是毛刺。检查之后发现噪声标准差大概 2.5 个灰阶也就是说信号差 8、噪声 2.5信噪比只有 3 倍出头任何阈值都会有一大批像素落在模糊地带。这里有个经常被忽略的量化概念8 bit 图像一共只有 256 个灰阶如果你的目标和背景只占其中 8 级那留给后续所有处理阈值、形态学、亚像素边缘的“数值空间”就被压得极扁。线性拉伸把 8 级拉到 60 级不会让噪声消失但会让后续算子在数值上有腾挪余地边缘提取的亚像素拟合也更稳。反过来说如果你的原始图像目标和背景本来就差 80 级再去做拉伸纯属浪费时间甚至会把高光拉爆。所以判断“要不要增强”的第一步永远是先量一遍数据而不是先调算子。用min_max_gray配合 ROI 把目标和背景的实际灰度范围、均值、标准差都打出来心里有数再动手。* 分别取目标和背景的小块 ROI量化现状 reduce_domain (Image, RegionFg, ImageFg) reduce_domain (Image, RegionBg, ImageBg) min_max_gray (RegionFg, Image, 0.5, MinFg, MaxFg, RangeFg) min_max_gray (RegionBg, Image, 0.5, MinBg, MaxBg, RangeBg) intensity (RegionFg, Image, MeanFg, DevFg) intensity (RegionBg, Image, MeanBg, DevBg)1.2 全局拉伸、直方图均衡、局部锐化各自的职责边界我把常见做法归成三类它们的物理意义完全不同用错了不但没效果还会引入新问题。类型代表算子改变了什么典型适用场景典型误用全局线性拉伸scale_image、scale_image_max只改变灰度的映射区间不改变信噪比图像整体偏暗/偏灰灰度集中在一小段背景有大面积饱和或死黑时无脑用直方图均衡equ_histo_image、equ_histo_image_rect按累积分布重排灰度局部斜率被放大背景与目标灰度分布严重重叠、层次压扁背景占比 90% 以上的工业图局部高频增强emphasize、手工 unsharp mask提升局部梯度强化纹理与边缘表面划痕、织纹、低对比度纹理高噪声图像直接上大增益举个生活化的类比全局拉伸像是把一张曝光不足的照片整体提亮你能看清更多东西但画面里的噪点也跟着亮了直方图均衡像是把照片里所有亮度重新“摊平”暗部细节会蹦出来但大面积纯色区域会被强行拉出噪点局部锐化则像是给照片加了锐化滤镜边缘变清楚但同时会出现白边和噪点颗粒。三者解决的是不同层面的问题不能互相替代。我个人的经验是能靠打光解决的就别靠算法。如果光源角度、偏振、背光方案还能调先把光调好图像本身对比度上来了后面的算子参数宽容度会大得多。算法增强是补救手段不是首选手段。2. 线性拉伸scale_image的 Mult 和 Add 到底怎么算2.1 从公式反推参数别靠试scale_image干的事情非常朴素对每个像素做g g * Mult Add。很多人是随便填个 1.5、2.0 试出来的其实完全可以直接算。假设你希望把原始区间[GMin, GMax]映射到[0, 255]那么Mult 255 / (GMax - GMin) Add -Mult * GMin拿前面那组数据举例GMin 40GMax 180跨度 140那么Mult 255/140 ≈ 1.8214Add -1.8214 × 40 ≈ -72.857。写进代码就是min_max_gray (Image, Image, 0.5, GMin, GMax, GRange) if (GRange 0) Mult : 255.0 / GRange Add : -Mult * GMin scale_image (Image, ImageScaled, Mult, Add) endifmin_max_gray的第三个参数Percent是分位数裁剪这一点极其关键。填 0 表示取真实极值只要图里有一个热噪点或者一粒反光粉尘是 255整个跨度就被撑满拉伸等于没做。填 0.5 表示忽略 0.5% 的最亮和最暗像素抗离群点的能力强很多。我一般会根据图像干净程度在 0.2 到 2 之间调噪声大的图可以放到 1 甚至 2。另外要注意scale_image对 byte 图像做运算时结果超出 0-255 的部分会被直接截断不会报错。所以Add为负数时原本低于GMin的像素会被压到 0 变成死黑。如果你的图里存在大面积暗区这些区域的细节就彻底丢了。稳妥的做法是在拉伸前先把图像转成real或int2类型convert_image_type (Image, ImageReal, real) scale_image (ImageReal, ImageScaledReal, Mult, Add) convert_image_type (ImageScaledReal, ImageOut, byte)代价是耗时上升real类型的运算量比 byte 大不少。产线上如果 ROI 不大、帧率不紧张这个开销可以接受如果是高速线扫还是老老实实用 byte 加裁剪逻辑前提是你确认过没有大面积溢出。2.2scale_image_max的失效场景一粒反光点毁掉整张图scale_image_max用起来最省事一行代码自动按极值拉伸很多教程都推荐它。但我在实际项目里对它有很强的戒心原因就是上面说的离群点问题。设想一张检测金属表面划痕的图背景灰度在 90 到 110 之间波动划痕大概 130剩下 99% 的像素都在这个窄带里。但画面角落有一处镜面反射灰度直接到 250还有一个轻微漏光的暗角是 5。scale_image_max会按 [5, 250] 做全范围映射Mult ≈ 1.02几乎等于没拉伸。你看着屏幕觉得“好像亮了一点”其实信号完全没被放大。判断方法很简单跑一遍拉伸后重新min_max_gray如果GRange明显小于 255就说明映射没打满中间必然有离群点吃掉了动态范围。这时候有两个选择一是改用min_max_gray带分位数手工算参数二是先用median_image或者小核mean_image把孤立噪点抹掉再拉伸。* 方案一先去孤立噪点再自动拉伸 median_image (Image, ImageMed, circle, 2, mirrored) scale_image_max (ImageMed, ImageOut) * 方案二分位数裁剪后手工映射 min_max_gray (Image, Image, 1.0, GMin, GMax, GRange)我通常更倾向方案二因为中值滤波在抹掉噪点的同时也会吃掉细小的真实缺陷尤其是宽度只有一两个像素的划痕。用分位数裁剪是“忽略极端值”对主体信号的破坏小得多。注意scale_image_max在不同版本里对彩色图像的处理是分通道还是按整体行为不完全一致涉及彩色图时务必先用一张已知图验证输出别想当然。2.3 ROI 内拉伸与三通道比例一致工业图有个特点真正需要检测的区域往往只占画面的一小块。全图拉伸等于让无关区域参与统计白白拉低了质量。正确的做法是reduce_domain之后只对 ROI 求极值再把这个Mult/Add应用到整图或者干脆只处理 ROI。reduce_domain (Image, RegionROI, ImageROI) min_max_gray (ImageROI, ImageROI, 0.5, GMin, GMax, GRange) Mult : 255.0 / GRange Add : -Mult * GMin scale_image (Image, ImageScaled, Mult, Add)彩色图还要多一层考虑。如果对 R、G、B 三个通道各自独立拉伸三个通道的Mult不一样色彩比例就被破坏了原本灰色的背景会偏色。稳妥做法是算一个统一的Mult/Add三通道共用decompose3 (Image, ImageR, ImageG, ImageB) min_max_gray (RegionROI, ImageG, 0.5, GMin, GMax, GRange) * 以绿通道为基准 Mult : 255.0 / GRange Add : -Mult * GMin scale_image (ImageR, R2, Mult, Add) scale_image (ImageG, G2, Mult, Add) scale_image (ImageB, B2, Mult, Add) compose3 (R2, G2, B2, ImageOut)如果确实需要独立拉伸各通道那基本都是为了做颜色分离比如区分两种色差很小的油墨这时候目标已经不是“看得清楚”而是“拉开色差”属于另一类需求了。千万不要对着彩色图直接跑equ_histo_image三个通道独立均衡之后出来的颜色会变得非常诡异后面的颜色特征全部作废。3. 直方图均衡equ_histo_image什么时候真能帮上忙3.1 均衡的本质是把累积分布拉直equ_histo_image的逻辑是统计整幅图的灰度直方图算出累积分布函数然后按累积分布重新映射灰度让输出图的直方图尽量接近均匀分布。数学上看它做的是一次单调非线性映射映射曲线的斜率在“像素密集的灰度段”被压小在“像素稀疏的灰度段”被放大。这意味着什么如果你的目标像素只占全图的 5%它们所在的灰度段在累积分布里斜率很大均衡之后这一段会被强行拉开目标和背景的区分度确实上去了。但反过来如果你做的是表面缺陷检测背景占 90% 以上那均衡会把背景那段密集灰度压缩得几乎没有层次然后靠放大那点残余波动来“制造”对比度——结果就是背景变得像电视雪花一样全是噪声颗粒。我用一个很粗暴的经验值来判断目标像素占比低于 10% 且背景相对均匀时慎用全局均衡目标与背景灰度分布重叠严重、且背景本身有丰富纹理时可以试试。前者典型的例子是字符、丝印、点胶后者典型的例子是织物、木纹、纸张。试过几次之后我发现工业场景里equ_histo_image真正发挥作用的地方其实很窄更多时候它是作为“看看图像里还有没有信息”的探索手段而不是最终方案。你在调试阶段用它看一眼发现“哦原来背景里还有这么多层次”然后再回头去想怎么用线性方法把那部分层次单独拎出来这样更靠谱。3.2 分块均衡与查表法把控制权拿回来全局均衡最大的问题是“一锅端”。如果画面里同时存在亮区和暗区全局统计会被亮区主导暗区的细节依旧出不来。这时候可以考虑分块处理。思路很直接把图切成若干矩形块每块独立算映射再拼回去。Halcon 里有现成的分块均衡算子部分版本中提供equ_histo_image_rect参数是块宽和块高。如果你的版本里没有手工实现也不难* 手工分块均衡示意4x4 块 get_image_size (Image, Width, Height) TileW : Width / 4 TileH : Height / 4 gen_empty_obj (Tiles) for Row : 0 to 3 by 1 for Col : 0 to 3 by 1 gen_rectangle1 (Rect, Row*TileH, Col*TileW, \ min([(Row1)*TileH-1, Height-1]), \ min([(Col1)*TileW-1, Width-1])) reduce_domain (Image, Rect, ImageTile) equ_histo_image (ImageTile, ImageTileEq) concat_obj (Tiles, ImageTileEq, Tiles) endfor endfor分块均衡的副作用是块与块之间会出现明显的亮度跳变像马赛克一样。所以拼接之后一定要做一次平滑过渡或者用重叠块加权融合。这块开销不小我在实际项目里用得很少除非是大幅面、光照严重不均的场合。另一条更可控的路子是手工构造查找表。既然均衡的本质是一个 256 项的映射表那完全可以自己按需求设计这个表再用lut_trans应用* 构造一条自定义 S 形映射曲线重点拉开中间灰度段 tuple_gen_sequence (0, 255, 1, GraySeq) * 这里用一个简单的分段线性示例 GrayOut : [] for i : 0 to 255 by 1 G : GraySeq[i] if (G 60) GrayOut : [GrayOut, G * 0.5] elseif (G 160) GrayOut : [GrayOut, 30 (G - 60) * 2.0] else GrayOut : [GrayOut, 230 (G - 160) * 0.26] endif endfor tuple_min (GrayOut, 0, GrayOutClipped) * 转成 lut 需要的 tuple 后交给 lut_trans自定义 LUT 的好处是你能明确知道“我要拉开哪一段”并且可以保证映射是单调的、不会出现均衡那种阶梯状的跳变。代价是需要先看直方图确定分段点多花点调试时间。但对于一个要上产线的方案这点时间花得值。4. 局部对比度真正提升细节的那一类操作4.1emphasize的参数在做什么emphasize是 Halcon 里做局部对比度增强最顺手的算子签名为emphasize(Image, ImageEmphasize, MaskWidth, MaskHeight, Factor)。它内部的逻辑是先用一个宽为MaskWidth、高为MaskHeight的均值滤波估计出局部背景然后用原图减去背景得到高频分量最后按Factor把高频分量加回原图。于是参数的意义就很清楚了。MaskWidth/MaskHeight决定了“什么尺度算背景”核越大被当作背景的低频成分越多留下的高频细节尺度也越大核越小只有很细的纹理被视为高频。Factor就是高频分量的放大倍数越大越锐利同时噪声也放大得越厉害。我一般在检测划痕、凹坑、织纹这类缺陷时核尺寸按“缺陷宽度的 3 到 5 倍”来取。比如划痕宽度大概 5 个像素核就取 21 到 25 左右。Factor从 1.0 开始每次加 0.5 试一直到背景开始起颗粒为止。经验上 1.5 到 3.0 是可用区间超过 4 基本就不能看了。emphasize (Image, ImageEmph, 21, 21, 2.0)有一点必须提醒emphasize对 byte 图像同样存在截断问题增强后原本就接近 255 的高光区域容易直接爆成一片白原本接近 0 的暗部会变成一片黑。所以用之前先看一眼min_max_gray的结果如果极值已经很接近边界先缩小动态范围压一下再增强。4.2 先用real类型手搓 unsharp mask绕开 byte 截断emphasize够用但不够透明。真正的项目里我更愿意自己写一遍 unsharp mask因为每一步都能控。这里最关键的一个技巧是先把图转成real这样中间结果不会因为超出 0-255 被截断最后再转回 byte。convert_image_type (Image, ImageReal, real) * 1. 估计局部背景大核均值或用 gauss_filter mean_image (ImageReal, ImageMean, 15, 15) * 2. 原图减背景得到高频分量real 类型可以直接出负值 sub_image (ImageReal, ImageMean, ImageDiff, 1.0, 0) * 3. 高频分量乘以增益 mult_image (ImageDiff, ImageDiff, ImageAmp, 2.0, 0) * 4. 叠加回原图 add_image (ImageReal, ImageAmp, ImageSharp, 1.0, 0) * 5. 转回 byte超范围自动裁剪 convert_image_type (ImageSharp, ImageOut, byte)这段代码比emphasize长但它带来的好处是如果你只想增强中频、不想放大高频噪声可以先把高频分量做一次轻微平滑再叠加如果只想增强正对比度亮的更亮而不想增强负对比度可以在ImageDiff上加一个判断。这些都是emphasize做不到的。另一种常见变体是“只增强暗缺陷”或者“只增强亮缺陷”做法是对ImageDiff做一次阈值截断把不需要的极性置零。这个技巧在检测单极性缺陷比如只有凹坑没有凸起时能明显降低误报。用gauss_filter替代mean_image也是常见选择高斯核的频域特性更平滑不会出现均值核那种方块状的振铃。代价是同样核尺寸下耗时略高一点。gauss_filter (ImageReal, ImageGauss, 15) sub_image (ImageReal, ImageGauss, ImageDiff, 1.0, 0)提示转real之后整条链路的内存和耗时都会涨一张 500 万像素的图real类型单个图像对象就是 20MB 起步。工控机上跑的时候要留意内存占用尤其是多线程并发处理时。4.3 光照不均先处理否则增强只会放大不均这是我最想强调的一条经验。很多“对比度不够”的表象根子其实是光照不均。图的一边亮一边暗全局拉伸会把亮的一边拉爆暗的一边还是看不清局部增强会把明暗过渡带强化成一片假边缘。正确的顺序是先做光照校正再做对比度增强。Halcon 里做光照不均修正最直接的是illuminateilluminate (Image, ImageIllum, 51, 1.0)它的逻辑是用大核中值或均值估计出背景然后把背景“拉平”。MaskSize要明显大于你想要保留的缺陷尺度否则缺陷本身会被当成背景抹掉。Factor控制校正强度1.0 是完全拉平小于 1 保留一部分原始明暗。更可控的做法是手工做“背景除法”convert_image_type (Image, ImageReal, real) * 用一个非常大的核估计背景 mean_image (ImageReal, ImageBg, 101, 101) * 原图除以背景得到相对亮度 div_image (ImageReal, ImageBg, ImageDiv, 128, 0) convert_image_type (ImageDiv, ImageOut, byte)除法比减法更能适应不同亮度区间的对比度差异它把“绝对灰度差”换成了“相对比例”。如果缺陷表现为“比局部背景暗 10%”那除法之后不管在亮区还是暗区这个 10% 都会变成相同的灰度差后面的阈值就能用同一个值覆盖全图。这个思路在金属、玻璃、纸张这类大面均匀材质上特别管用我基本把它当成预处理的标准动作。5. 效果好不好别只靠眼睛判断5.1 用 CNR 给增强效果打个分调参调到后面人眼会疲劳尤其是连续看几十张图之后“好像清楚了一点”这种判断极不可靠。我习惯用一个客观指标对比噪声比CNR。CNR |μ目标 - μ背景| / sqrt(σ目标² σ背景²)在增强前后各算一次如果 CNR 提升了说明增强是有效的如果基本没变说明你只是把噪声和信号一起放大了白忙一场。用intensity就能直接算出来intensity (RegionFg, ImageOut, MeanFg, DevFg) intensity (RegionBg, ImageOut, MeanBg, DevBg) Diff : abs(MeanFg - MeanBg) Noise : sqrt(DevFg*DevFg DevBg*DevBg) if (Noise 0) CNR : Diff / Noise endif这个指标还能帮你比较不同方案。比如 A 方案是scale_image拉伸B 方案是emphasize两张输出图都算一遍 CNR谁的数高用谁。前提是目标/背景 ROI 要选得一致别一次选得松一次选得紧那比较就没意义了。需要注意的是CNR 只能反映“分离度”不能反映“边缘质量”。如果后续要做亚像素测量还需要额外看边缘的梯度峰值和宽度这时候可以沿垂直于边缘的方向取一条灰度剖面看看过渡带是变窄了还是变宽了。极端锐化会让过渡带变窄看起来锐利但同时也引入了过冲白边亚像素拟合反而会偏。5.2 噪声估计给锐化增益找一个上限estimate_noise能直接从图像估计噪声标准差这个值是我调Factor时的重要参考estimate_noise (Image, gauss, Sigma)我的一般原则是锐化后的噪声标准差不要超过原始噪声的 3 倍。假设原始Sigma 2.0那锐化后控制在 6.0 以内比较安全。超过这个量级后续的形态学操作、区域合并都会被噪声主导你会开始用一堆开闭运算去修修到最后结构全变了。如果原始噪声本身就偏高比如Sigma 5那我的建议是先降噪再增强顺序不能反。先增强再降噪噪声已经被放大并混进信号里滤不干净先降噪再增强丢掉的只是高频细节而这部分细节本来也被噪声淹没了。降噪算子的选择上median_image保边效果好但会削弱细节适合椒盐类噪声gauss_filter平滑自然但会糊边适合高斯噪声binomial_filter速度快、可分离适合实时场景。如果对边缘保持要求高可以考虑先转real做一次非局部均值思路的自定义滤波但那个复杂度就上去了一般项目用不上。多帧平均是个更彻底的方案同一位置连采 N 张累加后除以 N噪声理论上降到原来的 1/√N。采 4 张噪声减半采 16 张降到 1/4。如果产线允许停机或者工位有冗余时间这个方法比任何算法都干净。* 假设 Image1..ImageN 已在循环中采集 add_image (Accum, ImageN, AccumSum, 1.0, 0) * 最后统一除以 N mult_image (AccumSum, AccumSum, ImageAvg, 1.0/N, 0)5.3 增强之后阈值参数必须重标这一条踩过坑的人应该都有共鸣。改了增强参数图像灰度分布整个变了但代码里threshold的上下限还是原来那对数字跑出来当然是错的。更麻烦的是有些阈值是“看着图调出来的”根本没有文档记录换个人接手就完全不知道从哪改起。我的做法是把增强环节和分割环节的参数显式解耦增强输出后重新用gray_histo看一眼直方图的谷底位置再定阈值。如果图像质量稳定可以用binary_threshold自动求阈值参数填max_separability让算法自己去直方图里找最优分割点这样即使光照有小幅漂移也能自适应。gray_histo (RegionROI, ImageOut, AbsoluteHisto, RelativeHisto) binary_threshold (ImageOut, RegionDark, max_separability, dark, UsedThreshold)binary_threshold返回的UsedThreshold很有价值把它打到日志里产线上跑一段时间看看这个值的波动范围。如果波动超过 ±10说明前端的光照或者增强参数不够稳需要回头查光源老化、镜头污染或者参数漂移。这个日志比任何事后排查都管用。另外提醒一句如果增强链路里用了real类型最后一定要convert_image_type转回 byte 再去做分割。虽然 Halcon 大部分算子对real也支持但阈值类算子在real上的行为跟 byte 不完全一样容易出一些莫名其妙的边界问题。6. 上产线之后才会遇到的几个现实问题6.1 耗时ROI 和算子选择比参数优化更重要调试阶段大家都不太在意耗时因为单张跑起来都很快。但节拍一旦压到 30ms 一张问题就来了。我做过一次统计一张 500 万像素的图scale_image大概在几毫秒量级equ_histo_image因为要统计直方图会明显慢一些emphasize内部带一次均值滤波核越大越慢转real之后整体耗时大概翻一倍。优化的第一优先级永远是缩 ROI。检测区域如果只占画面 10%那所有增强运算只跑这 10%耗时直接降一个数量级。用reduce_domain而不是crop_domain前者只改域不改图像矩阵内存不增加。第二优先级是算子替换。同样是拉伸scale_image比自定义 LUT 快同样是局部增强emphasize通常比手工mean_image sub_image mult_image add_image那条链路快因为内部做了优化。只有在需要特殊控制比如单极性增强时才值得手工写。第三才是参数优化。核尺寸从 21 降到 15耗时能降一点但效果也会变这个取舍要在效果达标的前提下做。不要为了省 2ms 把核改小结果误检率上去了那就本末倒置了。6.2 彩色图与多光源别在错误的色彩空间里做增强彩色图的对比度增强最容易犯的错是直接在 RGB 三通道上分别处理结果要么偏色要么某个通道饱和。我的建议是先把图转到 HSV 或者 Lab 空间只在亮度通道上做增强再转回去decompose3 (Image, ImageR, ImageG, ImageB) trans_from_rgb (ImageR, ImageG, ImageB, ImageH, ImageS, ImageV, hsv) * 只对 V 通道做拉伸 / 增强 min_max_gray (ImageV, ImageV, 0.5, VMin, VMax, VRange) scale_image (ImageV, ImageVNew, 255.0/VRange, -255.0/VRange*VMin) trans_to_rgb (ImageH, ImageS, ImageVNew, R2, G2, B2, hsv) compose3 (R2, G2, B2, ImageOut)这样色相和饱和度完全不动只改明度颜色关系保持原样后续如果还要用颜色做分类特征不会失真。如果检测对象是有色差的比如两种相近颜色的标签那就不能用亮度增强了得走颜色空间分离的路子用decompose3之后看哪个通道的差值最大或者干脆做一个颜色查找表。这跟“增强对比度”已经是两个不同的问题别混为一谈。多光源的情况更复杂一点。有些工位会用多个不同角度的光源分时点亮各拍一张然后合成。这时候合成的逻辑通常是取最大值突出高光缺陷或者取最小值突出暗缺陷而不是简单平均。Halcon 里没有现成的多图合成算子需要用max_image/min_image逐像素操作或者用tuple_max在数组层面处理。合成之后的图往往动态范围很大正好接scale_image做一次线性压缩。6.3 参数固化与版本管理别让调好的参数消失我见过最惨的一次事故是一个项目的增强参数调了两周才稳定结果代码合并的时候被人覆盖成了默认值产线跑了三天才发现误检率飙升。后来我们的做法是把所有增强相关的参数Mult、Add、核尺寸、Factor、ROI 坐标全部抽到一个配置文件里代码里只读不写配置文件进版本库。更进一步我建议在代码里加一段“参数合理性自检”启动时用一张标准样本图跑一遍增强算一下输出的min_max_gray和 CNR如果落在预期区间之外就报警。这相当于给参数加了一个看门狗一旦有人误改或者相机老化第一时间就能发现而不是等到批量误检才追查。* 启动自检示例 scale_image (ImageRef, ImageRefScaled, Mult, Add) min_max_gray (ImageRefScaled, ImageRefScaled, 0.5, RMin, RMax, RRange) if (RRange 200) * 拉伸不足说明参数或来图有问题 dev_display (ImageRefScaled) endif还有个细节不同批次的相机、不同批次的光源出来的图基线会漂。如果你把Mult/Add写死了换批次就得重新调。更稳的做法是每次开机用一张标准板做一次自动标定动态算出Mult/Add然后再进入正常检测流程。这个标定过程只要几秒钟但能省掉大量后期维护。最后说个我自己的习惯每调完一组参数我会把增强前后的图、直方图、CNR 数值、UsedThreshold一起存成一个对照记录按日期归档。项目做到后期往往需要回答“为什么这个参数是 1.8 不是 2.2”这种问题有记录就能直接翻出来没记录就只能重新试一遍。这个习惯看着笨但是真省事。
