FPGA图像电子透雾算法详解：从暗通道先验到ISP流水线落地

这年头搞视频图像处理的，只要不是纯做算法仿真，基本都绕不开一个词：电子透雾。安防监控、车载摄像、无人机航拍，一到雾天、霾天、回南天，画面灰白一片，细节全丢，后端算法再强也白搭。物理透雾加滤光片确实有效果，但成本高、安装受限、还怕脏污，维护起来一堆麻烦。所以现在主流方案都是在ISP管线里做Dehaze，也就是图像电子透雾。我这两年用FPGA做了几个相关的项目，从最初的算法验证到最终的硬件落地，踩了不少坑，也积累了一些实打实的经验。这篇就把整个设计思路和实现细节拆开讲讲。

这篇文章适合正在做FPGA图像处理、ISP相关开发，或者想在Zynq、Artix-7这类平台上落地透雾算法的朋友。我会从算法原理讲起，再深入到FPGA流水线架构、模块划分、资源优化、时序收敛，最后附上调试经验和问题排查手册。就算你是FPGA新手，刚接触ISP pipeline这个概念，这篇文章也能给你一条非常具体的入门路径。

1. 方案选型：为什么电子透雾必须上FPGA

1.1 从物理透雾到电子透雾

先说透雾的原理。雾气对成像的影响本质上是光在传播过程中被悬浮颗粒散射，导致到达传感器的光中包含大量非成像方向的杂散光。物理透雾的思路很直接，在镜头前加装偏振片或特定波段的滤光片，把散射光滤掉一部分，入射光干净了，画面自然通透。但物理透雾的缺点是致命的：一片好的偏振滤光片成本不低，而且只对特定角度的散射光有效，雾不浓时效果还行，浓雾基本无解。更要命的是，这种方式没法自适应场景变化，太阳角度一变、雾浓度一波动，效果就大打折扣。

电子透雾则完全靠算法。它直接对传感器采集到的原始图像做处理，通过估计场景深度、大气光、透射率等参数，把雾造成的对比度损失和颜色偏移补偿回来。整个过程不需要额外硬件，一颗SoC或者FPGA就能搞定。对于嵌入式平台来说，这是目前性价比最高、部署最灵活的透雾方案。

1.2 为什么用FPGA而不是DSP或CPU

先算一笔账。以1080p@30fps为例，每秒要处理的像素数是1920108030，约6200万像素。如果每个像素要做几十次乘加运算和多次非线性变换，需要几百GOPS的算力。对于纯软件方案，即便是高端ARM Cortex-A72跑NEON优化过的算法，也很难在功耗可控的情况下做到实时。DSP的优势是乘加密集任务，但Dehaze算法里面有大量的分支判断、取最大值最小值、数据搬移，这些恰恰是DSP的弱项。

FPGA方案的逻辑则完全不同。它是空间并行架构，可以把整条ISP pipeline分成多级流水线，每一级只处理自己那一段逻辑，数据像流水一样前进。720p的一个图像行，在DSP上可能需要循环几千次，在FPGA上只需要一个时钟周期就能全部并行处理完。实测下来，在Xilinx Artix-7 200T上，1080p@30fps的完整Dehaze流水线，LUT占用率控制在60%以内，功耗不到5W，延迟只有几毫秒。这个指标，DSP或者CPU方案很难做到。

还有一个关键优势是可定制性。FPGA的开发本质上是设计硬件，你可以把算法中的某一个算子直接映射成硬件逻辑。比如暗通道先验里的最小值滤波，在CPU上是用循环遍历窗口，在FPGA上就是一个滑动窗口的移位寄存器组加比较器树，性能完全不在一个量级。

2. 算法原理与硬件映射：从暗通道先验到流水线算子

2.1 暗通道先验算法的核心公式

