4. 图像采集与预处理
安防摄像头的烟火检测系统，其性能上限并非由算法模型单独决定，而是由“图像采集与预处理”这一前端链路的质量所框定。若视频流接入不稳定、帧提取存在撕裂、图像噪声淹没细小的烟雾纹理，或色彩空间选择不当导致火焰特征被压缩，后续任何高精度的深度学习模型都将难以发挥效用。本章将深入拆解从物理摄像头到算法输入张量之间的完整工程链路，涵盖协议接入、帧同步、图像增强与色彩空间变换，并结合实战案例说明如何针对烟火场景进行参数调优。
上图展示了本章节的核心工程链路。从左侧的物理视频源开始，经过协议解析、解码、帧同步、图像增强，最终在色彩空间转换后输出适合烟火检测算法处理的多通道数据。整个过程环环相扣，任何一个环节的参数设置不当，都可能导致检测精度下降或系统延迟超标。
4.1 视频流接入：RTSP与ONVIF的工程实践
核心原理：安防摄像头主流的网络协议为RTSP（实时流传输协议），用于控制流媒体会话的建立与播放。而ONVIF（开放网络视频接口论坛）则定义了设备发现、媒体配置、PTZ控制等标准接口。在实际部署中，我们通常使用ONVIF进行设备发现与参数配置，使用RTSP URL获取具体的视频流。RTSP本身并不传输视频数据，而是通过RTP（实时传输协议）承载H.264/H.265编码的码流。
操作流程：
- 设备发现与鉴权：通过ONVIF的WS-Discovery协议在局域网内探测摄像头，获取其IP、端口、媒体服务地址。使用摄像头管理员账号获取RTSP认证所需的用户名与密码。
- RTSP URL构造：不同厂商的URL格式略有差异，但通常遵循
rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[stream_type]的格式。例如海康威视的主码流为/h264/ch1/main/av_stream，子码流为/h264/ch1/sub/av_stream。 - 解码与缓冲策略：使用FFmpeg或GStreamer进行硬件/软件解码。为避免网络抖动导致的播放卡顿，需要设置合理的Jitter Buffer（抖动缓冲），通常为100-300ms。对于烟火检测，建议使用低延迟模式，关闭B帧重排序或使用B帧作为参考，以降低端到端延迟。
4.2 帧提取与时间戳同步
核心原理：视频流本质上是连续图像的编码序列。H.264/H.265编码中，I帧（关键帧）是完整的图像，而P帧/B帧仅存储与前一帧的差异。烟火检测算法通常需要处理连续的RGB帧，因此必须从解码器中提取完整的图像帧。帧提取的关键在于时间戳对齐——即确保提取的每一帧对应真实的物理时刻，避免因解码延迟导致的时间漂移。
判断方法与操作流程：
- 帧类型过滤：在解码回调中，仅当帧类型为AV_PICTURE_TYPE_I或AV_PICTURE_TYPE_P时，才将其转换为OpenCV的Mat对象。B帧由于依赖未来帧，会引入额外延迟，在实时检测场景中建议丢弃或仅用于参考。
- 时间戳处理：使用FFmpeg的
pts（显示时间戳）结合time_base换算为毫秒级时间。若摄像头支持PTP（精确时间协议），则直接使用硬件时间戳。 - 分辨率归一化：烟火检测的输入尺寸通常为416x416或640x640。若摄像头输出为1920x1080，需要先进行等比例缩放并填充至目标尺寸，避免直接拉伸导致火焰形状畸变。
| 参数项 | 推荐值/策略 | 说明 |
|---|---|---|
| 解码线程数 | CPU核数-1 | 避免与检测推理线程争抢CPU资源 |
| 帧缓冲队列 | 5-10帧 | 队列过短易丢帧，过长增加延迟 |
| 丢帧策略 | 优先丢B帧 | B帧对画面质量影响最小，且不参与后续参考 |
| 色彩转换格式 | YUV420P → BGR | 解码器原生输出YUV，需转换供OpenCV使用 |
4.3 图像去噪：保留烟雾纹理与火焰边缘
核心原理：低照度环境下，摄像头传感器噪声（高斯噪声、椒盐噪声）会严重干扰烟雾的微弱纹理特征。但过度去噪又会模糊火焰的锐利边缘，导致检测框抖动。因此，去噪需要在“平滑噪声”与“保留边缘”之间取得平衡。
方法对比：
- 高斯滤波：计算速度快，但会均匀模糊所有区域，导致火焰边缘被削弱。适用于光照充足、噪声较低的白天场景。
- 双边滤波：在平滑噪声的同时，根据像素灰度差异保留边缘。但计算量较大，且对参数（空间sigma、颜色sigma）敏感。推荐用于夜间烟火检测。
- 引导滤波：引导图与输入图一致时，具有边缘保持特性，且计算复杂度与滤波窗口大小无关，适合实时系统。
4.4 光照校正：应对逆光与阴影干扰
核心原理：安防场景常面临逆光（窗户、门口）、阴影（树木、建筑）以及夜间红外补光不均匀等问题。光照校正的目标是增强暗部细节，同时抑制高光区域的过曝，使火焰（通常为亮黄色或红色）与背景的对比度更加明显。
操作流程：
- 直方图均衡化（HE）：将图像的灰度直方图分布拉伸至整个灰度范围。但全局HE容易放大噪声，建议使用CLAHE（限制对比度自适应直方图均衡化），将图像划分为8x8的块，并对每个块进行局部直方图裁剪，限制对比度放大倍数（通常clip limit设为2.0-3.0）。
- 伽马校正：当图像整体偏暗时，使用
gamma < 1的幂次变换（如0.5）提升暗部亮度。但需注意，伽马校正会改变火焰的颜色饱和度，可能影响基于HSV色彩空间的火焰判定阈值。 - Retinex算法：模拟人眼对光照的感知，将图像分解为反射分量与光照分量。适用于光照不均严重的场景，但计算开销较大，在嵌入式设备上需谨慎使用。
4.5 色彩空间转换：RGB/HSV/YUV的选择逻辑
核心原理：RGB色彩空间适合显示，但三个通道高度相关，且对光照变化敏感。HSV（色调、饱和度、明度）将色彩信息与亮度分离，使得火焰的“橙红色调”可以独立于光照强度进行阈值判断。YUV（或YCbCr）是视频编码的标准色彩空间，其Y分量代表亮度，U/V分量代表色度，常用于分离亮度噪声与色彩噪声。
判断方法与适用场景：
| 色彩空间 | 火焰特征表现 | 适用场景 | 注意事项 |
|---|---|---|---|
| RGB | R通道值显著高于G/B通道 | 简单阈值初筛 | 受光照影响大，需配合亮度归一化 |
| HSV | H通道在0-30°（红橙），S通道高，V通道较高 | 火焰颜色分割 | H通道在低亮度时不稳定，需结合V通道判断 |
| YUV | Y分量高，U分量偏低（偏黄），V分量偏高（偏红） | 夜间红外模式 | 红外图像下色彩信息弱，主要依赖Y分量纹理 |
工程实践：在烟火检测模型中，通常不直接将原始RGB输入网络，而是将RGB转换到HSV后，提取H、S、V三个通道作为额外的输入特征，与RGB通道拼接成6通道输入。或者，更高效的做法是仅使用YUV的Y分量（灰度图）进行烟雾检测，因为烟雾在灰度图中表现为模糊的灰白色区域，而在U/V分量中缺乏稳定的色彩特征。
// C++伪代码示例：RGB转HSV并提取火焰候选区域
cv::Mat rgb_frame, hsv_frame;
cv::cvtColor(rgb_frame, hsv_frame, cv::COLOR_BGR2HSV);
cv::Mat mask;
cv::inRange(hsv_frame, cv::Scalar(0, 50, 50), cv::Scalar(30, 255, 255), mask); // 红色火焰
cv::Mat mask2;
cv::inRange(hsv_frame, cv::Scalar(160, 50, 50), cv::Scalar(180, 255, 255), mask2); // 红色边界
cv::bitwise_or(mask, mask2, mask);
// 后续可结合形态学操作与轮廓分析4.6 案例拆解：化工厂储罐区烟火检测系统的图像链路调优
背景与约束：某化工厂在储罐区部署了8路1080p高清摄像头，要求实现24小时烟火检测。现场存在以下挑战：夜间仅有红外补光，画面为灰度模式；白天逆光严重，储罐反光强烈；且厂区有蒸汽管道，经常产生类似烟雾的水蒸气干扰。
初始现象与目标：初始系统直接使用RGB图像输入YOLOv5模型，误报率高达每路每小时15次，且夜间漏检率超过30%。目标是将误报率降至每路每小时2次以内，漏检率低于5%。
分析判断过程：
- 通过日志分析发现，误报主要来源于水蒸气区域在HSV空间中的色相与火焰相近（偏白黄色）。
- 夜间漏检是因为红外图像下火焰的红色特征消失，仅表现为高亮区域，与背景中的白炽灯难以区分。
- 进一步检查发现，原始视频流存在约200ms的抖动，导致帧间差分时产生大量边缘噪声。
实际操作步骤：
- 第一步：将视频流接入改为RTSP over TCP，并设置Jitter Buffer为150ms，消除网络抖动。
- 第二步：在预处理中，将图像从RGB转换到YUV，仅使用Y分量进行烟雾检测（因为烟雾在灰度图中表现为边缘模糊的亮斑），同时使用HSV的H/S通道进行火焰检测（白天模式）。
- 第三步：针对夜间模式，关闭色彩空间转换，直接使用Y分量，并应用CLAHE增强局部对比度，同时降低火焰检测的亮度阈值。
- 第四步：引入水蒸气排除逻辑：检测到高湿度区域（通过背景建模判断为周期性出现的半透明区域）时，降低该区域的检测置信度权重。
结果对比与复盘：经过调优后，误报率降至每路每小时1.2次，漏检率降至3.8%。夜间检测率提升至92%。复盘发现，关键成功因素在于场景自适应的色彩空间切换——白天依赖HSV的色度信息，夜间依赖YUV的亮度纹理信息。代价是增加了约15%的CPU负载，但通过将CLAHE算法优化为查表法实现，最终在嵌入式设备上保持了实时运行。