简介面向计算机视觉开发者和火灾预警系统研究者的YOLO火焰与烟雾检测数据集专注解决不同光照、遮挡和复杂背景条件下火焰与烟雾目标识别难题。资源包共1444个文件包含482个txt标注文件、481张jpg原始图像和481个xml标注文件整体压缩包大小约3.93MB。txt与xml分别对应YOLO和PASCAL VOC两种主流标注格式每张图片中的火焰和烟雾位置均经过精确边界框标注可直接用于YOLOv3、YOLOv4等模型训练也便于迁移到TensorFlow、PyTorch或Darknet等框架。已有2780人学习下载适合需要数据增强、迁移学习或基准测试的火焰烟雾检测任务。开发者可对照图片与边界框快速完成训练验证借助双格式标注灵活切换预处理流程针对小样本还可通过旋转、缩放、翻转等增强手段提升模型泛化能力为火灾预警与安防监控提供可靠的数据支撑。1. YOLO 火焰和烟雾检测数据集一个小样本、双标注的目标检测包我拆过不少目标检测数据集看到fire_smoke-dataset.zip的第一反应是这包比那些动辄几万张的 COCO 子集“寒酸”很多但它恰好是火灾预警场景最缺的那种素材。全量接近五百张图片每张都带火焰和烟雾的标注框而且同时给了 PASCAL VOC 和 YOLO 两种格式——一个适合人看、方便画框调试一个适合直接喂给训练脚本。如果你正在做安全监控、厂区防火这类项目或者踩着 yolov8 训练自己的数据集的路子跑毕设这包能省掉你三天以上的标注时间。但它不是解压就能直接训练的。小样本、火焰烟雾形态多变、双格式标注带来的坐标换算问题都会在训练和验证环节冒出来。这篇就按真实拆包的顺序把文件结构、格式转换、训练参数和最容易翻车的几个坑过一遍。2. 拆开 fire_smoke-dataset.zip目录结构、XML 与 txt 怎么对应2.1 先看清三件套图片、XML、txt 各自管什么解压后第一件事不是急着训练而是把目录角色分清楚。绝大多数公开检测数据集都沿用“图片目录 标注目录”的组织方式这个包也不意外常见结构是images/放 jpgAnnotations/放 VOC 格式的 XMLlabels/放 YOLO 格式的 txt。我习惯先把结构固定好再写检查脚本。原因很直接后续不管是转格式还是做数据增强都依赖文件名的强一致性。图片 299.jpg对应的标注就必须是 299.xml 和 299.txt名字错一个字符训练时就会静默跳过这张图最后发现 mAP 缺了一截还找不到原因。目录/文件格式承担的角色images/.jpg原始图像数字命名Annotations/.xmlPASCAL VOC 标注含 object 标签、边界框像素坐标labels/.txtYOLO 标注每行一个目标类别ID 归一化中心点 归一化宽高图片命名是纯数字序号没有额外前缀这点对我这种要批量处理的人很友好。后面做数据集合并或者按比例划分训练/验证集时直接按数字取模就行不用处理乱七八糟的字符串。2.2 两种标注格式读起来思路完全不同VOC 的 XML 是给人看的。它把图片尺寸、每个目标的类别和边界框绝对坐标全部用标签包起来我贴一个典型片段annotation filename299.jpg/filename size width1280/width height720/height /size object namefire/name bndbox xmin400/xmin ymin150/ymin xmax520/xmax ymax260/ymax /bndbox /object /annotation参数含义很直白name是类别名bndbox里四个值分别是左上角 x、左上角 y、右下角 x、右下角 y单位是像素。这种格式的优势是直观画框调试、人工审核都方便OpenCV 直接拿着坐标往上画就行不需要任何换算。YOLO 的 txt 则完全不同。每行一个目标五个值全是浮点数类别 ID、归一化后的中心点 x、中心点 y、归一化宽度、归一化高度。归一化的意思是除以图片宽高所以火焰在图片左上角的话cx、cy 都会比较小。好处是训练时不管输入图怎么缩放标注都跟着比例走不会错位代价是拿眼睛看 txt 根本看不出框在哪。0 0.359375 0.284722 0.093750 0.152778有经验的开发者看到这种文件会先确认一件事类别 ID 0 到底是 fire 还是 smoke这个包的 XML 里写的是firetxt 里第一列是 0那么 0 就代表 fire。这个对应关系必须写进训练配置不能凭感觉猜。2.3 先跑一遍完整性检查确认图片和标注没有“缺对”我拆数据集的第一步永远是写完整性检查脚本。目标有三确认每张图片都有同名 XML 和 txt确认 txt 文件不为空确认 XML 里的类别都在预期集合里。import os import glob images glob.glob(images/*.jpg) expected_classes {fire, smoke} for img_path in images: stem os.path.splitext(os.path.basename(img_path))[0] voc_path fAnnotations/{stem}.xml yolo_path flabels/{stem}.txt if not os.path.exists(voc_path): print(f[MISS-VOC] {img_path}) if not os.path.exists(yolo_path): print(f[MISS-YOLO] {img_path}) if os.path.exists(yolo_path) and os.path.getsize(yolo_path) 0: print(f[EMPTY-YOLO] {yolo_path})这段脚本的逻辑是先拿到所有 jpg 的文件名主干再拼出预期的 XML 和 txt 路径逐个检查存在性和非空性最后把问题行打印出来。参数上唯一要动的地方是expected_classes如果这个数据集未来加了第三类比如“灯”就得扩展这个集合。实际使用中我会把这套检查做成所有数据集通用的脚本换目录名就能跑因为踩过一次“图片多、标注少”的坑之后就再也不敢跳过这步了。3. 把 VOC 标注转成 YOLO 格式坐标换算与三条校验规则3.1 为什么建议统一成 YOLO 格式如果只想用 YOLO 训练理论上可以只读 txt忽略 XML。但实际拆包时你会发现标注格式转换是躲不掉的一是有些脚本、可视化工具只认 VOC二是如果后续要扩展成 yolo 实例分割还得把边界框转成多边形标签。而训练端是绝对的 YOLO 格式主导因为模型训练时读的就是 txt省去解析 XML 的开销。转换的核心是坐标映射。VOC 里的绝对像素坐标除以图片尺寸就得到归一化的 YOLO 坐标。公式很简单但坑藏在细节里XML 里的size不一定和实际图片一致。如果有人在标注后压缩了图片XML 里还留着旧尺寸换算出的框就会整体偏移。所以转换脚本里必须用 PIL 重新读一次图片真实宽高而不是信 XML 里的数字。3.2 VOC 转 YOLO写一个不会丢框的转换脚本下面这个脚本我做过很多次换成哪个数据集都能用。核心思路是遍历所有 XML解析每个 object 的类别和边界框按公式换算写入同名 txt。import os import glob import xml.etree.ElementTree as ET from PIL import Image CLASS_MAP {fire: 0, smoke: 1} # 类别名 - ID def convert_voc_to_yolo(xml_path, img_path, out_dir): img Image.open(img_path) img_w, img_h img.size tree ET.parse(xml_path) root tree.getroot() lines [] for obj in root.iter(object): name obj.find(name).text.strip() if name not in CLASS_MAP: print(f[SKIP-UNKNOWN] {xml_path} - {name}) continue bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) center_x ((xmin xmax) / 2) / img_w center_y ((ymin ymax) / 2) / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append( f{CLASS_MAP[name]} {center_x:.6f} {center_y:.6f} {width:.6f} {height:.6f} ) stem os.path.splitext(os.path.basename(xml_path))[0] out_path os.path.join(out_dir, stem .txt) with open(out_path, w) as f: f.write(\n.join(lines) \n) # 用法示例 # convert_voc_to_yolo(Annotations/299.xml, images/299.jpg, labels/)逻辑说明CLASS_MAP在代码里写死了类别映射fire 是 0smoke 是 1这必须和训练时data.yaml里的类别顺序一致。坐标换算部分用了两次除法第一次算中心点和宽高的像素值第二次除图片宽高得到归一化值。.6f保留六位小数足够表达亚像素精度也不会让文件膨胀。参数需要注意两个点。第一img_w、img_h是从 PIL 读的真实尺寸不是 XML 里的size这个细节决定转换后框准不准。第二xmin到xmax如果出现负数或者反序说明标注本身有问题最好在脚本里加个判断打印哪张图哪条框违规而不是静默写出一个负数坐标。3.3 转换后必须做的三个校验转换脚本跑完不等于数据能训练。我每次都要再跑一段校验脚本检查三点第一坐标值必须在 0 到 1 之间。YOLO 格式是归一化的如果出现大于 1 的 cx 或 w直接说明换算除错了数。第二中心点必须落在图片范围内——某种意义上这是冗余检查因为归一化后不可能超界但真出现过由脏数据导致的坐标 1.000001。第三类别 ID 不能超过总类别数减一也就是不能出现 ID 大于 1 的行。def validate_yolo_file(txt_path, num_classes2): with open(txt_path) as f: for line_idx, line in enumerate(f, 1): parts line.strip().split() cls_id int(parts[0]) vals [float(v) for v in parts[1:]] if cls_id num_classes: print(f[BAD-CLASS] {txt_path}:{line_idx}) if any(v 0 or v 1 for v in vals): print(f[OUT-OF-RANGE] {txt_path}:{line_idx})这个脚本的num_classes2对应 fire 和 smoke 两类。如果后续加类别忘记同步改这里。校验跑完没有输出才说明这批标注从数字上看是正常的。4. 用 YOLOv8 训练自己的火焰烟雾模型data.yaml、增强与关键参数4.1 写好 data.yaml路径、类别顺序、验证集划分训练前第一步是把数据描述文件写好。YOLOv8 的data.yaml直接决定训练集、验证集路径和类别列表写错一个路径训练直接报错写错类别顺序模型训练时把 0 当 fire、1 当 smoke看起来能跑实际预测全乱。path: ./fire_smoke_dataset train: images/train val: images/val nc: 2 names: 0: fire 1: smoke参数说明path是数据集根目录的绝对或相对路径train和val是相对于path的子目录。nc是类别总数必须和names里的数量一致。类别顺序尤其关键0 永远是 fire1 永远是 smoke和上一章转换脚本里的CLASS_MAP保持一致。数据集小我一般不会手动建 train/val 子目录而是用脚本按 8:2 或 9:1 比例随机划分。火焰烟雾场景里漏检代价高验证集稍微多留一点反而踏实。mkdir -p fire_smoke_dataset/images/train fire_smoke_dataset/images/val mkdir -p fire_smoke_dataset/labels/train fire_smoke_dataset/labels/val ls images/ | awk NR % 5 ! 0 | xargs -I {} mv images/{} images/train/这段命令的逻辑是先建四个目录然后用awk每隔 5 个文件名保留一个到 train其余靠mv移走。百分比可以自己调NR % 5 ! 0是每 5 个取 4 个到 train也就是 80% 训练、20% 验证。要注意的是 labels 也要做一模一样的划分否则图片在 train 里、标注在 val 里训练时一张图也加载不出来。4.2 训练参数小数据集原本就过拟合先看这几项近五百张图放在目标检测里属于小样本训练参数和那些几万张的数据集完全不同。我习惯用 YOLOv8 的 n 模型起步把显存留给更大的输入尺寸。yolo train \ datafire_smoke.yaml \ modelyolov8n.pt \ epochs200 \ imgsz1024 \ batch16 \ patience50 \ augmentTrue \ mosaic0.5 \ degrees5 \ hsv_h0.02参数说明epochs200对于小数据集来说不多因为模型要反复看这些图到熟imgsz1024是这一串参数里最关键的一个——火焰往往是画面里的小目标输入太小会直接抹掉小火焰的细节mosaic0.5让模型每轮有一半概率看到马赛克拼接图能显著缓解小样本的过拟合degrees5允许图片旋转正负 5 度模拟摄像头安装角度偏差hsv_h0.02是色调扰动。这些增强参数在火焰烟雾场景里要讲究。烟雾的颜色从白到灰到黑都有hsv_h稍微加大一点模型更容易学到“颜色变化但形状不变”的烟雾本质。而degrees不能给太大火灾检测场景里倒置或横滚的图片不符合实际监控视角转多了反而制造无效样本。4.3 用迁移学习但要把预训练类别“忘记”到合理程度数据量小从头训练几乎必挂所以要用预训练权重yolov8n.pt做初始化。这一步是在 COCO 上预训练过的模型基础上微调模型已经会提取通用特征火焰的边缘、烟雾的纹理这些低层信息可以复用只需要在高层学习“什么是火、什么是烟”。参数上唯一推荐动的是检测头的学习率。YOLOv8 里可以通过lr0和lrf控制初始学习率和最终学习率小数据集我一般把lr0降到 0.005 左右微调时步子小一点避免把预训练权重冲坏。如果你的 NVIDIA 显卡小于 8GBbatch降到 8imgsz降到 640否则还没跑到第一个 epoch 就 OOM 了。4.4 评估指标火焰烟雾更要盯召回率训练完看验证结果mAP50、mAP50-95、precision、recall 四个值要一起看。其中最重要的其实是召回率。火焰检测漏报的代价远远大于误报——漏掉一个真实火源可能酿成大祸而误报最多就是触发一次假警报。YOLOv8 的验证输出默认会打印每个类别的 AP这时候重点看 smoke 的 AP。烟雾的标注天然比火焰困难因为它边界模糊、半透明同一张图不同标注员画出的框差距很大。如果 smoke 的 AP 明显低于 fire别急着调网络结构先回去看烟雾的标注框是不是偏大或者漏标。模型预测时还可以用conf参数调报警灵敏度。默认阈值 0.25如果希望在监控场景里少漏报降到 0.1如果误报太多提到 0.4。这个数字直接影响误报率和召回率后面接预警系统时就是靠它来平衡。yolo predict modelruns/detect/train/weights/best.pt \ sourcetest_video.mp4 \ conf0.15 \ imgsz1024conf0.15的意思是置信度低于 0.15 的框直接丢弃。这个值越小越敏感但也会带来更多误检实际部署时最好拉出一段真实监控视频跑一遍后数一下误报数量再调。5. 火焰烟雾数据集避坑清单五类翻车现场与处理办法5.1 损失函数降了但精度上不去现象训练时 loss 一路下降降到 0.4 以下打开验证集图片一看框的位置基本对但 mAP50 只有二十几。原因数据集小模型在训练集上“背答案”了。火焰和烟雾样本数少模型记住的是这几百张图里的固定背景和光照条件换一张没见过的监控画面就歇菜。迁移学习也只能缓解不能根治。解决先从数据层面补做更强的增广尤其是 mosaic 和 copy-paste再从模型层面补换更小的模型容量比如从 s 降到 n抑制过拟合。最后实在不行就人工补拍或者从公开视频里截帧凑到千张级别效果会有明显提升。5.2 VOC 转 YOLO 后批量框偏移现象转换完的 txt 里火焰的框全部偏到右下方或者宽高明显比实际大一圈。用可视化脚本把 YOLO 框画回图片每个框都飘。原因XML 里的size和实际图片分辨率不一致。最常见是标注后在修图软件里缩放过图片XML 没跟着更新转换脚本却用 XML 里的旧尺寸做除法导致归一化坐标集体偏移。解决回到转换脚本用 PIL 重新读图片真实宽高完全忽略size节点的值。这个改动就两行代码却能救回整批标注。从那以后我所有转换脚本都默认先Image.open再取img.size绝不信任 XML 里写死的尺寸。5.3 把路边红尾灯认成火把白墙认成烟现象训练完成后跑测试视频晴天傍晚的路口尾灯和落日被大量标成 fire白色雾气、蒸汽、水面反光也被标成 smoke。原因火焰和烟雾的外观本质上是“颜色 纹理 运动”的组合但静态图片模型只能看到颜色和纹理。红色圆形物体像火焰白色半透明的东西像烟雾这种混淆在小数据集下尤其严重因为见过的反例太少。解决最有效的是收集负样本。从监控视频里截取“像但又不是”的帧比如红色车尾灯、晚霞、排气蒸汽标注成背景类加入训练集重训。另一个思路是后续接视频流时用帧间差异做二次确认真实火焰有闪烁和飘动特征静态的红色尾灯没有。5.4 增强参数拉满显存当场爆炸现象训练时把mosaic1.0、degrees30、hsv_h0.5全开又把imgsz设到 1280启动三秒后 CUDA out of memory。原因增强和输入尺寸都在烧显存。mosaic会把四张图拼在一起送进网络输入分辨率加倍显存占用直接翻倍imgsz1280在小显存卡上本来就很极限。解决8GB 显存老老实实imgsz1024、mosaic0.5、batch8。火焰是小目标但 1024 已经能保留足够细节没必要硬上 1280。如果一定要高分辨率训练先看nvidia-smi确认剩余显存再决定参数。5.5 patience 太小模型还没学会就早停了现象训练到第 30 轮验证集 mAP 还在爬升但训练直接停止因为连续 20 轮没有明显改善patience 触发。原因火焰烟雾的难点分布不均匀。有些类别前 10 轮就学得差不多有些难样本要到 80 轮以后才逐渐学会。小数据集训练波动本来就大早停条件太苛刻会在模型还没到最佳点的时候掐断。解决小数据集patience设到 80 甚至 100让它“多熬一会儿”。或者干脆设 200用 epoch 数控制训练时长反正小数据集一个 epoch 就几十秒多跑几十轮代价很小。6. 把模型接进视频预警跳帧检测、阈值与防误报技巧6.1 跳帧检测与置信度阈值模型训练完最终要落到视频流里才能预警。监控摄像头常见 25 帧每秒逐个帧全量推理对 GPU 是浪费因为火焰和烟雾都是慢变化目标写个跳帧检测既能降低延迟又不会漏掉主要事件。import cv2 from ultralytics import YOLO model YOLO(best.pt) cap cv2.VideoCapture(camera_01.mp4) frame_id 0 consecutive_hits 0 ALERT_CONF 0.4 while cap.isOpened(): ret, frame cap.read() if not ret: break if frame_id % 3 ! 0: frame_id 1 continue results model(frame, conf0.15, imgsz1024, verboseFalse) fire_detected any( r.boxes.cls 0 and r.boxes.conf ALERT_CONF for r in results ) if fire_detected: consecutive_hits 1 else: consecutive_hits 0 if consecutive_hits 2: print(f[ALERT] 第 {frame_id} 帧连续检测到火焰) consecutive_hits 0 frame_id 1逻辑说明frame_id % 3 ! 0表示每 3 帧取 1 帧做推理25 帧的摄像头相当于每秒检测 8 次对火灾这种演变缓慢的目标完全够用。ALERT_CONF 0.4是报警阈值低于它只记录不报警减少误报。consecutive_hits 2要求连续两次检测到火焰才报警这是最有效的防误报手段——单帧的偶发误检被直接过滤掉。参数要按场景调摄像头离监控区域远火焰在画面里变成小目标imgsz保持 1024ALERT_CONF可以降到 0.3如果场景里红色物体多比如厂房里的红色设备多ALERT_CONF就得升高同时依赖连续帧确认来压误报。6.2 夜间与逆光场景的验证习惯火焰烟雾模型最怕的是场景光照分布变化。同一个模型白天 mAP 六十多晚上因为光线弱、颜色失真直接掉到三十。这个数据集里的图片偏白天场景部署到夜间场景前必须单独验证。我的习惯是训练完不直接收工而是拿一段夜间视频和一个黄昏视频跑一遍predict看看烟雾在暗背景下能不能分出来。如果夜间漏检严重优先调hsv_h和hsv_s增强模拟不同色温和饱和度重训。从那以后我每次训练完都强制走一遍“白天、黄昏、夜间”三段验证不是等部署到现场才发现模型在晚上是半瞎的。地铁站、仓库、隧道这些光照复杂的场景尤其要跑这一步希望这次的坑记录能帮你少走两趟弯路。本文还有配套的精品资源点击获取
简介面向计算机视觉开发者和火灾预警系统研究者的YOLO火焰与烟雾检测数据集专注解决不同光照、遮挡和复杂背景条件下火焰与烟雾目标识别难题。资源包共1444个文件包含482个txt标注文件、481张jpg原始图像和481个xml标注文件整体压缩包大小约3.93MB。txt与xml分别对应YOLO和PASCAL VOC两种主流标注格式每张图片中的火焰和烟雾位置均经过精确边界框标注可直接用于YOLOv3、YOLOv4等模型训练也便于迁移到TensorFlow、PyTorch或Darknet等框架。已有2780人学习下载适合需要数据增强、迁移学习或基准测试的火焰烟雾检测任务。开发者可对照图片与边界框快速完成训练验证借助双格式标注灵活切换预处理流程针对小样本还可通过旋转、缩放、翻转等增强手段提升模型泛化能力为火灾预警与安防监控提供可靠的数据支撑。1. YOLO 火焰和烟雾检测数据集一个小样本、双标注的目标检测包我拆过不少目标检测数据集看到fire_smoke-dataset.zip的第一反应是这包比那些动辄几万张的 COCO 子集“寒酸”很多但它恰好是火灾预警场景最缺的那种素材。全量接近五百张图片每张都带火焰和烟雾的标注框而且同时给了 PASCAL VOC 和 YOLO 两种格式——一个适合人看、方便画框调试一个适合直接喂给训练脚本。如果你正在做安全监控、厂区防火这类项目或者踩着 yolov8 训练自己的数据集的路子跑毕设这包能省掉你三天以上的标注时间。但它不是解压就能直接训练的。小样本、火焰烟雾形态多变、双格式标注带来的坐标换算问题都会在训练和验证环节冒出来。这篇就按真实拆包的顺序把文件结构、格式转换、训练参数和最容易翻车的几个坑过一遍。2. 拆开 fire_smoke-dataset.zip目录结构、XML 与 txt 怎么对应2.1 先看清三件套图片、XML、txt 各自管什么解压后第一件事不是急着训练而是把目录角色分清楚。绝大多数公开检测数据集都沿用“图片目录 标注目录”的组织方式这个包也不意外常见结构是images/放 jpgAnnotations/放 VOC 格式的 XMLlabels/放 YOLO 格式的 txt。我习惯先把结构固定好再写检查脚本。原因很直接后续不管是转格式还是做数据增强都依赖文件名的强一致性。图片 299.jpg对应的标注就必须是 299.xml 和 299.txt名字错一个字符训练时就会静默跳过这张图最后发现 mAP 缺了一截还找不到原因。目录/文件格式承担的角色images/.jpg原始图像数字命名Annotations/.xmlPASCAL VOC 标注含 object 标签、边界框像素坐标labels/.txtYOLO 标注每行一个目标类别ID 归一化中心点 归一化宽高图片命名是纯数字序号没有额外前缀这点对我这种要批量处理的人很友好。后面做数据集合并或者按比例划分训练/验证集时直接按数字取模就行不用处理乱七八糟的字符串。2.2 两种标注格式读起来思路完全不同VOC 的 XML 是给人看的。它把图片尺寸、每个目标的类别和边界框绝对坐标全部用标签包起来我贴一个典型片段annotation filename299.jpg/filename size width1280/width height720/height /size object namefire/name bndbox xmin400/xmin ymin150/ymin xmax520/xmax ymax260/ymax /bndbox /object /annotation参数含义很直白name是类别名bndbox里四个值分别是左上角 x、左上角 y、右下角 x、右下角 y单位是像素。这种格式的优势是直观画框调试、人工审核都方便OpenCV 直接拿着坐标往上画就行不需要任何换算。YOLO 的 txt 则完全不同。每行一个目标五个值全是浮点数类别 ID、归一化后的中心点 x、中心点 y、归一化宽度、归一化高度。归一化的意思是除以图片宽高所以火焰在图片左上角的话cx、cy 都会比较小。好处是训练时不管输入图怎么缩放标注都跟着比例走不会错位代价是拿眼睛看 txt 根本看不出框在哪。0 0.359375 0.284722 0.093750 0.152778有经验的开发者看到这种文件会先确认一件事类别 ID 0 到底是 fire 还是 smoke这个包的 XML 里写的是firetxt 里第一列是 0那么 0 就代表 fire。这个对应关系必须写进训练配置不能凭感觉猜。2.3 先跑一遍完整性检查确认图片和标注没有“缺对”我拆数据集的第一步永远是写完整性检查脚本。目标有三确认每张图片都有同名 XML 和 txt确认 txt 文件不为空确认 XML 里的类别都在预期集合里。import os import glob images glob.glob(images/*.jpg) expected_classes {fire, smoke} for img_path in images: stem os.path.splitext(os.path.basename(img_path))[0] voc_path fAnnotations/{stem}.xml yolo_path flabels/{stem}.txt if not os.path.exists(voc_path): print(f[MISS-VOC] {img_path}) if not os.path.exists(yolo_path): print(f[MISS-YOLO] {img_path}) if os.path.exists(yolo_path) and os.path.getsize(yolo_path) 0: print(f[EMPTY-YOLO] {yolo_path})这段脚本的逻辑是先拿到所有 jpg 的文件名主干再拼出预期的 XML 和 txt 路径逐个检查存在性和非空性最后把问题行打印出来。参数上唯一要动的地方是expected_classes如果这个数据集未来加了第三类比如“灯”就得扩展这个集合。实际使用中我会把这套检查做成所有数据集通用的脚本换目录名就能跑因为踩过一次“图片多、标注少”的坑之后就再也不敢跳过这步了。3. 把 VOC 标注转成 YOLO 格式坐标换算与三条校验规则3.1 为什么建议统一成 YOLO 格式如果只想用 YOLO 训练理论上可以只读 txt忽略 XML。但实际拆包时你会发现标注格式转换是躲不掉的一是有些脚本、可视化工具只认 VOC二是如果后续要扩展成 yolo 实例分割还得把边界框转成多边形标签。而训练端是绝对的 YOLO 格式主导因为模型训练时读的就是 txt省去解析 XML 的开销。转换的核心是坐标映射。VOC 里的绝对像素坐标除以图片尺寸就得到归一化的 YOLO 坐标。公式很简单但坑藏在细节里XML 里的size不一定和实际图片一致。如果有人在标注后压缩了图片XML 里还留着旧尺寸换算出的框就会整体偏移。所以转换脚本里必须用 PIL 重新读一次图片真实宽高而不是信 XML 里的数字。3.2 VOC 转 YOLO写一个不会丢框的转换脚本下面这个脚本我做过很多次换成哪个数据集都能用。核心思路是遍历所有 XML解析每个 object 的类别和边界框按公式换算写入同名 txt。import os import glob import xml.etree.ElementTree as ET from PIL import Image CLASS_MAP {fire: 0, smoke: 1} # 类别名 - ID def convert_voc_to_yolo(xml_path, img_path, out_dir): img Image.open(img_path) img_w, img_h img.size tree ET.parse(xml_path) root tree.getroot() lines [] for obj in root.iter(object): name obj.find(name).text.strip() if name not in CLASS_MAP: print(f[SKIP-UNKNOWN] {xml_path} - {name}) continue bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) center_x ((xmin xmax) / 2) / img_w center_y ((ymin ymax) / 2) / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h lines.append( f{CLASS_MAP[name]} {center_x:.6f} {center_y:.6f} {width:.6f} {height:.6f} ) stem os.path.splitext(os.path.basename(xml_path))[0] out_path os.path.join(out_dir, stem .txt) with open(out_path, w) as f: f.write(\n.join(lines) \n) # 用法示例 # convert_voc_to_yolo(Annotations/299.xml, images/299.jpg, labels/)逻辑说明CLASS_MAP在代码里写死了类别映射fire 是 0smoke 是 1这必须和训练时data.yaml里的类别顺序一致。坐标换算部分用了两次除法第一次算中心点和宽高的像素值第二次除图片宽高得到归一化值。.6f保留六位小数足够表达亚像素精度也不会让文件膨胀。参数需要注意两个点。第一img_w、img_h是从 PIL 读的真实尺寸不是 XML 里的size这个细节决定转换后框准不准。第二xmin到xmax如果出现负数或者反序说明标注本身有问题最好在脚本里加个判断打印哪张图哪条框违规而不是静默写出一个负数坐标。3.3 转换后必须做的三个校验转换脚本跑完不等于数据能训练。我每次都要再跑一段校验脚本检查三点第一坐标值必须在 0 到 1 之间。YOLO 格式是归一化的如果出现大于 1 的 cx 或 w直接说明换算除错了数。第二中心点必须落在图片范围内——某种意义上这是冗余检查因为归一化后不可能超界但真出现过由脏数据导致的坐标 1.000001。第三类别 ID 不能超过总类别数减一也就是不能出现 ID 大于 1 的行。def validate_yolo_file(txt_path, num_classes2): with open(txt_path) as f: for line_idx, line in enumerate(f, 1): parts line.strip().split() cls_id int(parts[0]) vals [float(v) for v in parts[1:]] if cls_id num_classes: print(f[BAD-CLASS] {txt_path}:{line_idx}) if any(v 0 or v 1 for v in vals): print(f[OUT-OF-RANGE] {txt_path}:{line_idx})这个脚本的num_classes2对应 fire 和 smoke 两类。如果后续加类别忘记同步改这里。校验跑完没有输出才说明这批标注从数字上看是正常的。4. 用 YOLOv8 训练自己的火焰烟雾模型data.yaml、增强与关键参数4.1 写好 data.yaml路径、类别顺序、验证集划分训练前第一步是把数据描述文件写好。YOLOv8 的data.yaml直接决定训练集、验证集路径和类别列表写错一个路径训练直接报错写错类别顺序模型训练时把 0 当 fire、1 当 smoke看起来能跑实际预测全乱。path: ./fire_smoke_dataset train: images/train val: images/val nc: 2 names: 0: fire 1: smoke参数说明path是数据集根目录的绝对或相对路径train和val是相对于path的子目录。nc是类别总数必须和names里的数量一致。类别顺序尤其关键0 永远是 fire1 永远是 smoke和上一章转换脚本里的CLASS_MAP保持一致。数据集小我一般不会手动建 train/val 子目录而是用脚本按 8:2 或 9:1 比例随机划分。火焰烟雾场景里漏检代价高验证集稍微多留一点反而踏实。mkdir -p fire_smoke_dataset/images/train fire_smoke_dataset/images/val mkdir -p fire_smoke_dataset/labels/train fire_smoke_dataset/labels/val ls images/ | awk NR % 5 ! 0 | xargs -I {} mv images/{} images/train/这段命令的逻辑是先建四个目录然后用awk每隔 5 个文件名保留一个到 train其余靠mv移走。百分比可以自己调NR % 5 ! 0是每 5 个取 4 个到 train也就是 80% 训练、20% 验证。要注意的是 labels 也要做一模一样的划分否则图片在 train 里、标注在 val 里训练时一张图也加载不出来。4.2 训练参数小数据集原本就过拟合先看这几项近五百张图放在目标检测里属于小样本训练参数和那些几万张的数据集完全不同。我习惯用 YOLOv8 的 n 模型起步把显存留给更大的输入尺寸。yolo train \ datafire_smoke.yaml \ modelyolov8n.pt \ epochs200 \ imgsz1024 \ batch16 \ patience50 \ augmentTrue \ mosaic0.5 \ degrees5 \ hsv_h0.02参数说明epochs200对于小数据集来说不多因为模型要反复看这些图到熟imgsz1024是这一串参数里最关键的一个——火焰往往是画面里的小目标输入太小会直接抹掉小火焰的细节mosaic0.5让模型每轮有一半概率看到马赛克拼接图能显著缓解小样本的过拟合degrees5允许图片旋转正负 5 度模拟摄像头安装角度偏差hsv_h0.02是色调扰动。这些增强参数在火焰烟雾场景里要讲究。烟雾的颜色从白到灰到黑都有hsv_h稍微加大一点模型更容易学到“颜色变化但形状不变”的烟雾本质。而degrees不能给太大火灾检测场景里倒置或横滚的图片不符合实际监控视角转多了反而制造无效样本。4.3 用迁移学习但要把预训练类别“忘记”到合理程度数据量小从头训练几乎必挂所以要用预训练权重yolov8n.pt做初始化。这一步是在 COCO 上预训练过的模型基础上微调模型已经会提取通用特征火焰的边缘、烟雾的纹理这些低层信息可以复用只需要在高层学习“什么是火、什么是烟”。参数上唯一推荐动的是检测头的学习率。YOLOv8 里可以通过lr0和lrf控制初始学习率和最终学习率小数据集我一般把lr0降到 0.005 左右微调时步子小一点避免把预训练权重冲坏。如果你的 NVIDIA 显卡小于 8GBbatch降到 8imgsz降到 640否则还没跑到第一个 epoch 就 OOM 了。4.4 评估指标火焰烟雾更要盯召回率训练完看验证结果mAP50、mAP50-95、precision、recall 四个值要一起看。其中最重要的其实是召回率。火焰检测漏报的代价远远大于误报——漏掉一个真实火源可能酿成大祸而误报最多就是触发一次假警报。YOLOv8 的验证输出默认会打印每个类别的 AP这时候重点看 smoke 的 AP。烟雾的标注天然比火焰困难因为它边界模糊、半透明同一张图不同标注员画出的框差距很大。如果 smoke 的 AP 明显低于 fire别急着调网络结构先回去看烟雾的标注框是不是偏大或者漏标。模型预测时还可以用conf参数调报警灵敏度。默认阈值 0.25如果希望在监控场景里少漏报降到 0.1如果误报太多提到 0.4。这个数字直接影响误报率和召回率后面接预警系统时就是靠它来平衡。yolo predict modelruns/detect/train/weights/best.pt \ sourcetest_video.mp4 \ conf0.15 \ imgsz1024conf0.15的意思是置信度低于 0.15 的框直接丢弃。这个值越小越敏感但也会带来更多误检实际部署时最好拉出一段真实监控视频跑一遍后数一下误报数量再调。5. 火焰烟雾数据集避坑清单五类翻车现场与处理办法5.1 损失函数降了但精度上不去现象训练时 loss 一路下降降到 0.4 以下打开验证集图片一看框的位置基本对但 mAP50 只有二十几。原因数据集小模型在训练集上“背答案”了。火焰和烟雾样本数少模型记住的是这几百张图里的固定背景和光照条件换一张没见过的监控画面就歇菜。迁移学习也只能缓解不能根治。解决先从数据层面补做更强的增广尤其是 mosaic 和 copy-paste再从模型层面补换更小的模型容量比如从 s 降到 n抑制过拟合。最后实在不行就人工补拍或者从公开视频里截帧凑到千张级别效果会有明显提升。5.2 VOC 转 YOLO 后批量框偏移现象转换完的 txt 里火焰的框全部偏到右下方或者宽高明显比实际大一圈。用可视化脚本把 YOLO 框画回图片每个框都飘。原因XML 里的size和实际图片分辨率不一致。最常见是标注后在修图软件里缩放过图片XML 没跟着更新转换脚本却用 XML 里的旧尺寸做除法导致归一化坐标集体偏移。解决回到转换脚本用 PIL 重新读图片真实宽高完全忽略size节点的值。这个改动就两行代码却能救回整批标注。从那以后我所有转换脚本都默认先Image.open再取img.size绝不信任 XML 里写死的尺寸。5.3 把路边红尾灯认成火把白墙认成烟现象训练完成后跑测试视频晴天傍晚的路口尾灯和落日被大量标成 fire白色雾气、蒸汽、水面反光也被标成 smoke。原因火焰和烟雾的外观本质上是“颜色 纹理 运动”的组合但静态图片模型只能看到颜色和纹理。红色圆形物体像火焰白色半透明的东西像烟雾这种混淆在小数据集下尤其严重因为见过的反例太少。解决最有效的是收集负样本。从监控视频里截取“像但又不是”的帧比如红色车尾灯、晚霞、排气蒸汽标注成背景类加入训练集重训。另一个思路是后续接视频流时用帧间差异做二次确认真实火焰有闪烁和飘动特征静态的红色尾灯没有。5.4 增强参数拉满显存当场爆炸现象训练时把mosaic1.0、degrees30、hsv_h0.5全开又把imgsz设到 1280启动三秒后 CUDA out of memory。原因增强和输入尺寸都在烧显存。mosaic会把四张图拼在一起送进网络输入分辨率加倍显存占用直接翻倍imgsz1280在小显存卡上本来就很极限。解决8GB 显存老老实实imgsz1024、mosaic0.5、batch8。火焰是小目标但 1024 已经能保留足够细节没必要硬上 1280。如果一定要高分辨率训练先看nvidia-smi确认剩余显存再决定参数。5.5 patience 太小模型还没学会就早停了现象训练到第 30 轮验证集 mAP 还在爬升但训练直接停止因为连续 20 轮没有明显改善patience 触发。原因火焰烟雾的难点分布不均匀。有些类别前 10 轮就学得差不多有些难样本要到 80 轮以后才逐渐学会。小数据集训练波动本来就大早停条件太苛刻会在模型还没到最佳点的时候掐断。解决小数据集patience设到 80 甚至 100让它“多熬一会儿”。或者干脆设 200用 epoch 数控制训练时长反正小数据集一个 epoch 就几十秒多跑几十轮代价很小。6. 把模型接进视频预警跳帧检测、阈值与防误报技巧6.1 跳帧检测与置信度阈值模型训练完最终要落到视频流里才能预警。监控摄像头常见 25 帧每秒逐个帧全量推理对 GPU 是浪费因为火焰和烟雾都是慢变化目标写个跳帧检测既能降低延迟又不会漏掉主要事件。import cv2 from ultralytics import YOLO model YOLO(best.pt) cap cv2.VideoCapture(camera_01.mp4) frame_id 0 consecutive_hits 0 ALERT_CONF 0.4 while cap.isOpened(): ret, frame cap.read() if not ret: break if frame_id % 3 ! 0: frame_id 1 continue results model(frame, conf0.15, imgsz1024, verboseFalse) fire_detected any( r.boxes.cls 0 and r.boxes.conf ALERT_CONF for r in results ) if fire_detected: consecutive_hits 1 else: consecutive_hits 0 if consecutive_hits 2: print(f[ALERT] 第 {frame_id} 帧连续检测到火焰) consecutive_hits 0 frame_id 1逻辑说明frame_id % 3 ! 0表示每 3 帧取 1 帧做推理25 帧的摄像头相当于每秒检测 8 次对火灾这种演变缓慢的目标完全够用。ALERT_CONF 0.4是报警阈值低于它只记录不报警减少误报。consecutive_hits 2要求连续两次检测到火焰才报警这是最有效的防误报手段——单帧的偶发误检被直接过滤掉。参数要按场景调摄像头离监控区域远火焰在画面里变成小目标imgsz保持 1024ALERT_CONF可以降到 0.3如果场景里红色物体多比如厂房里的红色设备多ALERT_CONF就得升高同时依赖连续帧确认来压误报。6.2 夜间与逆光场景的验证习惯火焰烟雾模型最怕的是场景光照分布变化。同一个模型白天 mAP 六十多晚上因为光线弱、颜色失真直接掉到三十。这个数据集里的图片偏白天场景部署到夜间场景前必须单独验证。我的习惯是训练完不直接收工而是拿一段夜间视频和一个黄昏视频跑一遍predict看看烟雾在暗背景下能不能分出来。如果夜间漏检严重优先调hsv_h和hsv_s增强模拟不同色温和饱和度重训。从那以后我每次训练完都强制走一遍“白天、黄昏、夜间”三段验证不是等部署到现场才发现模型在晚上是半瞎的。地铁站、仓库、隧道这些光照复杂的场景尤其要跑这一步希望这次的坑记录能帮你少走两趟弯路。本文还有配套的精品资源点击获取