目前工业界用得最多的电子透雾算法依然是何恺明提出的暗通道先验（Dark Channel Prior, DCP）。这个算法的核心观察是：在绝大多数无雾图像的局部区域里，至少有一个颜色通道的亮度值非常低，趋近于零。而雾的干扰会让这个暗通道值升高，雾越浓，暗通道值越接近大气光。基于这个先验，可以反推出透射率和大气光，从而恢复出无雾图像。

算法流程可以拆成四个关键步骤：

第一步：求暗通道图。对RGB三通道逐像素取最小值，得到单通道图J_dark_initial；再对该图做局部窗口最小值滤波。窗口大小通常取15x15，但FPGA上做这么大的窗口太吃资源，后面我会讲工程上的近似处理。

第二步：估计全局大气光A。取暗通道图中亮度最高的前0.1%像素，将这些像素对应到原图中的最大亮度值作为A。

第三步：估计透射率t。按公式 t = 1 - ω * min_c(I_c / A_c) 计算，其中ω是保留少量雾感的调节因子，一般取0.85到0.95。

第四步：恢复无雾图像。J = (I - A) / max(t, t0) + A，其中t0是透射率下限，防止除零和噪声放大，一般取0.1。

2.2 算法到硬件的逐级映射

上面这四个步骤看着不复杂，但要落到FPGA上，每一步都得重新思考数据流。

暗通道的最小值操作比较好办。RGB三通道逐像素取最小值，这个在FPGA上就是一个多路比较器，一拍就能完成。最麻烦的是窗口最小值滤波。15x15的窗口意味着需要15行行缓存（Line Buffer），同时每个输出像素要比较225个输入值。对于720p分辨率，一行是1280个像素，15行就是19200个像素的存储，全用BRAM大概要几十KB，资源压力不小。工程上常见的做法是把窗口缩小到5x5或者7x7，然后级联多级同样的滤波器来近似大窗口效果。比如做两次5x5的串行最小值滤波，等效于一个较大的窗口，资源消耗却能降低一半。实际测试下来，这种方法对暗通道估计的精度影响很小，特别是后续还有透射率细化步骤，可以补偿这部分的误差。

大气光估计在FPGA上通常用“局部最大值统计+时间滤波”实现。全局统计需要两遍扫描：第一遍找暗通道最大值，第二遍在原图对应位置找亮度最大值。实时视频流里没法做两遍扫描，所以硬件实现时都改成逐帧统计，用帧同步信号做复位和锁存。具体做法是：暗通道和原图数据流入统计模块时，不断更新最大值，等到一帧结束，锁存这一帧的A值，再用一个小的平滑系数对多帧的A值做IIR滤波，避免A值跳变引起画面闪烁。

透射率估计的除法在FPGA上比较麻烦。A_c是常数，I_c是变量，t = 1 - ω * I_c / A_c。除法器的实现可以调用Xilinx的Divider Generator IP核，但延迟较大且资源消耗高。工程上更常用的方法是把除法转换成乘法和移位。因为A_c是全局估计出来的常量，可以预先计算1/A_c，然后转换成定点乘法。如果A_c的值需要动态更新，就用查找表实现除法近似的倒数查找，把除法变成一次查表加一次乘法，精度完全够用。

最后的图像恢复，J = (I - A) / max(t, t0) + A，同样面临除法问题。但注意，这里的t是逐像素变化的，不能预计算倒数。实操中我一般把1/t近似成t的反函数查找表，输入t的高8位作为查找表地址，输出对应的1/t定点值。t的精度损失一段（从8位到8位）对最终图像的观感影响微乎其微，硬件实现却简单得多。

2.3 透射率细化：引导滤波的替代方案

直接用上述流程得到的透射率图，会有比较明显的块效应，画面看起来一块一块的，很不自然。原始DCP论文里用的是软抠图（Soft Matting），效果很好但计算量极大，在FPGA上基本行不通。后来何恺明又提出了引导滤波（Guided Filter），效果接近软抠图且效率高很多。但引导滤波涉及均值滤波、方差计算、线性回归，在FPGA上实现依然不轻。

