火灾烟雾图像标注数据集实战：从格式清洗到YOLOv8部署调优

简介火灾烟雾图像标注数据集是一份面向目标检测方向的计算机视觉资源包含2257张火灾与烟雾相关图像可帮助研究人员和开发者训练、优化火灾和烟雾识别模型解决安全场景中早期火情定位与预警问题。压缩包体积约266.14MB除原始图像外还提供PASCAL VOC与YOLO两种主流标注格式的标注文件便于直接接入常见检测框架进行试验也方便对不同模型的训练效果进行对比。目前已有2280人学习使用该数据集在安全监控、智能家居、应急响应等场景中具有广泛的应用价值可用于火情实时监测与预警也可为无人机巡检和消防侦查提供视觉依据。利用这些数据读者可训练Faster R-CNN、YOLOv3、SSD等检测模型并针对类别平衡、数据增强和超参数调优进行实践以构建更稳定、更高效的火灾烟雾检测系统为公共安全提供技术支撑。同时高质量的标注信息也便于开展数据预处理、标注格式转换与模型评估等完整流程。1. 火灾烟雾图像标注数据集.rar下载不是重点能用才是搜“火灾烟雾图像标注数据集.rar”的人多半已经吃过一次亏好不容易找到一份别人标好的烟雾数据解压、丢进YOLOv8就开训结果 loss 曲线像心电图验证 mAP 忽高忽低最后部署出去晴天误报、阴天漏报。问题不在模型而在你对这份 .rar 做了什么。这个标题背后真正值钱的东西不是压缩包里的几千张 JPG而是从“拿到标注”到“训出能用的检测器”这一段没人替你趟的路。本文按我平时处理这类数据集的实际顺序来写先摸清目录和标注格式再把标注清洗成 YOLO 能吃的格式然后做防泄漏的划分与增强最后用验证指标和阈值调优把模型推向可部署状态。适合做智慧消防、工地烟火识别、森林防火、以及用 YOLOv5/YOLOv8 训练自己数据集的检测工程师。2. 解压前先“体检”目录结构、标注格式与数据可信度拿到任何一个别人分享的数据集我的习惯是先把它当成一个“不可信的黑匣子”来处理。第一次接手火灾烟雾图像标注数据集这类资源时直接解压就开干的人通常会在两三小时后回来问“为什么标签对不上”。这章讲的是怎么在动手写训练脚本之前用最低的成本确认数据能不能用。2.1 用 7z 与 tree 给压缩包做完整性检查rar 这类压缩包在网盘传来传去损坏是常态不是意外。训练到一半发现某张图打不开或者标注文件解压出来是 0 字节那才叫真正的浪费时间。我一般先做完整性测试再解压再列目录。# 测试压缩包完整性不实际解压 7z t 火灾烟雾图像标注数据集.rar # 解压到独立目录避免污染当前工作区 7z x 火灾烟雾图像标注数据集.rar -o./fire_smoke_data # 看一眼整体目录结构最多展开两层 tree -L 2 ./fire_smoke_data # 统计图片与标注文件数量快速判断格式是否统一 find ./fire_smoke_data -name *.jpg | wc -l find ./fire_smoke_data -name *.xml | wc -l7z t这一步输出一段“Everything is Ok”才算通过任何 CRC 错误都意味着传输损坏不要抱着侥幸心理继续。统计图片和 XML 数量的意义在于对齐如果 JPG 有 5000 张而 XML 只有 4700 个说明有大约 6% 的图没有标注这类样本在训练时要么被自动跳过要么会造成 batch 里标签稀疏影响早期收敛。还有一种很常见的现象压缩包里的标注“一半是 XML、一半是 TXT”甚至混了一部分 JSON。这是不同时期由不同人标注后合并打包的结果。遇到这种混合型目录先不要急着转换而是先搞清楚每一类标注各有多少、分别对应哪部分图片。我见过最乱的一个人口普查式数据集光是标注后缀就有三种其中一种还是过时的 LabelMe 格式直接害他白训了一版。2.2 标注格式识别VOC、YOLO 与 COCO 的结构差异图像标注这件事本质上是在“图片上的像素区域”和“语义类别”之间建立对应关系。同样是画一个框不同工具存出来的文件长得很不一样。常见三类格式格式典型后缀核心内容常见生成工具VOC XMLxml文件名、路径、图像尺寸、每个 object 的 name 与 bndbox 绝对坐标LabelImgYOLO TXTtxt每行一个目标类别 id 归一化坐标中心点 x, y; 宽, 高LabelImg、RoboflowCOCO JSONjson单文件包含 images、annotations、categories 三个数组坐标是绝对像素值Labelme、CVAT识别方法很简单打开一个标注文件看前几行。XML 里出现bndbox和xmin的就是 VOCTXT 第一行是“数字 数字 数字 数字 数字”的通常是 YOLO 格式前 4 个值都小于 1 的尤其明显JSON 里包含大量花括号嵌套、且有一个大数组贯穿全文的多半是 COCO 风格。对火灾烟雾这个任务来说我最希望拿到的是 VOC 格式。原因很朴素XML 里带着图片尺寸和绝对坐标转成任何其他格式都不会丢信息而 YOLO TXT 一旦生成反向转回 VOC 会比较麻烦因为归一化坐标乘回宽度时存在舍入误差。不过现实是你很可能拿到的是 TXT因为分享数据的人自己就是用 YOLO 生态来标注的。这也没关系后面章节的转换脚本两个方向都能处理。这个阶段还有一个必须做的事统计类别名。用 grep 把 XML 里所有name字段拉出来去重或者把 TXT 每行的第一个字段排个序。火灾烟雾数据集的类别名通常不是统一的 “smoke” 和 “fire”而是会出现 “Smoke”“smoke_white”“fire_1”“火焰”这类写法。同一种目标七八个别名是这类项目里最典型的标注质量问题也是下一章要重点清洗的对象。3. 把标注清洗成 YOLO 能吃的格式转换脚本与边界处理如果你拿到的是 VOC XML而你要用 YOLOv8 训练自己的数据集那这一步跑不掉把 XML 转成 YOLO TXT。很多人在这一步用网上随手找的脚本结果转完训练时 loss 直接不收敛回头一查坐标归一化写反了。这章给出我常用的转换脚本并解释四个最容易出问题的边界坑。3.1 VOC XML 转 YOLO TXT一个能直接改来用的转换脚本YOLO 格式要求每个 bounding box 一行类别id x_center y_center width height所有值都除以图片宽高做归一化。看下面这个脚本。import xml.etree.ElementTree as ET from pathlib import Path # 类别映射把数据集中杂乱的类名归并成稳定 id # 同义词合并统一小写并去掉空格 CLASS_MAP { smoke: 0, Smoke: 0, smoke_white: 0, fire: 1, Fire: 1, flame: 1, } def convert_voc_to_yolo(xml_path: Path, out_txt_path: Path): tree ET.parse(xml_path) root tree.getroot() # 从标注文件取图片尺寸不依赖外部 image 文件 size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in CLASS_MAP: print(fskip unknown class: {name} in {xml_path.name}) continue # bndbox 里是绝对像素坐标 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) # 防呆有些标注工具把 xmax/ymax 写反 if xmax xmin: xmin, xmax xmax, xmin if ymax ymin: ymin, ymax ymax, ymin # 边界越界处理裁剪到图像范围内避免训练时出现负坐标 xmin max(0, min(xmin, img_w - 1)) xmax max(0, min(xmax, img_w - 1)) ymin max(0, min(ymin, img_h - 1)) ymax max(0, min(ymax, img_h - 1)) w xmax - xmin h ymax - ymin # 过滤掉完全没有面积的退化框 if w 0 or h 0: continue # 转成归一化的中心点 宽高 x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h width w / img_w height h / img_h # 保留 6 位小数够用且避免浮点噪声 lines.append(f{CLASS_MAP[name]} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) # 无有效标注的图片也写一个空 txt便于 YOLO 对齐样本 out_txt_path.write_text(\n.join(lines), encodingutf-8) def batch_convert(annotation_dir: Path, label_dir: Path): label_dir.mkdir(parentsTrue, exist_okTrue) for xml_path in annotation_dir.glob(*.xml): txt_path label_dir / (xml_path.stem .txt) convert_voc_to_yolo(xml_path, txt_path) if __name__ __main__: batch_convert(Path(annotations), Path(labels))逻辑说明脚本读取 XML 里的size作为归一化基准不依赖外部的图片文件这样即使某张原图被误删转换过程也不会中断。bndbox提供的是绝对像素坐标必须除以图片宽高很多人翻车就是把这一步写成了除以 224 或 640——他们拿模型输入尺寸去归一化标注后果是训练时所有框都跑到角落。参数说明CLASS_MAP是必须要按你自己的数据集改的地方。同一份 rar 里可能标注者用过 “smoke_white” 表示白烟、“smoke_black” 表示黑烟如果你希望把它们当成同一类就映射到同一个 id如果你觉得黑烟和白烟在视觉上差异足够大、需要分开训练就分配不同 id。另外保留 6 位小数对 4K 分辨率的图来说精度足够了写成 6 位还能减少 txt 体积几乎不影响磁盘占用。3.2 类别映射、多标签文件与“训练时才发现”的脏数据第一版转换脚本跑完之后别急着训练。先把生成的 txt 全部扫描一遍做这三件事第一确认没有空目录或空文件对应的图片。YOLO 训练时允许空标签文件存在表示该图无目标但如果你的数据集里本来不该有背景图空文件多半说明标注遗漏。看数量如果空 txt 占比超过 5%优先补标而不是直接训练。第二检查类别 id 是否存在越界。如果CLASS_MAP里漏掉一个类名脚本会打印 skip 提示但不中断。这个提示很容易被忽略而skip掉的目标在训练时会被视为背景等价于给背景图灌入错误负样本。我建议把 skip 改成写日志文件而不是只打到控制台。第三检查有没有“一个 XML 里存在两个相同类别的重叠框”。烟雾数据尤其常见标注者先画了一个大框罩住整片烟又觉得不够精细在里面补了一个小框。YOLO 训练时这两个框同时参与 loss 计算模型会学出一个“中间态”的框。遇到重叠严重的框先人工确认再决定保留哪个。# 扫描所有 txt统计每个类别的目标数量与异常空的文件 from pathlib import Path label_dir Path(labels) class_count {0: 0, 1: 0} empty_files [] for txt_path in label_dir.glob(*.txt): lines [l.strip() for l in txt_path.read_text().splitlines() if l.strip()] if not lines: empty_files.append(txt_path.name) continue for line in lines: cls int(line.split()[0]) if cls in class_count: class_count[cls] 1 print(empty txt count:, len(empty_files)) print(class distribution:, class_count)这段代码的作用是把每类目标的实例数统计出来判断类别平衡度。火灾烟雾数据集最常见的失衡形态是fire 类 8000 个实例smoke 类只有 1500 个。这种情况下直接训练模型会对 smoke 严重欠拟合。解决办法有两个要么给 smoke 提高 loss 权重要么做数据增强补足样本。后面第 4 章会讲增强怎么做这里先做到一个数字层面的确认就好。顺带说一句如果你拿到的是 COCO JSON处理逻辑会不同需要把images数组里的id、width、height与annotations数组里的image_id对齐还要处理segmentation多边形转bbox的问题。coco2017 数据集结构里同一个 image_id 可能对应多条 annotation转换时注意不要漏。JSON 转 YOLO 比 XML 转 YOLO 更容易写错因为 JSON 的嵌套层级更深、字段名不统一。4. 划分数据集与增强策略决定模型上限的两个安静因素很多人在这一步直接执行ultralytics里的train_val_split功能或者干脆前 90% 后 10% 一刀切。对普通图片数据集这样做的后果不致命对火灾烟雾这种来自连续视频抽帧的数据集这样做会直接毁掉你的验证集可信度。同一段视频的相邻两帧背景几乎一样如果一帧进了训练集、另一帧进了验证集验证分数会虚高到让你误以为模型已经能用了。4.1 防数据泄漏的划分按视频来源分组而不是按图片随机分火灾烟雾数据集绝大多数是从监控视频或无人机拍摄视频里抽帧得到的。抽帧的时间间隔如果比较短相邻帧画面高度相似。随机划分时相似的帧大概率同时出现在 train 和 val 里模型等于“背过答案去考试”。我一般会在 rar 里先找文件名规律如果文件名形如video01_frame_0001.jpg那前缀就是分组依据。如果没有明显规律就去看同一拍摄场景的 EXIF 信息或者文件名连续段。下面这段脚本按文件名前缀做分组划分。import random from pathlib import Path from collections import defaultdict # 假设文件命名规律是 场景id_帧号.jpg如 scene03_0042.jpg image_dir Path(images) data defaultdict(list) for img_path in image_dir.glob(*.jpg): scene_id img_path.stem.split(_)[0] # 按场景分组 data[scene_id].append(img_path) # 划分比例8:1:1 scene_list list(data.keys()) random.seed(42) random.shuffle(scene_list) train_scenes scene_list[: int(len(scene_list) * 0.8)] val_scenes scene_list[int(len(scene_list) * 0.8) : int(len(scene_list) * 0.9)] test_scenes scene_list[int(len(scene_list) * 0.9) :] def write_split(scene_ids, out_file): paths [] for sid in scene_ids: paths.extend(data[sid]) with open(out_file, w) as f: f.write(\n.join(str(p) for p in paths)) write_split(train_scenes, train.txt) write_split(val_scenes, val.txt) write_split(test_scenes, test.txt)逻辑说明这个脚本保证同一个场景的全部帧只进 train / val / test 中的某一个。val 里的每一张图对模型来说都是“陌生的场景”mAP 数字才会有参考意义。参数说明random.seed(42)固定随机种子保证重复运行得到相同的划分方便复现这个习惯在调参时很重要否则你换了划分方式就分不清效果提升来自模型改动还是数据划分变化。占比 8:1:1 是常见做法如果数据量少可以放宽到 7:2:1让 val 更多以稳定评估如果整体样本超过 2 万张可以 9:0.5:0.5。还有一个容易忽略的点划分后要检查 val 和 test 中是否包含“同一场景不同时间”的帧。比如同一栋楼的起火视频分别截了白天版和傍晚版文件名前缀相同但光照条件完全不同这时建议把前缀细化到“场景时间段”否则 val 的难度会骤降参考价值失真。4.2 在线增强少用 Mosaic 对烟雾检测的副作用图像增强在烟雾检测里的作用比通用目标检测更关键因为烟雾本身的“实体感”很弱边缘模糊、半透明、形状不定模型容易过拟合到特定背景。YOLOv8 训练自己的数据集时默认开启 Mosaic 增强但对烟雾这类目标Mosaic 并不总是好东西。Mosaic 会把四张图拼到一张图里相当于缩小了每个目标的相对尺寸。烟雾目标本来就偏小、偏模糊再被缩小模型很容易学到“模糊小色块 烟雾”这种错误关联直接导致误报率上升。我通常会在训练的前 10 个 epoch 关闭 Mosaic让模型先把基础特征学到手之后再用较低概率开启微调。# ultralytics 的默认训练配置在 yaml 里按需覆盖 # train.yaml 片段 train: ./train.txt val: ./val.txt test: ./test.txt nc: 2 names: [smoke, fire] # 关闭前 10 个 epoch 的 mosaic mosaic: 0.0 # 全局关闭 mixup烟雾场景下 mixup 会产生诡异的半透明叠加 mixup: 0.0如果你用的是 albumentations 做离线增强或在线 pipeline我建议优先保留这三类随机亮度对比度、随机旋转 15 度、随机裁剪缩放。烟雾检测对光照变化极其敏感亮度增强能明显提升夜间场景的鲁棒性。旋转不要超过 15 度烟雾没有明显方向性但旋转过大会引入无关背景变化。import albumentations as A # 用于 yolo 训练的数据增强 pipeline train_transform A.Compose([ A.RandomBrightnessContrast( brightness_limit0.3, contrast_limit0.3, p0.8 ), A.Rotate(limit15, border_mode0, p0.6), A.RandomSizedBBoxSafeCrop( width640, height640, erosion_rate0.2, p0.5 ), ], bbox_paramsA.BboxParams( formatyolo, label_fields[class_labels] ))参数说明RandomBrightnessContrast的brightness_limit0.3意味着亮度在正负 30% 范围内随机扰动这个值对烟雾场景偏激进但对夜间起火的样本非常有效可以抵消监控摄像头自动增益造成的光照跳变。Rotate的border_mode0是把旋转后的空白区域填 0黑色而不是用边缘像素填充目的是在训练时强制模型看到“黑色背景下的烟雾”这恰好模拟了夜景。RandomSizedBBoxSafeCrop会保证边界框不被裁掉是增强里少有的不会弄坏标注的操作erosion_rate0.2表示允许框略微贴边。注意增强参数不能拍脑袋固定我的验证习惯是先只调一个变量比如单独测 brightness_limit 从 0.2 提到 0.4 后 val mAP 的变化一起调三个出了问题你根本不知道是谁干的。增强是高风险收益项它可能让你的 mAP 涨 3 个点也可能掉 5 个点别迷信默认配置。5. 火灾烟雾数据集训练的 5 个典型踩坑点与排查方法这一章记录我在这类数据集上真实遇到过的坑。每一条都是“现象 → 原因 → 解决”的结构血泪经验可以直接对照排查。5.1 训练 loss 正常但 val 完全检测不到烟雾现象训练曲线收敛得很漂亮loss 一路下降但推理测试图像时烟雾区域一个框都不出。原因数据泄漏的反向版本——训练集和验证集划分时按图片随机打散而视频抽帧的相邻帧极其相似训练集里已经见过验证集的场景模型学会了“识别背景”而不是“识别烟雾”。一旦换了真正新的场景立刻打回原形。解决按第 4 章的脚本重新按场景分组划分重点是 val 和 test 不能和 train 共用任何同一视频来源的帧。如果重新划分后 val mAP 从 0.9 掉到 0.6别慌这是真实的水平。5.2 类别 id 错位导致 fire 全部检测成 smoke现象val 里 fire 的框全部打成了 smoke 标签但 shape 位置是对的。原因转换脚本的CLASS_MAP里重复赋值比如两个类型都映射到了 0。最常见的是分享者给的 YOLO txt 里类别 id 从 1 开始而不是从 0 开始而 YOLO 训练的nc2只认识 0 和 1。系统性地差一位就是全部错位。解决统计训练集 txt 里出现过的所有类别 id 的集合和data.yaml里的names顺序做一次交叉比对。我每次转换后都会跑一遍那 10 行统计脚本确保每类都有数据、id 无空洞。如果是 1 起始的标注转的时候统一减 1 再做训练。5.3 大量小目标烟雾漏检但大框检测效果很好现象近距离的大团烟雾能检出来远处刚冒头的、还没形成浓烟的小目标基本全漏。原因烟雾的标注框经常画得“比烟本身大”——标注者倾向于把整片灰色区域都框进去导致真实烟面积只占框的 30%模型实际学到的是一大半背景。这种框对大烟团影响不大对小目标就是致命的框内有效特征太少。解决检查标注框的宽高分布看是不是大量集中在整张图面积的 20% 以上。如果是用脚本把明显过大的退回重新标注或者在增强里加入随机裁剪缩放让模型被动地看到不同尺度的烟雾。除此之外可以在推理时对同一张图做多尺度预测用小尺寸输入侧重全局、大尺寸输入侧重细节然后合并结果。5.4 室内白墙在强光下高概率误报为 smoke现象晴天窗户边、白色墙壁区域置信度 0.7 以上的 smoke 框频繁出现。原因训练数据里白色烟雾的样本大多出现在浅色背景里模型没有学到“纹理结构”而是学到了“高亮度 低饱和度区域 烟雾”。尤其当增强里把 brightness_limit 调得过大浅色背景变白后模型会把这个模式强化。解决洗数据时把“背景也是白色/浅色”的烟雾样本拿出来单独看一眼如果这个组合极少考虑补充或做选择性增强。部署时把置信度阈值从 0.25 提到 0.45 能压掉大部分误报但代价是漏报增加。更稳的办法是在训练时给背景类加一点负样本专门收集一些高亮的墙面、反光地面的图片标注为空。5.5 解压后图片能看但标注文件全是 0 字节现象rar 解压后txt / xml 文件数量齐全但打开全是空的文件大小 0 KB。原因网盘压缩时文件损坏或者在打包前一批空文件就被打进来了。这类问题在7z t阶段测不出来因为压缩包本身的结构是完整的。解决解压后用脚本遍历所有标注文件的字节数把 0 字节文件对应的图片挪到一个单独目录并输出清单。下一步从这份清单回到 rar 源文件确认如果源文件本身有问题就考虑用另一台设备重新下载一次。我有一次被这个问题坑掉了整个下午从那以后解压 → 统计标注文件字节数 → 核图片数量就成了固定三步。6. 用验证指标与阈值调优把模型推向“能报警”的状态训练完一轮val mAP50 到了 0.78看起来不差但这个数字对火灾烟雾场景几乎没意义。真正有意义的是在保持可接受误报率的前提下能不能做到不漏掉一簇刚冒头的小烟。这章讲我最后一步的做法。YOLOv8 训练完会输出 P、R、mAP50、mAP50-95 四个指标。烟雾检测我主要盯 recall。理由很直接消防报警漏报的代价远大于误报。一次误报引起的人工复核只有几十秒成本一次漏报可能就是一整栋楼的损失。所以我的做法是先接受一个相对低的置信度阈值0.25然后通过验证集上的“阈值-误报数”曲线来反推部署值。from ultralytics import YOLO # 加载训练好的模型在 test 集上扫描不同置信度阈值 model YOLO(runs/detect/train/weights/best.pt) results model.predict( source./test.txt, conf0.05, # 先放很低把候选框都打出来 save_txtFalse, verboseFalse, ) # 统计不同阈值下的目标数量与平均置信度 for thresh in [0.1, 0.2, 0.3, 0.4, 0.5, 0.6]: total_boxes 0 for r in results: if r.boxes is not None: confs r.boxes.conf.cpu().numpy() total_boxes int((confs thresh).sum()) print(fconf {thresh}: {total_boxes} boxes)逻辑说明先以 conf0.05 的低阈值跑完整个测试集把模型觉得“有点像目标”的框全部保留再人为把阈值一档一档往上抬观察候选框数量的变化。如果阈值从 0.3 升到 0.4框数骤降 60%说明大部分检测框本身就处在低置信度区间模型其实没有把握这时就该回到数据层面解决问题而不是继续调阈值。关于 mAP50 和 mAP50-95 的取值烟雾这类目标边界天然模糊mAP50-95 一般偏低不要因为它只有 0.4 就认定模型没用。更合理的验证手段是抽几段完全没有参与训练的监控视频做端到端跑测统计报警延迟和误报间隔。我留下的习惯是每训完一版一定把验证集里“置信度最高的 10 个误报框”和“置信度最低的 10 个漏检框”打印出来贴到墙上——前者告诉你模型被什么骗了后者告诉你模型还没学会什么。这两组图看得足够多你慢慢会形成对烟雾数据的直觉。另外如果你的场景是大范围室外监控可以考虑把这类火灾烟雾图像标注数据和遥感图像标注做一次联合训练遥感视角下的烟雾形态更整体、更接近俯视能帮模型建立对烟雾“形状连续性”的认知减少对纹理细节的依赖。两者尺度差异大联合训练时需要对遥感数据做额外下采样但收益往往是跨场景泛化能力的明显提升。说回最开头那个 .rar。它只是一个起点真正决定你能不能把它变成可部署检测方案的是你花在数据清洗、划分、增强和阈值调校上的那些功夫。我每次处理新数据集都会告诉自己模型翻车多数不是模型的问题而是数据在某个环节骗了你。希望这篇能帮你少走几段弯路。本文还有配套的精品资源点击获取