简介火焰烟雾检测数据集YOLO.zip面向深度学习目标检测开发者尤其适合使用YOLO框架进行火焰烟雾识别与工程化落地的用户。图片清晰、场景覆盖广泛所有数据均经人工精心挑选与标注可直接作为通用模板训练火焰烟雾检测模型若需适配特定环境仅需补充少量场景数据即可完成迁移免去收集、清洗、标注的重复劳动。压缩包共332个文件以77个目标文件、70个C源文件、61个头文件为主辅以Python脚本、YAML配置、示例视频和模型权重整体约32.18MB代码覆盖数据加载、模型定义、训练推理等完整链路便于按需调取。目前已吸引2018人学习下载。借助该资源开发者可快速搭建火焰烟雾检测训练流程并将精力集中在模型调优与工程部署上对研究者和团队而言既能直接用于模型验证也可参考底层代码深入理解YOLO实现细节适合高效落地火焰烟雾检测应用的项目场景。1. 火焰烟雾数据集YOLO.zip 是什么先搞清三个关键点再动手火焰烟雾数据集YOLO.zip是很多做消防告警、森林防火、智慧工地的人拿到的第一份训练数据。解压后你通常会看到一批已经标好框的火焰烟雾图片以及和图片同名的.txt标签文件标签里每一行代表一个目标格式为“类别编号 中心点x 中心点y 框宽 框高”所有坐标都归一化到 0~1。这份数据解决的最大问题是省掉了从零采集图像、手工标注的几周工作量让你可以直接进入 YOLOv8 或 YOLOv5 的训练流程。它比较适合刚接触 YOLO 的算法工程师、做烟火识别场景的安防开发以及拿目标检测做毕业设计的同学。但我劝你先别急着解压训练先按下面几个步骤把数据和环境做一遍体检否则后面翻车时很难定位问题。2. 解压后第一件事把目录、标签和图片做一次体检很多人拿到“火焰烟雾数据集YOLO.zip”后第一反应是解压然后直接填data.yaml开训结果要么 loss 变成 nan要么训练完类别全乱。这里面的坑大多不在训练环节而在数据集本身。所以解压后的第一件事不是训练是体检。2.1 目录结构train、val、labels 的对齐关系一份规范的 YOLO 火焰烟雾数据集解压后目录结构一般是这样的fire_smoke/ ├── train/ │ ├── images/ │ │ ├── fire_001.jpg │ │ └── smoke_002.jpg │ └── labels/ │ ├── fire_001.txt │ └── smoke_002.txt ├── val/ │ ├── images/ │ └── labels/ └── data.yamltrain/images放训练图片train/labels放同名 txt 标签val目录同理。.txt文件名必须和对应的图片文件名完全一致包括扩展名前缀比如fire_001.jpg对fire_001.txt。如果出现一张图片没有同名标签YOLO 训练时会在加载阶段报“label not found”或者默认把它当成纯背景图处理这部分图多了就会让模型学到奇怪的背景特征。不过实际从网上下到的 zip 并不都这么规范。我见过标签目录叫annotations/train、图片目录叫images/train2017的也见过所有图片和标签混在同一个目录里用jpg和txt扩展名区分的。遇到这种结构我一般会先写两行 Python 统计一遍图片和标签的数量再决定要不要重新整理目录。原始目录不调整的话后面写data.yaml很容易出错。另外如果 zip 里自带classes.txt一定要打开看因为类别编号是从 0 开始按classes.txt顺序分配。常见错误是标注文件里类别编号用的是 1、2但data.yaml里从 0 开始造成火焰和烟雾互相标反。体检阶段把类别编号统计出来能省掉后面一次无效训练。2.2 用一段 Python 完成标签体检类别、坐标和空文件不管目录结构规不规范我拿到数据后都会先跑一遍标签体检脚本。下面这段代码会统计每个类别编号出现次数、找出空标签文件和格式异常的行是排查类别错位和空标签问题最快的手段import os from collections import Counter labels_dir fire_smoke/train/labels class_counter Counter() empty_files [] bad_lines [] for name in os.listdir(labels_dir): if not name.endswith(.txt): continue path os.path.join(labels_dir, name) with open(path, r, encodingutf-8, errorsignore) as f: lines f.readlines() if len(lines) 0: empty_files.append(name) continue for line in lines: parts line.strip().split() if len(parts) ! 5: bad_lines.append((name, line.strip())) continue cls, cx, cy, w, h parts try: cx, cy, w, h float(cx), float(cy), float(w), float(h) except ValueError: bad_lines.append((name, line.strip())) continue if not (0 cx 1 and 0 cy 1 and 0 w 1 and 0 h 1): bad_lines.append((name, line.strip())) continue class_counter[int(cls)] 1 print(类别出现次数:, class_counter) print(空标签文件:, len(empty_files), empty_files[:10]) print(格式异常行:, len(bad_lines), bad_lines[:10])这段脚本的逻辑分四步先把所有.txt文件读进来检查是否为纯空文件再把每一行按空格切分成 5 个字段字段数量不对的直接记为异常接着把坐标转成浮点数并验证边界框的中心点坐标在 0~1 之间、宽高大于 0 且不超过 1最后按类别编号计数。class_counter的输出如果出现{0: ..., 1: ..., 5: ...}这种跳跃编号就说明原始数据集不是从 0 开始连续编号或者已经按多个批次合并过必须做一次重映射。纯背景图在目标检测数据集里大量存在但如果一个 zip 里空标签文件超过 1%训练时 loss 会明显波动。另外有一个容易被忽略的情况某些标注工具导出的 txt 里会多一个difficult属性导致每行变成 6 个字段这种也会被标记为格式异常。解决方法是把parts[0:5]前 5 个字段截出来不要直接删文件。2.3 图片损坏与方向问题PIL 批量验证标签没问题不代表图片没问题。从网上下载的数据集尤其是视频抽帧出来的经常混着截断的 JPEG、莫名其妙的纯色块甚至只有几 KB 的损坏文件。YOLO 训练时碰到损坏图片轻则加载失败重则进程直接中止。我会用 PIL 批量验证图片可读性from PIL import Image import os img_dir fire_smoke/train/images broken [] for name in os.listdir(img_dir): if not name.lower().endswith((.jpg, .jpeg, .png)): continue path os.path.join(img_dir, name) try: with Image.open(path) as im: im.verify() except Exception as e: broken.append((name, str(e))) print(损坏图片数量:, len(broken)) for item in broken[:10]: print(item)verify()不会把整张图片解码进内存而是校验文件头、数据块是否完整所以执行速度快能筛掉大部分传输过程中截断的图片。注意verify()之后这张图片对象不能再用了需要重新Image.open()因此在这个脚本里我直接进入下一次循环。还有一类问题是手机或某些相机拍摄的照片带有 EXIF 方向信息图片实际内容方向和文件名里看到的旋转方向不一致。YOLO 训练时会按像素矩阵读图如果 label 是按正常方向标注的而训练代码读到了旋转后的图像边界框位置就会错位。最稳妥的处理方式是用 PIL 打开图片后根据exif_transpose方法把图片转正再统一另存为 RGB 格式。这也顺便解决了 PNG 带透明通道、BMP 格式不统一带来的很多小毛病。3. 用 PyCharm 搭 YOLO 环境并跑通训练YOLOv8 最小可复现流程数据集体检完就可以进入训练阶段。这里我用 YOLOv8 作为示例因为它的ultralytics包把数据校验、训练、验证、导出封装得比较完善对火焰烟雾这类标注质量参差不齐的数据集容错性比 YOLOv5 更好一些。3.1 用 PyCharm 安装并使用 YOLO虚拟环境与 ultralytics在 PyCharm 里安装并使用 YOLO 是最省事的方式。新建项目时把 Python 解释器选为 3.10 或 3.11然后创建虚拟环境。Windows 上我习惯在项目根目录打开 Terminal执行下面几条命令# 如果你的机器是 NVIDIA GPU先安装 CUDA 版 PyTorch pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 再安装 ultralytics它会自动补齐 opencv-python、pandas 等依赖 pip install ultralytics装完以后可以跑一条 Python 命令验证环境和权重文件是否正常from ultralytics import YOLO model YOLO(yolov8n.pt) print(model)如果执行没有报错说明 PyCharm 已经正确绑定了虚拟环境里的 Python 解释器而且yolov8n.pt这个预训练权重可以被正常加载。yolov8n.pt是最小的轻量模型只用来验证环境真正训练火焰烟雾时我会换成yolov8s.pt或yolov8m.pt因为 V8n 的特征提取能力对烟雾这种边缘模糊的目标偏弱。这里要特别提醒PyCharm 里如果直接用当前项目解释器跑训练内存里的数据和训练日志可能会把项目目录撑大好几 GB。我会在项目外单独建一个runs目录存放训练输出或者用projectruns/xxx参数把输出重定向出去。另外 Windows 下训练时如果报了和spawn相关的多进程错误多半是workers参数和 PyCharm 的调试模式冲突解决办法是调试时把workers设为 0正式训练时再设为 4 或 8。3.2 写 data.yaml 的四个关键字段path、train、val、names环境就绪后第一步不是直接跑训练命令而是写data.yaml。这个文件写错一个字段后面训练白跑。最基本的火焰烟雾配置如下path: D:/datasets/fire_smoke train: train/images val: val/images # test: test/images names: 0: fire 1: smokepath是数据集根目录我建议写绝对路径。train和val是相对于path的图片目录路径注意只写到images这一层不要写成train/images/也不要写上具体图片文件。names是类别名编号从 0 开始连续递增。这里最容易犯的一个错误是从网上复制别人的 data.yaml结果path指向的是别人电脑上的路径或者names里多了几个没用的类别火焰烟雾实际用的编号是 3 和 4训练出来自然乱套。还有一个细节如果 zip 解压出来的目录里train/images和train/labels不在一层比如图片在images/train标签在labels/train就需要把目录调整为 YOLO 预期的镜像结构或者在data.yaml里用train: images/train并配合path指定到包含两个子目录的上一级。我一般会重构目录而不是改配置因为后续用val.py做验证时YOLO 会自动去同名 labels 目录找标签目录不规整会派生出一堆额外问题。3.3 第一条训练命令imgsz、batch、epochs 怎么设data.yaml 写完训练命令可以这样写yolo detect train \ datafire_smoke.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ patience20 \ projectruns/fire_smoke \ nameexp1 \ device0先从imgsz说起。火焰烟雾数据里既有占画面很大一块的明火又有远处冒出来的一小团烟。imgsz640是速度和精度的平衡点显存 8G 的卡跑yolov8s基本够用。如果烟雾目标普遍很小我会把imgsz提到 960 或 1280但 batch 要相应减半否则 8G 显存直接溢出。batch16在数据量 2000 张上下时是比较稳的选择。batch 太小比如 4训练后期 loss 抖动大模型不容易收敛batch 太大比如 64BLAS 库和 GPU 利用率上去了但很容易让模型在小数据集上过拟合。patience20的意思是验证集指标连续 20 个 epoch 没有提升就提前终止这个参数对火焰烟雾这种样本量不大、容易过拟合的任务非常管用可以防止半夜训练跑满 100 个 epoch 而浪费电。device0指定使用第一块 GPU。纯 CPU 机器上没必要加这个参数但要把epochs降低到 30 以内因为火焰烟雾数据集即便只有几百张图CPU 训一个 epoch 也要好几分钟。第一次跑通全流程我的建议是用 20 个 epoch 验证整条链路通不通再开正式训练。3.4 训练时看什么YOLO 损失函数与 results.csv训练启动后PyCharm 的 Terminal 里会滚动输出每个 epoch 的 loss 和 mAP。很多新手只看train loss看到它降了就以为万事大吉。实际上 YOLOv8 的损失函数是三个部分的组合在results.csv里会分别记录这三项# 训练输出目录下会生成 results.csv用 pandas 或 Excel 直接打开 # 重点看 train/box_loss、train/cls_loss、train/dfl_loss 三列box_loss衡量预测框和真实框的位置偏差YOLOv8 里采用了 CIOU 和 DFL 的混合策略数值大说明框的位置还不准。cls_loss是分类损失火焰和烟雾类别失衡时cls_loss下降会很慢。dfl_loss是 Distribution Focal Loss它负责细化边框的分布训练后期即使 mAP 已经稳定dfl_loss还会继续缓慢下降这属于正常现象。我一般盯三个信号前 10 个 epoch 的box_loss是否明显下降val/cls_loss是否和train/cls_loss保持同步如果验证集的分类损失先降后升说明过拟合了metrics/mAP50是否在某个 epoch 后突然跳升跳升太早太猛反而要怀疑数据泄漏。训练结束后不要只截个 loss 图直接把results.csv拖到 Excel 里看曲线比看终端输出更清楚。4. 火焰烟雾训练的 4 个坑现象、原因和解决顺序这章写的全是真实工作里容易出的问题。每一个我都按“现象、原因、解决”的顺序讲方便你直接对照排查。4.1 类别编号和 data.yaml 对不上火焰和烟雾互相标反现象训练能正常跑完loss 也降到很低但推理的时候把火苗识别成 smoke把白烟识别成 fire甚至把烟囱、路灯也标成火焰。原因大部分原始标注工具导出的类别编号不一定是连续的。比如有人从公开数据集转换时先合并了 10 个类再删掉 8 个类最后 labels 里残留的编号是 0、2、5而data.yaml里按顺序只写了 fire 和 smoke 两个类编号分别变成了 0 和 1。这会导致模型把原始的 2 号类当成 1 号类来学训练过程不会报错但语义全乱了。解决用第 2 章的体检脚本先打印class_counter拿到数据集里实际出现的全部类别编号。然后写一个重映射脚本把旧编号映射到以 0 开头的连续编号import os def remap_labels(labels_dir, old_to_new): for name in os.listdir(labels_dir): if not name.endswith(.txt): continue path os.path.join(labels_dir, name) with open(path, r) as f: lines f.readlines() with open(path, w) as f: for line in lines: parts line.strip().split() if len(parts) ! 5: continue cls int(parts[0]) if cls in old_to_new: parts[0] str(old_to_new[cls]) f.write( .join(parts) \n) # 假设统计出来编号只有 0 和 20 表示火焰2 表示烟雾 old_to_new {0: 0, 2: 1} remap_labels(fire_smoke/train/labels, old_to_new) remap_labels(fire_smoke/val/labels, old_to_new)这段脚本会把所有标签文件里的旧编号替换成新编号。注意labels_dir要同时处理 train 和 val 两个目录只处理一个会在训练时报“验证集类别数不一致”。重映射完再跑一次体检脚本确认编号已经变成连续的 0 和 1再开始训练。4.2 空标签与纯色图片loss 变成 nan 的元凶现象训练到某个 epoch 后终端输出里出现nan然后 mAP 全部归零或者训练根本启动不了直接报All labels are empty。原因数据集里混入了空 txt 文件或者图片本身是纯黑、纯白、单色块YOLO 的损失函数在计算时除数为零梯度变成了 NaN。视频抽帧数据最容易出现这种问题因为摄像头黑屏、对着白墙的画面会被抽进来标注时又被跳过留下空标签。解决先用体检脚本删掉空标签文件再把对应的图片也删掉。对于纯色图片需要额外用 OpenCV 检查灰度标准差import cv2 import os img_dir fire_smoke/train/images labels_dir fire_smoke/train/labels for name in os.listdir(img_dir): path os.path.join(img_dir, name) img cv2.imread(path, cv2.IMREAD_GRAYSCALE) if img is None: print(无法读取:, name) continue if img.std() 5: print(疑似纯色图:, name)这里std()计算的是灰度图的像素标准差。火焰烟雾图像因为烟雾本身有纹理火焰亮度高正常图片的标准差一般会在 20 以上纯黑、纯白或者单色背景图的标准差接近 0。阈值取 5 是为了保留雾天、夜晚这种整体偏暗但仍有内容的图像如果不小心调高了容易误删正常样本。删除时要记住一条原则图片和对应的 txt 标签必须成对删除只删图片或只删标签都是在给训练埋雷。4.3 同源视频随机切分出的数据集mAP 虚高现场失效现象训练时验证集的 mAP50 达到 0.95看起来非常漂亮但把模型拿到真实摄像头画面上一测烟雾漏检严重还经常把消防车排气管当火焰。原因这类数据集很可能来自同一段监控视频按时间顺序抽帧然后随机打乱分成了 train 和 val。由于相邻两帧之间的差异极小模型相当于把训练集里的图像“背”下来了验证时遇到几乎相同的帧自然表现很好但遇到新场景就露馅。解决按视频来源分组而不是按单张图片随机划分。假设原始文件名前缀能区分视频来源import os import random from collections import defaultdict img_dir all_images video_groups defaultdict(list) for name in os.listdir(img_dir): video_id name.split(_)[0] # 文件名前缀是视频编号 video_groups[video_id].append(name) all_videos list(video_groups.keys()) random.seed(42) random.shuffle(all_videos) train_videos all_videos[: int(len(all_videos) * 0.8)] val_videos all_videos[int(len(all_videos) * 0.8):]这段脚本会把同一视频抽出的所有帧全部放到同一边从源头上避免训练集和验证集出现关联帧。要注意的是如果视频抽帧本身做了随机间隔文件名前缀不一定能代表视频来源最好在抽帧时就把视频 ID 写进文件名。这个操作看起来很简单实际能省掉大量无效调参——模型在新场景上的表现至少能提升 10 到 20 个百分点。4.4 小目标烟雾漏检imgsz 与实例分割两种解法现象大团烟雾检测没问题但画面远处飘出的一小缕烟完全检测不到森林场景里烟雾颜色和天空接近时尤其严重。原因YOLO 默认用 640x640 输入如果一个烟雾目标在原图中只有 20x20 像素缩放到 640 后就只剩几个像素特征图上的信息几乎被背景淹没。边界框形式也不适合烟雾——烟雾没有固定边缘框里大量区域是背景模型很难学到稳定的“中心点”特征。解决先尝试提高输入分辨率。把imgsz从 640 提到 1280小目标在特征图上的像素数量会变成原来的 4 倍mAP50-95 通常会有可见提升。显存不够时优先把batch降下来而不是减小输入尺寸。更彻底的办法是换成 YOLO 实例分割。如果数据集里附带的是多边形标注或者你愿意重新标注烟雾轮廓就用yolov8n-seg.pt这类分割模型训练yolo detect train \ datafire_smoke.yaml \ modelyolov8s-seg.pt \ imgsz960 \ batch8 \ epochs100注意这里训练命令和检测稍不同但data.yaml里标签格式需要变成分割格式的.txt每个实例由类别编号和多组归一化多边形坐标构成。火焰和烟雾天然就是不规则目标实例分割输出的是掩码而不是矩形框对消防联动、精准定位火源的场景更实用。如果你当前只有矩形框标签就从检测模型开始不要强行转分割。5. 验证不只是 mAP从指标曲线到肉眼过一遍推理图训练完不等于模型能用。火焰烟雾场景的特点是有大量相似背景指标好不一定现场好用。这章说说我怎么验证一个训练好的火焰烟雾模型。5.1 读懂两个指标mAP50 与 mAP50-95训练结束后先用验证命令跑一遍验证集yolo detect val \ modelruns/fire_smoke/exp1/weights/best.pt \ datafire_smoke.yaml终端会输出两类核心指标mAP50和mAP50-95。mAP50表示预测框和真实框的 IoU 超过 0.5 就判定为正确这是工程验收最常用的指标也更宽容。mAP50-95是把 IoU 阈值从 0.5 按 0.05 的步长升到 0.95取平均值严格要求预测框和真实框贴合得很准。火焰烟雾任务里消防报警策略一般只需要知道哪里有火、哪里有烟框稍微大一点小一点影响不大所以我最看重mAP50。很多网上下载的数据集标注本身不严格如果强行追求mAP50-95反而是在教模型拟合标注误差。我给自己定的及格线是mAP50大于 0.75mAP50-95大于 0.5低于这个水平部署到现场误报和漏报的比例会很高。5.2 混淆矩阵和 PR 曲线看火焰烟雾谁在拖后腿验证完成后runs/fire_smoke/exp1/下会自动生成一堆图表其中confusion_matrix.png和PR_curve.png最值得看。混淆矩阵的横轴是真实类别纵轴是预测类别。对角线上的数字越大越好如果火这一类预测成烟的比例明显偏高说明火焰和烟雾在模型内部的特征太相似或者训练样本量不平衡。PR 曲线能看出不同置信度阈值下的准确率和召回率变化。曲线越靠近右上角越好。如果 PR 曲线在召回率 0.8 之后突然陡然下降说明模型在低置信度区域会产生很多误检。我见过不少火焰烟雾模型全局 mAP 不错但混淆矩阵里“背景被预测成烟火”的比例很高这往往是因为训练数据集里负样本太少。解决方向是补充大量不含火焰烟雾的监控画面而不是继续堆正样本。这类问题从 PR 曲线上能直观看到曲线的横轴召回率很高但精确率始终上不去就说明模型把太多背景框也输出为候选了。5.3 把验证集图片推理一遍用眼睛找指标找不到的问题指标是统计结果但现场用户看的是单张画面。我会把验证集图片跑一遍推理然后打开输出图逐张看yolo detect predict \ modelruns/fire_smoke/exp1/weights/best.pt \ sourcefire_smoke/val/images \ save_txtTrue \ save_confTrue这里source指向验证集图片目录save_txtTrue会为每张图片生成包含类别、坐标、置信度的文本框save_confTrue会在框上标出置信度数字。肉眼检查时重点看置信度在 0.3 到 0.5 之间的目标因为这是最容易误报和漏报的区间。我还会额外准备一组负样本图片比如纯森林、纯天空、街道场景跑一遍推理统计误检数。火焰烟雾项目里一次误报可能触发喷淋或者报警器所以负样本测试比看 mAP 更重要。这一步发现的常见问题有夕阳和红色灯光被识别成 fire空调外机热风或者汽车尾气被识别成 smoke。解决方式是把这些负样本加入训练集的背景类别或者调高部署时的置信度阈值。6. 让模型能落地导出 ONNX 模型后在 AGX Orin 上跑一次推理训练验证都通过后最后一步是把 PyTorch 权重导出成 ONNX再部署到边缘设备。这里不说太多云部署单讲最常见的 NVIDIA AGX Orin 场景。导出命令很简洁yolo export \ modelruns/fire_smoke/exp1/weights/best.pt \ formatonnx \ opset12 \ dynamicFalse \ imgsz640opset12是为了兼容 ONNX Runtime 和 TensorRT 的常见版本dynamicFalse表示固定输入尺寸这会牺牲一点灵活度但能让部署端推理更稳定。火焰烟雾检测的边缘设备上输入尺寸通常固定为训练时的 640动态轴能不用就不用。导出成功后在 AGX Orin 上搭建 YOLO 环境只需安装onnxruntime-gpu然后用 Python 加载import onnxruntime as ort sess ort.InferenceSession(best.onnx, providers[CUDAExecutionProvider])这里providers优先指定 CUDAAGX Orin 的 GPU 推理速度比 CPU 快很多。我吃过一次亏在 PC 上验证时一切正常到了工控机上用 CPU 跑一帧要 400 毫秒完全没法用后来导出 ONNX 并用 GPU 才压到 20 毫秒左右。所以导出前就要想好目标设备GPU 版本和 CPU 版本的量化方式、输入尺寸都可能不一样。另外ONNX 导出后记得用 PyTorch 和 ONNX Runtime 各跑同一张图片对比输出框的坐标和置信度是否接近。我遇到过导出后置信度降低了 0.1 的情况最后定位是opset版本太高导致某些算子实现不一致。现在我的习惯是拿到任何一个新数据集先体检再训练导出固定 opset最后在目标设备上做一次负样本测试。这套流程走完火焰烟雾模型才算是真正能交到现场用。希望帮到你。本文还有配套的精品资源点击获取