我实测比较过几种方案，最终推荐用“快速双边滤波”或者干脆用“多级均值滤波近似”。具体做法是：

1. 对透射率图做3x3的均值滤波；
2. 对结果再做5x5的均值滤波；
3. 然后做一个边缘保护处理，用原图亮度作为引导图，对透射率图做一次联合双边滤波。

联合双边滤波的权重计算需要访问原图对应位置的像素，这个在FPGA上需要同时缓存原图和透射率图的行数据，BRAM占用会比单纯透射率滤波多一倍。但效果提升很明显，边缘区域的细节被保留，平滑区域又很自然，不会出现光晕伪影。如果你的BRAM资源实在紧张，至少要把前两级均值滤波做了，效果能改善不少。

3. FPGA系统架构设计与核心模块实现

3.1 整体系统框图

一套完整的基于FPGA的ISP Dehaze系统，核心架构包含几个大模块：视频输入接口（MIPI RX或者并行RGB输入）、Dehaze算法流水线、后端ISP模块（Gamma校正、色彩空间转换、自动曝光统计等）、视频输出接口（MIPI TX或者并行RGB输出），以及一个控制管理模块，通常挂在I2C或AXI-Lite总线上，负责参数配置和寄存器读写。

Dehaze算法流水线内部分成五个子模块，按数据流顺序串联：

1. RGB最小值模块（求暗通道初值）
2. 多级滑窗最小值滤波模块（生成暗通道图）
3. 大气光估计模块（逐帧统计+时间滤波）
4. 透射率计算模块（定点乘加+查找表）
5. 图像恢复模块（除法近似+像素融合）

整条流水线设计成两级流水结构。第一级是“流式处理”，数据进来后按行依次经过最小值滤波、透射率计算，输出的透射率延迟若干行；第二级是“帧级反馈”，需要用前一帧估计的大气光A来处理当前帧的透射率和恢复，所以数据在进入恢复模块前需要做行对齐和帧对齐缓冲。

3.2 行缓存与滑动窗口的实现细节

滑动窗口是整个FPGA图像处理的基础，也是新手最容易写崩的地方。以5x5最小值滤波为例，核心是用4条行缓存加5组移位寄存器。行缓存的深度是图像行宽，宽度是像素位宽。每一行数据进来，先写入当前行的移位寄存器组，然后依次向下一行推进，形成5x5的窗口数据矩阵。

在Verilog里实现时，有个细节一定要注意：行缓存的写入和读出时序必须严格配合行同步信号的有效窗口。我见过很多开发者在仿真时一切正常，上板后边缘几列像素错位、颜色花掉，都是因为行缓存的读写控制没有处理好行首和行尾的无效像素（HBlank）区域。正确做法是在计数器里把有效像素的起始和结束位置都拉出来，写指针和读指针严格限定在有效像素范围内。

窗口数据就绪后，取25个像素的最小值可以用比较器树，两级比较器就够了。先分成5组，每组5个像素互相比较取最小，再把这5个中间结果比较一次，一共用到30个比较器。对FPGA这种并行资源丰富的平台来说，30个LUT级别的比较器几乎不占什么资源。如果窗口增大到7x7，那就需要49个比较器，占用会明显上升。这也就是为什么我建议在多级小窗口方案上花功夫，而不是直接上一味追求大窗口。

3.3 大气光估计的流水线实现

大气光估计在FPGA上不如前面几个模块那么“流式”，因为它需要跨帧处理。我的实现思路是：

• 暗通道数据流进入统计单元，设一个寄存器存储当前帧最大的暗通道值，每来一个新像素就比较一次，大于就更新。
• 与此同时，原图数据流进入另一个统计单元，但只统计那些暗通道值大于阈值的对应像素。这里需要把原图延迟，等待暗通道结果，做像素级对齐。
• 帧同步信号到来时，一帧结束，把统计得到的最大值锁存，并更新给后续模块，同时复位统计寄存器开始新一帧的统计。
• 为了稳定性，锁存后的A值不要直接使用，而是和上一帧的A做一次加权平均：A_cur = alpha * A_frame + (1-alpha) * A_prev。alpha一般取0.05到0.1，在FPGA上实现就是一次乘加。

