Halcon低对比度图像增强：算子选型、参数计算与产线落地

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 全局拉伸、直方图均衡、局部锐化各自的职责边界

我把常见做法归成三类，它们的物理意义完全不同，用错了不但没效果，还会引入新问题。

举个生活化的类比：全局拉伸像是把一张曝光不足的照片整体提亮，你能看清更多东西，但画面里的噪点也跟着亮了；直方图均衡像是把照片里所有亮度重新“摊平”，暗部细节会蹦出来，但大面积纯色区域会被强行拉出噪点；局部锐化则像是给照片加了锐化滤镜，边缘变清楚，但同时会出现白边和噪点颗粒。三者解决的是不同层面的问题，不能互相替代。

我个人的经验是：能靠打光解决的就别靠算法。如果光源角度、偏振、背光方案还能调，先把光调好，图像本身对比度上来了，后面的算子参数宽容度会大得多。算法增强是补救手段，不是首选手段。

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 = 40，GMax = 180，跨度 140，那么Mult = 255/140 ≈ 1.8214，Add = -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) endif

min_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([(Row+1)*TileH-1, Height-1]), \ min([(Col+1)*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 里做光照不均修正最直接的是illuminate：

illuminate (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”这种问题，有记录就能直接翻出来，没记录就只能重新试一遍。这个习惯看着笨，但是真省事。