控制室里的监控画面往往是最枯燥的但一旦画面里出现不该有的红色谁都不敢大意。之前给某个厂区做安防监控需求评估时对方问能不能用现有摄像头自动识别早期火情不需要换硬件最好快速出一版可演示的原型。当时我第一反应是这套东西用MATLAB做非常合适因为图像处理工具箱成熟建模调试快还能顺手做一套带GUI的操作界面让非算法背景的人也能直接上手。这就是这套基于MATLAB的火灾检测系统带GUI界面的由来。它的核心是把颜色分割、运动检测、形态分析三个环节串成一条完整链路最终覆盖从视频流读取、火焰像素判据到界面报警的整个过程。无论你是做毕业设计、课程项目还是想验证某个检测算法是否可行这套系统的价值在于不需要先啃一堆论文也能把链路跑通并且清楚每一步在做什么、为什么这么做。1. 先弄清楚火在图像里长什么样颜色、运动、闪烁三类判据1.1 画面出现红色为什么不能直接告警很多文章在讲火焰检测时第一个条件永远是找红色像素比如经典的R G B规则。听起来很直接但如果你真的拿一段监控视频去试就会发现问题很大红色标语、红色工程车、穿红衣服的巡检员、LED广告牌、夕阳反光这些东西在RGB空间里和火焰像素高度相似。我第一次跑原型时屏幕上飘过一段红色横幅系统直接给了最高警报但现场连个火星都没有。所以核心问题不是找出红色而是找出像火一样会动、会长大、会闪烁的红色。火焰区别于普通红源的关键从来不是单一颜色特征而是它在时间序列里的表现。换句话说一张静态照片很难准确判断是不是火但连续几帧视频可以。1.2 火焰在图像序列里的四个可观察特征我把实际能用的判据整理成一张表后续章节的算法基本都围绕这四个特征展开特征可观测表现对检测的价值颜色火焰像素通常满足R分量偏高G分量居中B分量最低整体呈黄红暖色把候选区域从全画面缩小到少数连通域运动火焰形状在相邻帧之间变化剧烈边缘抖动明显排除红旗、红色车漆这类静止红源面积早期火情从点火到发展火焰区域面积总体呈增长趋势参考人走路时的衣服移动面积不会一直膨胀闪烁火焰亮度存在7~13Hz左右的往复波动轮廓在扩张和收缩间不断切换最强排除手段几乎能直接区分火焰和红色移动物体注意一个容易误解的点这四类特征不是满足一个就报警而是逐级筛选。我的做法是把它们设计成管道式的判据颜色粗筛、运动精筛、时序稳筛。1.3 判据组合逻辑先粗筛还是先细筛先做颜色分割的最大好处是计算量低。一帧1080p图像有约200万个像素全图做帧差和形态学分析很吃力但先用颜色规则筛掉95%的区域后面所有计算都只针对候选火焰区域。处理顺序直接决定了整个系统的实时性尤其是涉及GUI连续刷新时这一步优化比后面所有花哨算法都重要。2. 视频流接入与预处理让MATLAB吃到干净的数据2.1 离线视频与实时摄像头两种接入方式MATLAB读视频的方式很简单但要分清楚两种来源。离线回放用VideoReader实时采集用webcam对象。原型阶段我强烈建议先用离线视频调试算法因为你可以反复拖动到同一帧对比输出摄像头场景很难复现等算法稳定了再接实时流。两种方式的初始化代码完全不同% 离线视频 vidObj VideoReader(test_video.mp4); % fps vidObj.FrameRate; % 后面算闪烁特征会用到 % 实时摄像头需要加分辨率参数 % cam webcam(1); % cam.Resolution 640x480; % preview(cam);一个很容易踩的坑MATLAB对中文路径和某些老式编码视频支持不好实测中我一般先把测试视频统一转成H.264的MP4文件名也改成英文。这听起来是小事但能省下大量排查读取失败的精力。另外读取大视频时建议用循环读帧而不是read(vidObj)一次性把全部帧加载进内存否则4GB的内存很容易被塞满。2.2 预处理三步走缩放、滤波、亮度归一化拿到原始帧后直接丢进检测算法是新手最容易犯的错误。我做预处理按三步走缩放。宽高各缩到原来的一半甚至四分之一速度提升远超分辨率损失。火焰本身是区域级目标不需要高清细节。滤波。用medfilt2做3×3中值滤波消除摄像头传感器热点噪点后面做帧差时能减少许多孤立闪烁点。亮度归一化。监控画面在一天内亮度变化很大我会先算整帧的平均亮度再乘一个系数把平均亮度压到某个基线附近减少光照漂移对固定阈值的影响。frameResized imresize(frame, [240 320]); % 统一尺寸 frameDenoised medfilt2(rgb2gray(frameResized), [3 3]);2.3 预处理不是越多越好有段时间我为了提高效果叠加了直方图均衡、锐化、边缘增强一堆操作结果误报反而变多了。因为火焰图像处理要的是保留原始物理特征锐化会放大边缘抖动直方图均衡会改变颜色分布直接干扰后续基于色彩空间的阈值判断。预处理的核心是让数据更干净而不是让画面更好看。这条经验真的很值钱少做一些花哨的预处理检测准确率反而会提升。3. RGB与YCrCb双色彩空间分割阈值怎么敲定才不瞎报3.1 传统RGB火焰判据的写法与明显短板经典火焰颜色规则在网上到处可见大概是这样的R frameResized(:, :, 1); G frameResized(:, :, 2); B frameResized(:, :, 3); maskRGB (R 140) (R G) (G B) (R 190 - G);这条规则在实验室环境确实能分割出火焰区域它的思路也容易理解R最大、B最小、G居中且R分量还要明显高于G。但短板同样突出——RGB三个通道高度相关场景亮度一变三个通道一起变阈值马上失效。同一个火源在白天日光下和夜晚暗光下表现完全不同固定阈值总有一半场景会出问题。3.2 YCrCb颜色空间的优势把亮度剥离开比RGB更稳的是YCrCb色彩空间因为它把亮度分量Y单独抽出来色彩信息集中在Cr红色差和Cb蓝色差两个通道受光照变化的影响小很多。火焰在YCrCb空间下通常表现为Y较高Cr明显高于Cb且Cr分量大于某个下限。YCBCR rgb2ycbcr(frameResized); Y YCBCR(:, :, 1); Cr YCBCR(:, :, 2); Cb YCBCR(:, :, 3); maskYCrCb (Y 150) (Cr 140) (Cb 120) (Cr Cb);实际应用中只依赖一组固定数值是不够的。不同摄像头白平衡参数差异明显标准火焰燃烧物木材、汽油、塑料的色温也不一样。我所采用的策略是把颜色掩膜做成可调参数然后在GUI界面上放滑块让操作者根据当前场景微调。这一点做出来之后整个系统在光照变化下的适应能力有明显提升。3.3 从固定阈值到自适应阈值Otsu方法的使用前提自适应阈值在很多论文里被当成灵丹妙药但我的体会是得看用法。直接在整幅图上跑graythreshOtsu效果并不好因为画面里火焰区域通常只占很小比例Otsu的类间方差会被大面积背景带偏。正确做法是先利用RGB规则粗筛出候选区域缩小到局部ROI后再在ROI内的Cr分量上做阈值分割。这样既避免了全图的偏置又保留了自适应能力。try roiRows stats(i).BoundingBox(2) : stats(i).BoundingBox(2) stats(i).BoundingBox(4); roiCols stats(i).BoundingBox(1) : stats(i).BoundingBox(1) stats(i).BoundingBox(3); level graythresh(Cr(roiRows, roiCols)); adaptiveMask Cr(roiRows, roiCols) (level * 255 - 10); catch % 候选区域过于小时跳过避免empty数据 continue; end3.4 形态学后处理去掉孤立点和填补空洞颜色分割得到的二值图通常是雪花片形状火焰边缘有大量孤立像素核心区域又有小空洞。直接用这种掩码去做连通域分析连通域数量会很碎、很乱。我的操作分两步先用bwareaopen删除面积小于某个阈值比如50像素的小块再用imclose做一次闭运算把相邻区域连起来。bwClean bwareaopen(binaryMask, 50); se strel(disk, 3); bwClose imclose(bwClean, se);这一步之后再通过regionprops标记连通域拿到每个候选区域的面积、外接矩形、质心等属性为后续动态特征识别做准备。这也是判断哪些区域值得继续跟踪的关键节点候选区域超过10个时就该考虑是不是颜色阈值调得太松了。4. 动态特征识别怎么把红旗、红衣服和真火区别开4.1 帧间差分提取运动区域一切动态判据的地基静态红色区域被颜色规则圈出来后下一步就是让它动起来。帧间差分是最经典、也最简单有效的办法计算当前帧与前几帧灰度图的绝对差超过阈值就被认为是运动区域。火焰边缘是剧烈抖动的所以火焰候选区的差分响应通常很强。grayNow rgb2gray(frameResized); diffMap abs(double(grayNow) - double(prevGray)); % 自适应阈值比固定阈值更抗场景抖动 diffThresh max(25, 0.15 * mean(diffMap(:))); motionMask diffMap diffThresh; % 与颜色掩码求交集得到“又红又会动”的区域 candidateMask bwClose motionMask; prevGray grayNow;我的经验是两个参数决定这个环节的好坏一是差分阈值太小人影晃动会产生大量运动区太大会让火焰边缘响应消失二是做差分的帧间隔间隔过大超过5帧会把目标突然消失也算成运动间隔取1~3帧最合适。4.2 面积增长率火在早期是会长大的真实的早期火情有一个特征着火点面积随着时间推移总体增加。而人走来走去时衣服红色区域的面积是在一个固定范围内波动不会持续膨胀。我用一个循环队列保存最近5帧的候选区域面积只要满足连续若干帧面积单调递增允许小幅抖动就将该区域标记为高温疑点。areaQueue [areaQueue(2:end), currentArea]; % 滑动窗口 if all(diff(areaQueue) -5) currentArea areaMinThresh areaAlarm true; end这一步是排除移动红源的利器。穿红衣的人即便被误分割出来他的面积也不会持续膨胀超过10帧而点燃的废纸篓在十秒内面积通常能翻好几倍。两者在时序上的表现差异非常明显比单纯依赖某一帧的颜色信息可靠得多。4.3 圆形度与闪烁频率两个容易忽略的辅助判据圆形度是用来衡量轮廓接近圆形的程度公式是4*pi*面积/(周长^2)。圆形度越接近1形状越规整。真实火焰的边缘扭曲、分叉、撕裂圆形度通常远小于1而很多干扰源比如车灯、圆形路牌反射反而形状规整。所以我会把圆形度作为负向判据圆形度异常高比如大于0.7时反而降低权重。闪烁频率是一个理论上很漂亮、实现上很容易翻车的判据。火焰的闪烁频率大约在7~13Hz区间但普通监控摄像头通常只有25~30fps采样率不够高直接用FFT去算频率往往得不到干净的峰值。实操中我改用面积序列的波动强度来近似描述闪烁感连续几帧面积标准差很大说明这个区域在剧烈变化更像火焰反之则可能是平滑移动的物体。4.4 这一环节的完整判定逻辑整个动态判定我不会允许单一规则直接触发报警一定要组合。最终判定优先级大概这样颜色分割产生候选区 → 存在运动响应 → 面积保持增长 → 圆形度低于阈值 → 闪烁强度超过基线。所有条件都满足才真正拉响警报。前面几节看到的误报80%以上会被运动面积增长这两道筛子挡住。5. App Designer下从零搭GUI布局、回调、实时显示不漏帧5.1 为什么用App Designer而不是老式GUIDE老版本MATLAB用户习惯用GUIDE拖拽控件但它维护状态偏麻烦代码生成也比较混乱。App Designer的组件系统更接近现代开发框架UI组件的属性、回调函数组织更清晰还天然支持缩放布局。哪怕你是第一次写GUI花半小时把组件拖到画布上再双击按钮生成回调就能进入开发状态。这套系统我设计的界面很简单功能划分也明确左边一个主坐标轴显示原始视频画面右边一个辅助坐标轴实时显示分割掩码下方一排按钮控制视频加载、开始检测、暂停、复位右下角放阈值滑块、报警状态灯和文本日志区。5.2 控件布局和各部件职责控件类型职责主显示区UIAxes实时播放视频流并在火焰区域绘制红色矩形边框掩码显示区UIAxes显示当前帧的火焰分割二值图方便人工确认判据有没有跑偏打开视频Button调用uigetfile选择视频文件创建VideoReader对象开始/暂停Button控制检测循环的运行状态用状态标志位控制计时器启停阈值滑块Slider调节YCrCb颜色分割阈值范围实现不用改代码的现场调参报警灯Lamp正常状态绿色疑似火焰变黄色确认报警变红色日志区TextArea记录每帧的候选区域数量、报警状态、时间戳5.3 定时器回调实现连续检测别用while循环新手最容易犯的错误是在按钮回调里写一个while true循环做逐帧处理。这样界面会被循环卡死滑块拖不动、按钮没响应用户会以为程序崩溃了。正确做法是使用timer对象设置固定周期比如0.1秒触发一次回调在回调里读取一帧并执行检测。这样UI事件循环始终有空闲时间按钮和滑块都保持可操作。function startDetection(app) app.Timer timer(TimerFcn, (~, ~) stepDetection(app), ... Period, 0.1, ExecutionMode, fixedRate); start(app.Timer); end function stepDetection(app) if ~hasFrame(app.VidObj) stop(app.Timer); return; end frame readFrame(app.VidObj); result runFireDetection(frame, app.ThresholdSlider.Value); % 更新两个坐标轴、状态灯和日志文本 end注意一点readFrame在读取视频最后一帧后会报错所以hasFrame判断必须写在读取之前这就是上面代码里那个判断的作用。5.4 报警输出设计声音、截图、日志一个都不能少光有界面上的红灯闪烁还不够真实监控场景需要多种报警联动。我的做法是确认报警后第一调用系统蜂鸣或播放一段提示音频让值班人员即使没盯屏幕也能听到第二自动截取当前报警帧保存到指定目录并记录时间戳第三把报警事件追加写入文本日志方便事后复盘。if confirmedAlarm beep; % 系统短促提示也可以换 audio file imwrite(frame, fullfile(app.LogDir, [alarm_ datestr(now, yyyymmdd_HHMMSS) .jpg])); app.Log.Value sprintf(%s: 检测到疑似火焰位置(%d,%d)\n, ... datestr(now, HH:MM:SS), centroidX, centroidY); app.AlarmLamp.Color [1 0 0]; end这里有一个很实用的细节截图保存的路径必须提前用exist检查目录是否存在不存在就先mkdir否则第一次报警时程序会因为写文件路径无效而卡在报警环节我遇到过不止一次。6. 实测表现与调优我踩过的四个误报坑6.1 逆光下的红色工程车单色彩空间完全失灵第一次现场测试选在阳光强烈的下午一辆红色工程车从画面中经过逆光时车头漆面反射日光整片车漆在RGB规则下和火焰区域几乎一模一样。后来对比发现工程车区域在YCrCb空间里的Cr、Cb关系和火焰还是有一定差异把判定规则改为双色彩空间取交集后这类误报基本消失。核心经验RGB和YCrCb各有擅长也有盲区组合使用比单独一套可靠得多。6.2 夜间路灯与车灯频闪闪烁判据反而帮倒忙夜间场景里路灯的荧光灯或LED灯存在明显的工频闪烁50Hz/60Hz交流电导致在低帧率摄像头下拍出来会呈现规律性的明暗变化面积序列的标准差高得惊人。我的处理办法是引入面积增长率作为前置条件玩闪烁判据前先看面积是否连续增长。灯光闪烁时面积只有小幅波动但不会单调递增所以会被增长条件拦住。6.3 摄像头参数差异导致阈值失效把参数交给滑块换了一台焦距更广的摄像头之后原本调好的颜色阈值全部失效火焰分割区域大面积缩小。原因很简单不同摄像头自动白平衡、增益算法差异大同一火焰在不同镜头下的色度值可以差出20以上。与其每换一个摄像头就改一次代码不如在GUI上把所有关键阈值做成滑块现场调节后立即看掩码变化。这个改动让系统从算法演示变成可交付工具使用体验上升了一个级别。6.4 实时性与检测精度的平衡点分辨率一律降为320×240做分析主界面上显示的原始画幅可以保持原清晰度检测逻辑都在低分辨率版本上跑。这样在普通笔记本上也能稳定维持在8~10fps的处理速度基本满足实时预警需求。如果还不够快可以对ROI区域做局部加速只有候选区域数量超过设定值时才进入动态特征判断阶段否则直接跳过。6.5 几个典型误报的排查对照表误报现象根因解决动作夕阳红光导致大面积报警全图色温偏暖颜色规则全被触发叠加运动掩码静态红区直接剔除红色车辆驶过产生误报大面积红色位移绕过静态筛引入面积增长率和圆形度判据夜间灯光频闪报警工频闪烁干扰闪烁判据增长条件前置拒绝非递增序列火焰很小却漏报面积阈值定太高候选区被清掉调低bwareaopen面积值提高形态阈值灵敏度写在最后调试这套系统最值得记住的一件事如果只留一条经验我会说把调试视频和实时摄像头分开。我前期花了很多时间在摄像头实时画面上反复试阈值效率极低因为同一个场景很难完全复现。后来改成先录几段典型场景的视频白天、夜晚、红物干扰、真实火焰再在GUI里加载这些视频做反复的参数迭代问题定位速度快了不止一倍。调好之后再切回摄像头你会发现大多数问题在回放阶段就被解决掉了。另外再说一点个人体会这套系统还有往上走的空间比如用深度学习目标检测器替换掉颜色粗筛或用光流法替代帧间差分获得更细腻的运动场。但如果你刚开始做这个方向我强烈建议先把经典判据链路完整跑通因为它能帮你建立对特征如何组合才可靠的直觉。有了这个基础再上复杂模型遇到的坑会少很多。