这种做法虽然牺牲了“全局精确性”——严格来说A应该取暗通道前0.1%亮度的对应位置，但工程上“全帧最大”已经足够。雾天的暗通道最大值天然高，无雾区域暗通道值很低，所以全局最大值基本都落在浓雾区域，误差很小。

3.4 透射率恢复模块的定点量化策略

透射率和图像恢复这两个模块在整个流水线中涉及的定点运算最复杂，也最容易出问题。我调试时吃过亏的地方就是位宽截断：运算中间结果的位宽明明够，截断后低几位丢得太狠，结果图像偏色或者出现色阶断层。

这里给出我验证过的一套量化参数（以8比特输入输出为例）：

• RGB通道：8位无符号，范围0到255。
• 暗通道初值：3个通道取最小值，依然是8位。
• 暗通道滤波结果：8位。
• A值估计：12位，从8位原图扩展而来，方便做除法精度保留。
• 透射率计算中间值：用32位定点，其中整数位4位，小数位28位。计算t = 1 - ω * I_c / A_c时，先把ω和1/A_c合并成系数，I_c乘这个系数后右移28位，得到定点小数。这个精度在FPGA上已经远高于人眼分辨力了。
• 图像恢复时1/t查找表的输入用t的高8位，输出为32位定点小数，计算J时一次乘法加一次加法搞定。

这个量化方案在MATLAB定点仿真和FPGA实际输出之间做过对比，PSNR能到42dB以上，肉眼完全看不出差距。

3.5 时序约束与跨时钟域处理

Dehaze流水线通常工作在视频像素时钟域。MIPI接收端出来的是什么时钟频率，整个Dehaze模块就跟着跑什么频率。很多通用视频平台是24MHz、74.25MHz、148.5MHz这些速率的像素时钟，Dehaze流水线要在这个频率下保证一个像素在一个时钟周期内处理完。如果时序收敛有问题，第一件事不是优化布局布线，而是检查关键路径。Dehaze模块最长的组合逻辑链通常在透射率计算和图像恢复的定点乘法上。在Vivado里查看时序报告后，如果发现关键路径绕了很远，可以在乘法器前加一级流水寄存器，把组合逻辑拆分成两级。

跨时钟域主要集中在参数配置上。视频流是像素时钟域，CPU配置寄存器是AXI-Lite时钟域，这两个域之间必须做同步处理。我的习惯是：所有配置寄存器用AXI-Lite域写入，写完置一个更新标志位，在视频域中检测到该标志时，用两级同步寄存器把数据打拍到视频域。这样虽然会引入几个时钟周期的延迟，但完全避免了亚稳态风险。

4. 实操过程中遇到的问题与排查经验

4.1 输出图像整体偏色，青色过重

这个问题我在第一版硬件上遇到过。现象是处理完的雾图，天空区域明显发青，绿色植物的颜色也不正。排查思路分两步：第一步检查暗通道滤波的窗口大小。如果窗口太小，暗通道估计偏小，透过率计算偏大，导致恢复时蓝色通道的提升过猛。我的解决方法是把最小值滤波的窗口从5x5加大到7x7，并且连续做两级串行滤波，等效窗口约13x13，接近桌面算法常用的15x15。第二步检查透射率下限t0的取值。t0设得太小，透射率趋近零的区域（浓雾区）会过度增强，蓝色通道失真更明显。把t0从0.05调整到0.15后，偏色问题基本解决。

4.2 画面边缘出现纵向条纹或伪影

