简介面向目标检测模型训练的火焰数据集包含1553张已标注火焰图像并为每张图片提供TXT与XML两种格式的标注文件可清晰记录火焰的位置、形状与大小适用于火灾预警、智能监控等场景的模型开发。压缩包内共5260个文件以jpg图像、txt标注、xml标注三类文件为主打包后约194MB目录结构清晰便于直接接入YOLOv5等深度学习项目。目前已有4898人学习下载。资源中还给出了YOLOv5训练参考指标在IoU阈值0.5时mAP达到0.953在0.5至0.95阈值范围内mAP为0.679说明数据标注具备较好的一致性与可用性可作为火焰检测研究的基准数据集也可用于对比不同预处理、数据增强和超参数调优策略对检测效果的影响。对于需要快速构建实时火焰识别模块的开发者这份数据能支撑从模型训练、性能评估到部署验证的完整流程有效节省前期图像采集与标注成本。1. 火焰数据集做目标检测先用它把坑踩一遍火焰检测是个典型的「看着简单、落地一堆坑」的任务。很多刚接触 YOLOv5 的从业者拿到火焰数据集就直接开训结果 mAP 看着不错一到夜间、远距离小目标就全面翻车。问题往往不在模型而在数据本身标签格式混乱、目标尺度失衡、标注框把烟雾和火焰混在一起。这份火焰数据集含标注好的标签的价值在于你不需要再从零收集图片、自己画框能直接把精力放到格式转换、训练调参和踩坑排错上。适合要做消防预警、烟火识别、边缘设备部署的算法工程师和学生也适合想系统过一遍 YOLOv5 全流程的入门者。2. 先认标签这份火焰数据集的格式与两种主流标注规范2.1 VOC XML 和 YOLO TXT 的结构差异拿到数据集第一步不是急着训练而是确认标签格式。火焰检测数据集的标注格式常见做法是 PASCAL VOC 的 XML 和 YOLO 的 TXT 两种。VOC 格式把每个目标的信息存在 XML 里包含文件名、图像尺寸、目标类别和 bounding box 坐标坐标是绝对值像素值。YOLO 格式则是一个类别 四个归一化浮点数对应中心点 x、中心点 y、宽、高范围都在 0 到 1 之间。两者各有使用场景VOC 更适合用 LabelImg 这类标注工具继续编辑YOLO TXT 则能直接喂给 YOLOv5 训练脚本。这份数据集的标签若是 VOC 格式你需要留意 XML 里的folder、filename和path字段是否和实际图片路径一致。很多标注工具写path时会带上标注者的本机绝对路径比如C:\Users\xxx\Desktop\fire\xxx.jpg这种字段在跨机器迁移时非常容易导致路径解析失败。我更倾向于在脚本里只读取filename然后按自定义规则重新拼接图片路径而不是信任 XML 里的绝对路径。VOC XML 和 YOLO TXT 的另一层差异体现在边框坐标的精度上。VOC 的xmin、ymin、xmax、ymax是整数代表像素位置YOLO 的归一化坐标是浮点数转换过程中会引入四舍五入误差但这个误差在 640x640 输入下通常不到一个像素对火焰这类语义边界本来就模糊的目标影响不大。真正影响训练效果的还是标注框是否贴合火焰轮廓而不是小数位精度。2.2 标签内容不透明时先跑一遍格式探测脚本数据集简介里写了「含标注好的标签」但没细说格式和类别名时不要凭文件名后缀猜测直接写个脚本把标签文件夹扫一遍。我每次拿到新数据集都会先统计一下标签文件大小分布、格式类型和类别名集合。这个动作能提前发现很多隐蔽问题比如某个标签文件是空的、某张图的 XML 被截断、类别名混入了全角和半角空格。import os from pathlib import Path import xml.etree.ElementTree as ET label_dir Path(labels/xml) classes set() empty_files [] parse_errors [] for xml_file in label_dir.glob(*.xml): try: tree ET.parse(xml_file) root tree.getroot() objects root.findall(object) if not objects: empty_files.append(xml_file.name) for obj in objects: name obj.find(name).text.strip() classes.add(name) except ET.ParseError: parse_errors.append(xml_file.name) print(类别集合:, classes) print(空标签文件:, empty_files[:10]) print(解析失败:, parse_errors[:10]) print(总文件数:, len(list(label_dir.glob(*.xml))))这段脚本的核心逻辑是遍历指定目录下的所有 XML用 ElementTree 解析出object节点里的name字段同时捕获两类异常一类是文件存在但没有目标框另一类是 XML 结构损坏导致解析直接抛异常。跑完之后你就能看到这份火焰数据集到底标注了哪些类别、有没有空标签文件、有没有损坏文件。参数上需要注意glob(*.xml)只匹配当前目录不递归子文件夹如果标签是按 train/val 分目录存放的你需要分别执行或改成rglob(*.xml)。这段脚本还有一层价值它能暴露类别名的真实写法。很多数据集的类别名看起来是fire实际可能混着Fire、fire带尾随空格、flame这样的变体。YOLOv5 训练时类别名写错一个字母该类的标签就会全部失效并导致训练日志里出现诡异的no labels found警告。2.3 转换到 YOLO 格式脚本与归一化计算如果这份数据集的标签是 VOC XML训练 YOLOv5 之前必须转换成 YOLO TXT。转换的核心就是把 XML 里的xmin、ymin、xmax、ymax绝对值坐标换算成归一化的中心点坐标和宽高。公式不复杂中心点 x 等于左右边界均值除以图片宽度中心点 y 等于上下边界均值除以图片高度宽度和高度分别除以图片宽高。但这里有一个高频踩坑点XML 里存的坐标是基于原始图片尺寸的如果图片在标注后被人为缩放或裁剪过那转换时用的宽度和高度也必须是对应缩放后的尺寸否则所有框的位置整体偏移。import xml.etree.ElementTree as ET from pathlib import Path def voc_to_yolo(xml_path, class_names, out_dir): tree ET.parse(xml_path) root tree.getroot() size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) yolo_lines [] for obj in root.findall(object): cls_name obj.find(name).text.strip() if cls_name not in class_names: continue cls_id class_names.index(cls_name) box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h width (xmax - xmin) / img_w height (ymax - ymin) / img_h yolo_lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) out_path Path(out_dir) / (Path(xml_path).stem .txt) out_path.write_text(\n.join(yolo_lines), encodingutf-8) class_names [fire, smoke] voc_to_yolo(labels/xml/fire_001.xml, class_names, labels/yolo)这段脚本的关键参数有class_names列表和out_dir输出目录。class_names的顺序就是训练时类别 ID 的映射顺序一旦确定就不能在中途更改否则之前转换好的标签全部作废。脚本里我用float()包裹 XML 里的坐标文本即使标注文件里写的是空字符串或非法字符也能提前抛出异常定位问题文件。输出时保留六位小数这个精度足够 640x640 输入下的训练需求。转换完成后别急着训练抽几张图把 YOLO 标签画回原图目测框位置是否贴合火焰边界。这一步听起来繁琐但能同时验证两类错误坐标归一化是否正确以及标注本身是否可靠。我见过有数据集标注框只框住了火焰中心亮部完全没覆盖外焰边缘这种标签训练出来的模型对边缘火焰的召回率会明显偏低。3. 训练前的数据体检类别平衡、光照分布与漏标检测3.1 统计每张图的类别框数量与目标尺度数据集的图片数量和标注质量不能直接画等号。火焰检测任务里常见的标签分布问题有三类大部分图片只有一两个目标框少数图片有十几个框夜间火焰框占比极低白天占比极高小目标框数量少但图片尺寸大。这些问题会直接导致训练出来的模型对特定场景失效所以有必要在训练前写一段统计脚本把每张图的框数量、目标宽度高度占比、类别分布拉成一张表。这份火焰数据集的分布情况直接决定了后面 YOLOv5 的超参数怎么调。from pathlib import Path import numpy as np label_dir Path(labels/yolo) per_image_counts [] relative_sizes [] for txt_file in label_dir.glob(*.txt): lines [l.strip() for l in txt_file.read_text().splitlines() if l.strip()] per_image_counts.append(len(lines)) for line in lines: parts line.split() w float(parts[3]) h float(parts[4]) relative_sizes.append(max(w, h)) per_image_counts np.array(per_image_counts) relative_sizes np.array(relative_sizes) print(每张图目标框数量: 均值 %.2f, 中位数 %.2f, 最大 %d % ( per_image_counts.mean(), np.median(per_image_counts), per_image_counts.max())) print(目标尺寸占比: 均值 %.4f, 50分位 %.4f, 90分位 %.4f % ( relative_sizes.mean(), np.percentile(relative_sizes, 50), np.percentile(relative_sizes, 90)))这段脚本统计的是 YOLO 格式标签统计结果能帮你判断两件事。第一每张图的框数量如果中位数明显低于均值说明个别图片框特别多大多数图片只有一两个目标训练时会呈现「负样本比例高、正样本稀疏」的局面。第二目标尺寸占比反映的是目标的尺度分布火焰检测里尺寸占比小于 0.05 的目标基本属于小目标如果 90 分位依然很小那就意味着模型需要更强的浅层特征提取能力YOLOv5 的输入尺寸可能需要从默认 640 提升到 1280或者开启多尺度训练。两类统计的结论直接服务于数据增广策略。框数量过少的图片训练时靠马赛克增强和随机裁剪能把局部火焰样本数量提上去目标尺度整体偏小的数据集则更适合在训练时把mosaic和copy_paste这类增广策略开得保守一点因为过度拼接会把小目标再进一步缩小导致漏检更严重。3.2 光照和背景干扰对火焰检测的影响火焰数据集里最容易被忽略的变量是光照条件。白天阳光下的火焰和外焰的对比度可能很低火焰的橙色区域在暖色调背景里几乎融成一片而夜间火焰则是纯黑背景里的高亮目标。这两种情况的特征分布差异极大如果训练集里夜间图片占比过低模型在夜间场景下基本靠猜。做标签检查时我习惯按图片的亮度直方图粗略分组统计每组里目标框的数量和平均尺寸。import cv2 import numpy as np from pathlib import Path img_dir Path(images) dark_count 0 bright_count 0 dark_box_count 0 bright_box_count 0 for img_file in img_dir.glob(*.jpg): img cv2.imread(str(img_file)) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) brightness gray.mean() if brightness 80: dark_count 1 else: bright_count 1 print(暗光图片占比: %.2f % (dark_count / len(list(img_dir.glob(*.jpg)))))这里的核心参数是亮度阈值 80这是我处理火焰数据集时比较常用的分界值。低于 80 的图片按暗光处理高于 80 的按正常光照处理。实际使用时你可以根据数据集的色偏情况调整这个值比如很多夜间火焰图片的背景不是纯黑而是深蓝灰度均值可能在 40 到 70 之间。如果暗光图片占比明显偏低建议训练前做一次简单的数据增广对暗光图片做亮度抖动、加入高斯噪声、随机降低对比度让模型在训练阶段就见过更接近真实场景的输入。光照分组的意义不止于数据增广它还能指导验证集的划分方式。如果验证集里全是白天图片模型在夜间的真实表现就成了黑匣子。合理做法是让训练集和验证集都包含一定比例的夜间样本并且保证夜间样本里的目标框数量占比和整体分布一致。3.3 训练集/验证集划分按场景分而不是按文件随机分火焰检测数据集的划分方式直接关系到指标可信度。很多人直接train_test_split按文件名随机划分这会带来一个隐患同一个场景连续拍摄的多帧画面可能同时出现在训练集和验证集里导致验证集的 mAP 虚高。火焰目标检测的图片序列通常来自监控视频抽帧相邻帧之间的背景几乎相同、火焰形态高度相似模型见过了训练集里的这一帧验证集里同场景的另一帧自然容易被正确识别。我一般会按场景目录或拍摄时间段做划分把相同场景的图片放进同一个集合。具体做法是给图片文件名加上场景前缀比如warehouse_001.jpg、warehouse_002.jpg表示同一个仓库的连续帧划分时以场景为单位而不是以单张图片为单位。如果原始文件命名没带场景信息可以按文件名里的时间戳或目录结构来判断。这样划分出来的验证集才能真实反映模型的泛化能力。4. 用 YOLOv5 训练火焰检测从配置到收敛4.1 数据集 YAML 与超参数调整YOLOv5 训练火焰检测模型时最先要准备的是数据集配置文件。这个 YAML 文件定义了训练集和验证集的图片路径、类别数量和类别名称列表内容简洁但极其关键。路径写错或类别名不匹配训练脚本启动后看起来正常实际加载的标签可能全部为空等你发现时已经浪费了几个小时的训练时间。train: /data/fire_dataset/images/train val: /data/fire_dataset/images/val nc: 1 names: [fire]这份 YAML 的关键参数有三个train和val指向图片目录脚本会自动去同级的labels目录找对应的标签文件nc是类别数量这份火焰数据集只标注了火焰一个类别就填 1names的类别名列表必须和标签文件里的分类 ID 一一对应。如果数据集里还标注了 smokenc就要改成 2names也要相应增加。这里最容易出错的地方是train和val的路径格式YOLOv5 支持绝对路径和相对于项目根目录的相对路径但当 YAML 文件被复制到别的机器上时绝对路径经常会失效建议统一用相对路径。超参数方面火焰检测不是常规的目标检测任务默认的hyp.scratch.yaml需要适度调整。火焰目标通常具有明显的颜色特征和纹理特征尤其是外焰边缘的锯齿状结构训练时手动降低一点色度增强的幅度可以避免背景色被误判为火焰。我一般会把hsv_h从默认的 0.015 降到 0.01因为火焰的橙色色相范围本身很窄增广太激进反而让模型学到错误的颜色关联。4.2 训练命令与关键参数含义YOLOv5 的训练入口是项目根目录下的train.py命令行参数多数有默认值但对火焰数据集来说有四个参数需要单独指定。--img决定训练输入尺寸火焰检测里小目标占比高时建议用 640 甚至 960 而不是默认的 640--batch受限于显存大小同一批数据里图片尺寸越大能放的 batch 越小--epochs火焰数据集通常 100 轮以内可以收敛但如果数据分布复杂可能需要更多--data指向你写好的 YAML 配置文件。python train.py --data fire.yaml --weights yolov5s.pt --img 640 --batch 16 --epochs 100 --project runs/train_fire --name fire_v1这行命令的作用是启动一次 YOLOv5 训练实验。--weights yolov5s.pt表示加载官方预训练权重做迁移学习s 版本的模型规模适中对火焰检测这种单类别任务来说s 或 m 版本通常已经足够不需要一上来就上 x 版本。--project和--name决定了训练输出的保存路径跑多次实验时可以把不同参数组合保存到不同名字下方便后续对比。--cache参数在数据集较大时建议开启它会把图片提前加载进内存而不是每次迭代都从磁盘读能显著加快训练速度代价是占用内存。参数调整的经验是批次大小和输入尺寸优先于模型复杂度。如果显存只有 8G把输入尺寸从 640 降到 512同时把 batch 从 16 降到 8比直接换大模型更划算。--workers参数控制数据加载的线程数Windows 下设置为 0 可以避免某些环境下 DataLoader 抛错Linux 服务器上设置为 4 或 8 都不错。如果训练日志里出现 GPU 利用率长期低于 50%多半是数据读取速度跟不上加大--workers比调整模型更有效。4.3 验证输出怎么看mAP、混淆矩阵与 PR 曲线训练结束后验证结果保存在runs/train_fire/fire_v1目录里重点看三个文件results.png、confusion_matrix.png和PR_curve.png。results.png里包含训练和验证的 loss 曲线、precision、recall 和 mAP0.5 曲线用来判断模型是否收敛。火焰检测里如果最终的train/obj_loss和val/obj_loss差值过大说明过拟合已经比较严重需要在数据增广或模型正则化上做调整而不是继续加训练轮数。PR_curve.png展示了不同置信度阈值下精确率和召回率的权衡关系。火焰检测场景里误检的代价通常比漏检低因为后续还有消防联动确认环节但漏检的代价极高。如果你的使用场景是预警系统建议把推理时的置信度阈值下调到 0.25 甚至 0.2把召回率提上去。如果模型在验证集上的mAP0.5达标但mAP0.5:0.95偏低说明模型对火焰框边界的位置预测还不够精确尤其是外焰和非火焰橙红色区域的边界。这时可以对标注质量做一次回头检查很多标注框的外边界只是粗略框了一个矩形和真实火焰轮廓存在偏差mAP0.5:0.95 就会有天花板。5. 火焰数据集实战避坑标注类错误有多隐蔽5.1 标签文件字符串编码不一致导致解析失败现象训练脚本启动后日志里大量出现WARNING: No labels found in .../labels/train/xxx.txt但打开标签文件明明有内容。原因不同的数据标注工具和操作系统生成文本文件时可能采用不同的编码格式。Windows 下用记事本另存为 UTF-8 时可能带 BOM 头Linux 下的解析器把 BOM 当作字符处理导致首行解析失败。还有一类情况是类别名里混入了全角冒号或中文逗号肉眼看不出来但 YOLO 解析逻辑会直接跳过。解决写一个清洗脚本统一把标签文件转成无 BOM 的 UTF-8 格式并移除所有控制字符和不可见字符。清洗之后重新检查类别集合确认只有一个标准化命名。5.2 同一张图重复出现在训练集和验证集现象训练结束后验证集的 mAP 高达 0.95 以上但拿到一段新的监控视频测试检测效果稀烂漏检一大堆。原因划分训练集和验证集时直接用了随机划分没有考虑图片之间的内容相似性。火焰数据集里很多图片来自同一段视频的连续抽帧相邻帧的背景、火焰位置、尺度几乎一样随机划分导致同一场景的画面同时出现在训练集和验证集mAP 虚高但没有实际参考价值。解决按图片名称前缀或目录重新分组确保同场景的图片只进入一个集合。实际操作时我会把所有图片文件名整理成一份带场景标签的 CSV按场景做分层抽样而不是直接对文件名列表做随机打乱。5.3 离群标注烟雾被框进去、火焰中心被漏掉现象模型训练收敛后在验证集某些图上出现诡异行为同一个火焰区域有时给一个框、有时给两个框对白烟误检率高。原因看标签统计时会发现部分标注框的中心点和宽高与其他框存在明显离群。火焰标注的质量问题通常有两类一类是把烟雾和火焰混在一起标注导致模型学到的是「橙红色 灰白色」区域的混合特征另一类是只框住了火焰最亮的核心区域完全忽略了外焰导致框中心和实际火焰形心偏差很大。解决用脚本把每张图上标注框尺寸和位置的可视化叠加到原图上逐张检查离群标签。发现大偏差的框用标注工具修正或直接把整个标签文件剔除。火焰检测宁可少一个质量差的正样本也不要让它干扰模型学到的特征边界。5.4 类别名大小写不一致导致训练标签全部丢失现象训练刚开始时日志提示found 0 images and 0 labels但图片目录和标签目录下的文件都在。原因标签文件里有部分类别名是fire部分是Fire而数据集的 YAML 配置文件里写的名字是fire。YOLOv5 加载标签时按索引号和名称双重匹配多余的类别名直接匹配失败。解决统一把所有标签文件里的类别名改成 YAML 里定义的同一个字符串。这一步必须在格式转换脚本里归一化处理不要手动改单个文件否则下一次重新生成部分标签又会出现新的不一致。5.5 图片尺寸与标注坐标不匹配导致目标框偏移现象训练输出 mAP 正常但推理阶段框总是比火焰区域大一圈或者整体偏移到火焰旁边。原因标注工具在标注时按较大尺寸的原始图标注之后图片被批量压缩到小尺寸但标注坐标没有同步换算导致宽高比例失真。解决检查标签里记录的目标宽度占比和实际图片的视觉比例是否吻合。修复方法是读取原始图片尺寸和当前图片尺寸按比例换算所有坐标后重新生成标签这个逻辑与 VOC 转 YOLO 的脚本合并在一起处理原图和标签同步缩放。6. 验证与进阶把火焰检测结果接进工程前先做这四步训练完成不代表可以直接投入使用。把模型接到视频流或边缘设备之前我强制自己先做四件事用没参与训练的真实视频片段测试、统计不同光照条件下的召回率、对误检样本做反向排查、针对部署环境做推理速度评估。第一步是准备一段全新的监控视频不要用测试集图片也不要用爬来的网络图而是模拟真实部署场景的连续视频帧。视频中应该包含火焰从点燃到蔓延的过程以及一些常见的干扰源比如红色汽车尾灯、橙黄色路灯、夕阳反射在玻璃上的高光。用训练好的模型跑一遍视频记录漏检发生的帧和误检发生的帧按时间段把结果整理成表格能快速发现光照偏暗或背景复杂的时段是否存在系统性失效。第二步是统计不同光照条件下的表现。把视频按亮度分成纯白天、黄昏、夜间三个阶段分别计算每个阶段的召回率和精确率。夜间火焰的高亮特征其实更容易被检测到但如果训练集里夜间样本不足模型可能反而只在白天表现好。如果夜间漏检明显优先复习训练集里的光照分布而不是盲目调阈值。第三步是对误检样本做反向排查。把每个误检框单独截出来放到热力图旁边观察判断模型是被颜色骗了还是被纹理骗了。红色车尾灯和火焰的色相非常接近区别在于火焰有动态纹理和边缘模糊感但静态单帧检测很难利用这些信息。如果误检集中在红色圆形物体上说明模型缺少火焰形态约束可以考虑在训练集里加入一些红色干扰样本作为背景负样本强化模型区分「橙红色圆形区域」和「橙红色不规则区域」的能力。第四步是部署环境的推理速度测试。火焰检测通常跑在嵌入式设备或普通监控主机上建议测量三个指标单帧推理时间、GPU 显存占用、CPU 占用率。如果目标是边缘设备且帧率要求 25FPS 以上而当前模型在目标设备上只能跑 10FPS优先做两件事一是把输入尺寸降到 416火焰目标通常较大降分辨率对精度影响有限二是换用yolov5n或yolov5s版本配合半精度推理速度提升明显。导出模型时用export.py转成 TensorRT 或 ONNX 格式不同格式的预处理方式有差异尤其是输入归一化和通道顺序实际部署前必须用同一张图对比导出前后的推理结果防止格式不一致导致输出错乱。从那以后我每次拿到新的火焰数据都会先跑一遍格式探测和分布统计再决定训练策略不再贪图省事直接开训。很多坑都在标签层模型本身反而是最可靠的部分。希望帮到你。本文还有配套的精品资源点击获取