简介这是一份面向YOLO学习者和安防、火灾预警开发者的火焰目标检测资源包包含完整的数据集与预训练模型用于解决火焰检测场景中数据收集和标注成本高的问题。压缩包内共1559个文件519张火焰图片均配有txt和xml两种标注格式记录边界框坐标、类别标签及结构化对象信息可直接用于YOLO系列训练另有h5和tflite格式的预训练模型便于快速验证或部署至移动端。压缩包约57.26MB已有2520人浏览学习。借助这份资源目标检测初学者可省去自行采集和标注火焰图像的工作对照标注文件理解YOLO标签规范完整走通“数据准备—模型训练—效果验证”流程进阶开发者可在预训练权重基础上做迁移学习或按场景微调并尝试将模型部署到嵌入式设备或云端构建实时火焰检测与报警应用。1. 火焰检测为什么不像普通目标检测数据才是第一个坑第一次拿YOLO跑火焰目标检测我以为难点在模型选型看完测试结果才意识到火焰检测真正的门槛不在模型在数据。火焰没有固定形状颜色从橙红到蓝白跨度极大半透明的特性让边界框天然带噪声这跟检测猫狗车完全是两回事。这份YOLO火焰目标检测数据集加测试模型的资源解决的就是这个起点问题数据集已经整理成YOLO标准格式标注齐全自带可以直接做推理验证的测试模型。你不需要自己爬图、清洗、标注拿到手就能在火焰检测这条线上快速跑通训练、验证和部署。适合两类人正在做火灾报警、工业安全监测的开发者以及想在目标检测上拿一个非普通类别练手的同学。2. 火焰数据集构成与YOLO标注坐标、边界与划分先说结论这份数据集按YOLO系列通用的目录结构和标签格式组织不做转换、不写脚本就能直接喂给YOLOv5、YOLOv8或者更新的YOLO系列训练。下面把目录、标签、边界框规范拆开讲清楚。2.1 目录结构与标签文件解析拿到数据集后先不要急着训练把目录结构整体看一遍。dataset/ ├── images/ │ ├── train/ # 训练集原图JPG │ ├── val/ # 验证集原图JPG │ └── test/ # 测试集原图JPG ├── labels/ │ ├── train/ # 训练集标签TXT │ ├── val/ # 验证集标签TXT │ └── test/ # 测试集标签TXT ├── fire.yaml # YOLOv8 数据配置 └── categories.txt # 类别清单第一行是 fireimages目录下每一张图片在labels目录里都有一个同名的TXT文件作为标签。文件结构是YOLO系列通用的后面换任何YOLO版本目录都不用动。标签文件不是XML也不是JSON是纯文本每行五个数字对应一个火焰目标框。可以用下面的脚本把标签读出成可读信息from pathlib import Path label_path Path(dataset/labels/train/fire_0001.txt) for line in label_path.read_text().strip().splitlines(): parts line.split() cls_id int(parts[0]) x_center, y_center, w, h [float(p) for p in parts[1:]] print(f类别ID: {cls_id} | 中心X: {x_center:.4f} | 中心Y: {y_center:.4f} | 宽: {w:.4f} | 高: {h:.4f})这段代码把每条标注解析成可读信息。注意cls_id从0开始这份数据集只有fire一个类别所以cls_id恒为0。x_center、y_center、w、h四个值全部是相对图片宽度和高度的归一化比例取值范围在0到1之间。x_center0.5表示火焰中心位于图片水平正中w0.1表示火焰宽度占图片总宽度的10%。训练前把数据集里所有标签扫描一遍如果出现绝对值大于1或者为负的数说明标注有问题需要修正否则会在训练中报坐标越界错误。2.2 标注边界半透明、反光与远处小火苗火焰目标框不像行人、车辆那样边界清晰标注时有三类边界情况最影响最终模型效果。第一是半透明特性火焰外焰很淡标注框要不要包进去我一般建议宁小勿大只框住核心燃烧区域把淡色外焰留给模型自己去学习特征而不是用边界框硬切。第二是火光反射水泥地、墙面上会出现橙红色反光容易被标注成火焰。如果训练标签里混入了反光框模型学到的是颜色而不是火焰形态测试时会把落日、灯光全检出来。第三是远处小火苗在640分辨率下可能只有十几个像素标注时不能因为看不清就跳过这类小目标样本决定了模型在真实场景下的远距离检测能力。场景标注建议原因半透明外焰只框核心燃烧区宁小勿大边界框太大会引入大量背景特征地面反光不标注作为负样本反光是映射不是火源框进去会教坏模型远处小火苗即使很小也要标注小目标样本稀缺漏掉会导致远距离漏检多个火源每个火源单独一个框多个火源合框会让模型学习检测大区域而非火焰本身这四条是经验总结不是官方规范。实际标注时如果发现某类误报反复出现回头查标注大概率是这几类问题。数据质量决定模型上限YOLO本身不能替你解决标签噪声。2.3 数据划分与泄露检查数据集已经按8:1:1左右的比例划分好了train、val、test。这个比例对火焰这种单一类别、场景相对集中的数据集够用。建议做一次泄露检查如果数据里有从视频抽帧得到的图片连续帧不能同时出现在train和val中否则验证集指标会虚高训练出来的模型一到真实场景就露馅。from pathlib import Path import re def extract_video_id(filename): # 假设文件名形如 video01_frame0032.jpg match re.match(r(video\d)_frame, filename) return match.group(1) if match else filename for split in [train, val, test]: img_dir Path(dataset/images) / split video_ids {extract_video_id(p.stem) for p in img_dir.glob(*.jpg)} print(split, 视频来源数:, len(video_ids))把三个split的视频来源ID集合做交集如果存在重复就把重复来源的视频帧整体挪到train侧。火焰场景的视频连续性很强相邻帧内容几乎相同这一步不做后面所有指标都会失真这也是很多人在火焰检测复现时发现模型“训练很好、部署翻车”的常见原因。3. YOLOv8训练火焰模型从配置到权重数据集准备好之后下一步是把它跑成可用的检测权重。这里用YOLOv8作为基准操作因为这个版本的ultralytics命令生态最完整文档和社区案例也最多。如果你用的是YOLOv5或YOLOv9核心逻辑一样只是命令行参数略有差异。3.1 环境准备与数据集配置训练前先确认环境依赖pip install ultralytics torch torchvisionultralytics版本建议在8.1以上YOLO系列迭代比较频繁版本太老会出现配置项不识别的问题。能上GPU就上GPU火焰检测模型不算大一张8G显存的GPU就可以起步。如果只有CPU训练时间会拉长数倍建议先缩小imgsz到416做一轮快速验证再决定要不要扩大。然后检查fire.yamlpath: /absolute/path/to/dataset train: images/train val: images/val test: images/test names: 0: firepath推荐写绝对路径避免换目录后训练时报找不到图片的错误。train、val、test写相对路径相对于path定义的位置。names只有一类fire对应ID 0与标签文件保持一致。保存配置后先跑一个快速的合法性检查yolo detect train datafire.yaml modelyolov8n.yaml epochs1 batch8 imgsz640epochs1的意义是走一个batch验证配置和目录不长时间训练。常见做法是先用这个命令确认没错再进入正式训练。这个步骤能过滤掉大部分路径、yaml格式、标签缺失问题省下半天排错时间。3.2 训练参数epochs、batch与优化器正式训练按下面的命令启动yolo detect train \ data/absolute/path/to/fire.yaml \ modelyolov8n.pt \ epochs100 \ batch16 \ imgsz640 \ lr00.01 \ patience20 \ device0这里不用yolov8n.yaml而用yolov8n.pt区别在于后者是COCO预训练权重相当于模型已经学会了通用视觉特征再在火焰数据上微调收敛速度和最终精度都明显更好。火焰检测属于单一目标类别任务从零训练完全没必要除非你想折腾YOLO的训练逻辑。参数取值作用modelyolov8n.pt预训练模型nano体积小单类检测够用epochs100完整迭代轮数单类任务100轮足够batch16批量大小显存不够时降到8imgsz640输入分辨率越高小目标越友好但显存压力大lr00.01初始学习率数据量小时降低到0.005patience20连续20轮指标不提升就早停如果习惯在代码里手动控制训练等价写法from ultralytics import YOLO model YOLO(yolov8n.pt) model.train( data/absolute/path/to/fire.yaml, epochs100, batch16, imgsz640, lr00.01, patience20, device0, projectruns/fire_detect, nameexp1 )project和name决定训练产物输出位置多次试验时建议每次换name不要全部堆在默认目录里。batch的调整规则很简单训练报CUDA out of memory先减半。batch太小小于8的话BN层统计不稳定loss曲线会抖动这个在火焰训练里尤其明显因为火焰样本颜色对比度高batch波动会被放大。YOLO的损失函数由box_loss、cls_loss和dfl_loss三部分组成训练日志里会分别显示。火焰检测只需要关注cls_loss走势如果cls_loss持续下降而box_loss在后期震荡大概率是边界框标注不一致导致的——就是第2章讲的半透明外焰问题框得太随意模型怎么拟合都拟合不准。3.3 训练产物与结果解读训练完成后产物在runs/fire_detect/exp1/下。先看两个东西ls runs/fire_detect/exp1/ cat runs/fire_detect/exp1/results.csv | head -5results.csv每一行是epoch维度的指标汇总。重点关注这几列列名含义火焰检测里怎么看metrics/mAP50(B)IoU0.5时的平均精度主要指标火焰检测看这个metrics/mAP50-95(B)多IoU阈值平均精度会低于mAP50火焰边界模糊导致metrics/precision(B)精确率误检多时看它metrics/recall(B)召回率漏检多时看它火焰检测场景下mAP50和mAP50-95的差距会比一般物体大。原因是火焰边界天然不确定同一个火焰目标标注框和预测框在IoU0.75时很难完全对齐这是数据本身的特性不是模型出问题了。我在实际项目里一般要求mAP50达到0.85以上才考虑部署mAP50-95能到0.6就已经很不错。混淆矩阵图confusion_matrix.png也要看重点看假阳性和假阴性的分布。火焰目标被漏检成background说明小目标或低对比度样本不足background被误检成fire说明背景里橙红色干扰物没有加入负样本。这两个方向对应完全不同的补数据策略一个是补充真实火焰样本一个是补充无火焰的干扰场景。4. 测试模型图片、视频与摄像头检测训练出来的best.pt只是中间产物最终要拿到真实场景下验证它能不能用。这个章节讲清楚怎么用测试模型做单张图、视频和摄像头推理以及导出成部署格式的边界条件。4.1 单张图片推理用训练好的best.pt对测试集或任意图片做检测from ultralytics import YOLO model YOLO(runs/fire_detect/exp1/weights/best.pt) results model.predict( sourcetest_images/factory_fire.jpg, conf0.25, iou0.45, saveTrue, save_txtTrue ) for r in results: boxes r.boxes print(f检测到 {len(boxes)} 个火焰区域) for box in boxes: cls int(box.cls[0]) conf float(box.conf[0]) x1, y1, x2, y2 box.xyxy[0].tolist() print(f类别{cls} 置信度{conf:.2f} 坐标({x1:.0f},{y1:.0f},{x2:.0f},{y2:.0f}))conf是置信度阈值低于这个值的检测框被丢弃。iou是NMS的IoU阈值当两个检测框重叠超过这个比例时保留置信度更高的那个。这两个参数在火焰检测里需要根据场景调整后面第6章会专门讲。saveTrue把标注图存下来save_txtTrue把检测结果存成与标签同样格式的TXT方便直接评测或与GT对比。单张图片推理是最基本的验证方式。建议先用测试集里的图片跑一遍确认训练没有过拟合到训练集再拿几张完全没见过的真实场景图看泛化效果。我见过不少训练指标很好、一到实际摄像头画面就大量误检的模型问题都出在这一步跳过了。4.2 视频与摄像头实时检测视频文件推理yolo detect predict \ modelruns/fire_detect/exp1/weights/best.pt \ sourcewarehouse_camera.mp4 \ conf0.3 \ saveTrue \ device0摄像头直播流yolo detect predict \ modelruns/fire_detect/exp1/weights/best.pt \ source0 \ conf0.3 \ showTrue \ device0source0表示本机第一个摄像头换成rtsp://地址也能直接跑。showTrue会弹出一个实时显示窗口。视频检测速度取决于显卡算力和输入分辨率我一般用yolov8n在单张消费级GPU上处理640分辨率视频可以跑到实时。如果只有CPU帧率会掉到个位数这种场景就需要先下采样视频再检测或者干脆导出成TensorRT模型。注意火焰视频检测和普通视频检测不同火焰可能出现在画面任意位置且面积变化剧烈如果视频分辨率很高直接缩到640会丢失小火苗建议保留原分辨率做分块或滑窗。4.3 模型导出ONNX与TensorRT如果要把模型部署到实际监控系统不能只靠ultralytics的predict脚本导出成通用格式更合适yolo export modelruns/fire_detect/exp1/weights/best.pt formatonnx imgsz640 yolo export modelruns/fire_detect/exp1/weights/best.pt formatengine device0ONNX是跨平台通用格式可以转成OpenVINO或TNN运行在边缘设备上。engine是TensorRT专用格式只能在NVIDIA GPU上运行但推理速度比PyTorch原生快一个量级。导出engine前必须先导出ONNXTensorRT是在ONNX基础上做图优化。格式适用场景推理速度PyTorch (best.pt)实验验证、二次开发基准ONNXCPU部署、跨平台比PyTorch快TensorRT engineNVIDIA GPU部署明显快于ONNX导出后用ONNX Runtime验证一下输出确认模型结构转换没问题再进部署流程。这里有个小坑导出engine时imgsz必须和推理时保持一致否则TensorRT会重新做一次隐式转换性能反而下降。我一般先确定部署分辨率再按这个分辨率导出不搞两套尺寸。5. 火焰检测的避坑指南五条踩坑记录把实际跑火焰检测中高频出现的问题记录下来按现象、原因、解决的顺序写。复现时遇到了可以直接照方抓药不用再花一晚上排查。5.1 夕阳和灯光被当成火焰现象模型在傍晚场景下把夕阳、橙红色路灯全部框出来误报率飙升。原因训练样本里橙红色自然光源太少模型学的其实是颜色和亮度的组合而不是火焰的形态和动态特征。火焰检测的模型对颜色非常敏感这是优势也是隐患。解决在训练集中加入大量负样本包括夕阳、黄昏天空、橙红色路灯、工地照明灯。负样本图片不需要任何标注框直接放在images目录里对应的标签文件为空让模型学会在这些场景下输出“无目标”。5.2 标签坐标越界引发训练NaN现象训练到某个epoch后loss突然变成NaN后续指标全乱。原因标注文件中某个框的坐标超出0到1范围或者框的中心点靠近图片边缘导致w/2越界。这种情况在手工标注火焰时很常见因为半透明火焰的边缘很难精确定位。解决训练前用脚本扫描所有标签文件对坐标做边界截断。import numpy as np from pathlib import Path def fix_label_file(txt_path, img_w640, img_h640): lines [] for line in txt_path.read_text().strip().splitlines(): parts line.split() cls parts[0] xc, yc, w, h map(float, parts[1:]) # 把归一化坐标换算回像素坐标做边界截断 x1 np.clip((xc - w / 2) * img_w, 0, img_w) y1 np.clip((yc - h / 2) * img_h, 0, img_h) x2 np.clip((xc w / 2) * img_w, 0, img_w) y2 np.clip((yc h / 2) * img_h, 0, img_h) # 截断后再换算回归一化坐标写回文件 new_w (x2 - x1) / img_w new_h (y2 - y1) / img_h new_xc (x1 x2) / 2 / img_w new_yc (y1 y2) / 2 / img_h lines.append(f{cls} {new_xc:.6f} {new_yc:.6f} {new_w:.6f} {new_h:.6f}) txt_path.write_text(\n.join(lines)) # 扫描训练集标签目录逐个修正越界坐标 for txt in Path(dataset/labels/train).glob(*.txt): fix_label_file(txt)注意如果训练时用的不是640分辨率脚本里img_w和img_h要改成对应值。另一种做法是直接删掉越界的整行标注但我不推荐删尤其小目标样本本来就稀缺删一条就少一条。5.3 视频抽帧造成数据泄露现象验证集mAP50比预想高很多但一到真实场景就掉链子检测效果差一大截。原因数据集从视频抽帧时相邻帧被分到train和val两侧验证集里出现了大量训练时见过几乎一模一样的内容。火焰视频的帧间变化很小抽帧间隔不够大时泄露会非常严重。解决划分数据集时以视频为单位不能以帧为单位。先按视频ID整体分割再在各自的集合里抽帧。具体做法就是第2.3节那段代码把重复的视频来源ID挑出来整体挪到train侧。5.4 远处小火苗永远检不到现象近距离和中等距离火源检测正常十米开外的小火苗直接漏检完全没有响应。原因目标在640分辨率下按比例缩小到十几个像素经过数次下采样后特征基本消失。火焰检测的特征是小区域高亮加形态不规则小目标在经过深层网络后语义信息保留不住。解决提高输入分辨率到960或1280或者对视频做分块检测。我一般会在部署时用imgsz960跑一遍如果显存不够就在推理前把视频按网格切块每块独立检测再把结果坐标映射回原图。切块时注意相邻块要有重叠否则火焰正好落在边界上时会被切成两半两边都检不出来。5.5 白天低对比度火焰漏检现象白天强光下的火焰漏检尤其是蓝色火焰或燃气火焰模型几乎没有反应。原因白天的环境光把火焰颜色和纹理压掉了模型学到的特征对低对比度目标不敏感。火焰检测样本里如果夜间和室内场景居多白天场景就会成为模型的盲区。解决在训练集里补充白天火焰样本尤其是蓝色焰和燃气焰。也可以用数据增强手段对训练图片随机降低对比度、增加亮度扰动让模型对光照变化更鲁棒。火焰检测在燃气管道、化工场景里经常是蓝色火焰白天空背景下几乎和背景融为一体单一RGB数据集很难完全解决条件允许时配合热成像做多模态输入才是根本方案但那是另一个话题了。6. 把误检压下去阈值扫描与框重叠处理在实际部署中默认conf0.25对于火焰检测往往偏松。火焰检测的误检和漏检代价不对称在火灾报警场景里一次误报会消耗消防资源甚至导致报警系统被人工关闭后果很严重。所以我有一个固定的动作每次部署新场景前先用验证集做一遍阈值扫描把精确率和召回率的平衡点找出来。from ultralytics import YOLO model YOLO(runs/fire_detect/exp1/weights/best.pt) for conf in [0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5]: metrics model.val( data/absolute/path/to/fire.yaml, confconf, iou0.45 ) print(fconf{conf} 精确率{metrics.box.mp:.4f} 召回率{metrics.box.mr:.4f} mAP50{metrics.box.map50:.4f})这段代码会输出一系列阈值下的精确率和召回率。火灾报警场景我会选精确率开始下降的前一个阈值宁可漏检也不误报如果是安全巡检则反过来选召回率高的阈值。NMS的iou参数同样值得调。火焰检测里多个火源可能靠得很近比如厂房里一排机器同时起火默认iou0.45容易把相邻的火焰框合并成一个大框。把iou调到0.6或0.7能保留更多的独立火源框。注意这里调的是NMS合并阈值不是mAP计算里的IoU两者概念不同别混淆。我做火焰检测第一次上线时直接沿用默认conf0.25结果摄像头对着橙色厂房墙面误报了一整晚。从那以后每换一个部署场景我都会先把验证集跑一遍阈值扫描把精确率和召回率的拐点找出来再写进推理脚本这个动作已经变成我的固定流程希望帮到你。本文还有配套的精品资源点击获取