这个问题的根源通常不在Dehaze算法本身，而在行缓存和边界填充的匹配上。滑动窗口处理到图像的左边缘和右边缘时，窗口会跑到有效像素范围外。这些位置的数据如果没有正确处理，在图上就表现为边缘的纵向条纹。解决办法是给行缓存加镜像填充逻辑：当横向计数小于窗口半宽时，用同行的镜像像素填充；当横向计数超过图像宽度减窗口半宽时，用反向镜像填充。镜像填充比补零填充的效果好很多，尤其是边缘区域的纹理细节不会被破坏。

4.3 透雾后的图像出现闪烁，亮度跳变

这类问题十有八九出在A值的稳定性上。我刚提过A值如果不加时间滤波直接逐帧更新，前后帧的A值会有波动，导致整体亮度一跳一跳的。解决方法是增加一个帧级的IIR低通滤波器，对A值进一步平滑。alpha系数的选择需要现场调试，我最后固定在0.08，画面亮度的变化已经非常平滑，而且没有拖影。

还有一个细节容易被忽略：直接从传感器出来的RAW图经过Debayer之后，RGB通道的增益其实是不同的。在求暗通道、计算透射率、恢复图像时，如果不对白平衡增益做归一化处理，透雾图像很容易出现整体色偏。我的做法是在Dehaze模块前面加一个简单的增益补偿：在计算暗通道时，先把三个通道除以各自的白平衡增益，恢复图像时再乘回来。

4.4 资源不足与时序收敛问题

BRAM的规划是Dehaze模块能否放下去的关键。以1080p为例，每行需要1920个像素存储，如果每个像素是24位（RGB888），一行就要约4.6KB。5级级联的滤波需要4条行缓存做暗通道、4条行缓存做透射率滤波，再加上原图延迟线，总共差不多要40到50KB的BRAM。这个量对于Artix-7 200T芯片来说占总BRAM的20%左右，完全不紧张。但如果用资源更小的芯片，比如Zynq-7010，BRAM总量只有270KB，Dehaze加其他ISP模块会非常紧张。这时候可以考虑把行缓存的位宽从24位压到16位，牺牲一点暗通道精度换取容量，实测效果仍可接受。

时序方面，如果乘法器使用LUT实现，路径延迟明显。我通常会用Xilinx的DSP48E1硬核来实现定点乘法，这一个改动能把关键路径缩短至少一个级别。还有一个常见的优化点：把透射率计算模块里的除法查找表提前一拍从寄存器里读出，做到下一拍直接用，避免查表和后续运算串行在这种组合逻辑里。Vivado里的UltraFast设计方法学对此有详细说明，照着调即可。

4.5 验证与对比方法

算法在FPGA上实现后，必须和软件仿真结果对比，否则没法确认硬件逻辑是否正确。我的做法是：用MATLAB读同一张雾图，执行和FPGA完全一致的定点算法（注意，不是浮点算法，而是和我最终量化方案一致的定点版本），得到一张参考输出图。然后把FPGA处理同一个输入的输出图像通过串口、USB或者SD卡导出来。在MATLAB里对两张图做逐像素对比，计算PSNR和差值图。PSNR低于40dB或者差值图存在明显的区域块，就说明硬件逻辑某处有偏差。这个对比方法帮我抓到了好几个逻辑bug，尤其是定点截断位置选错的问题。

5. 性能实测结果与扩展方向

5.1 实测数据

我在Xilinx Zynq UltraScale+ MPSoC平台和一片低成本的Artix-7 200T上都完整跑过这套Dehaze流水线，结果如下：

处理延迟方面，从第一个像素进入到第一个像素输出，暗通道滤波是21行延迟，透射率细化是11行延迟，加上其他的对齐缓冲，总延迟控制在三个图像帧以内。对于实时视频链路来说，这个延迟对用户体验几乎无感。

主观效果上，对一个浓雾场景的测试视频，透雾后的图像在对比度、细节纹理和颜色还原上都有明显提升。处理前后图像的局部对比度平均提升约2.4倍，雾区细节的可见度从几乎无法辨认到能清晰分辨出车辆轮廓。虽然和桌面级浮点算法相比还有一点点差距，但在嵌入式实时处理的框架下，这个效果完全满足工程要求。

5.2 可能的扩展方向

Dehaze模块做完整后，自然可以往几个方向扩展。第一个方向是带回片内亮度统计的自适应参数控制，让ω和t0根据场景动态调整，比如在雾天和正常天气之间平滑切换，而不是所有场景都用一组参数。第二个方向是集成视频增强功能，比如在透雾之后再接一个局部直方图均衡模块，进一步增强低照度下的对比度。第三个方向是支持多路视频的同时透雾，多路MIPI输入进来，Dehaze模块做成时分复用，一个模块轮流处理多路视频流，资源利用率更高。第四个方向是结合神经网络做雾浓度估计，给透雾强度提供一个更智能的参考。

这套架构不只是在雾天有用。雨天、烟尘、薄雾、逆光等低能见度场景下的图像增强，算法流程其实高度相似，改一改参数就能复用。

6. 调试工具与方法：仿真之外的实战技巧

6.1 用好仿真一定要用带测试台的模块级测试

写Dehaze模块，不能一上来就做全系统联调。一定要做充分的模块级仿真。我写每个子模块都会配一个独立的testbench，喂入简单的递增图像或固定色块，验证模块的输出是否符合预期。比如暗通道滤波模块，我会生成一个5x5的测试图，手动算好中间像素的滤波结果，仿真时做比较。如果这一步都没法确认，后面整链路调不通，就很难定位是哪一级出了问题。

6.2 ILA抓信号：状态机的强制约束

FPGA调试和软件调试不同，你不能随便打断点。Xilinx提供的ILA调试核是嵌入式调测最重要的帮手。但ILA抓信号有条件：只能抓有限的信号深度，深度受BRAM容量限制。我常把ILA挂在Dehaze模块的输入、透射率计算输出、恢复模块输出这三处，每个位置抓256个深度就够了。拉出时序波形后，看同步信号和像素数据的对应关系，一眼就能判断数据流是否对齐。

我第一次上板调试时，正是靠ILA抓到了行计数错位的bug——输出图像里有一条垂直的移位带，波形一看就明白是行缓存读指针动得晚了一拍。

6.3 参考硬件平台：用什么板子少走弯路

FPGA开发板的选择直接影响效率。做图像处理，建议选择带MIPI接口、DDR3/DDR4内存颗粒、HDMI输出的板子。我首推Xilinx的Zynq系列开发板，比如Zynq-7020或者Zynq UltraScale+ MPSoC。Zynq的优势在于ARM和FPGA在同一个芯片里，调试、传数据、做控制逻辑都很方便。如果纯做FPGA验证，Artix-7系列配合FMC接口的摄像头模组，也完全能跑。黑金、正点原子或者米尔科技的板卡都有视频处理的参考例程，能省不少前期开发时间。看重性价比的话，高云或者安路的FPGA也有不错的表现，只是生态和IP库相对薄弱，工具链需要熟悉一下。

最后一个小技巧

做完这套Dehaze之后我还有几点体会。首先是算法验证阶段就别偷懒，尽量用MATLAB定点仿真去对齐硬件，等硬件做出来再返工查算法，代价会大得多。其次是参数化的思想很重要，ω、t0、滤波窗口大小、A值平滑系数，全都做成寄存器可配，这样在现场调效果时不用改代码重新编译，直接在软件端改参数就行。最后，如果做视频处理，一定要想清楚你的视频流里有没有OSD叠加。OSD字符如果在Dehaze之前叠加，透雾会把字符一起处理掉，导致文字变淡变形，所以一般要放在Dehaze之后做OSD。这个顺序问题看似小，影响却很大，我就是吃了这个亏才记住的。