简介一份面向目标检测研究方向的数据集说明文档围绕俯拍航拍视角下的森林火灾检测任务系统梳理了6116张图片、2类目标fire与smoke的标注规范。资料采用Pascal VOC与YOLO两种通用格式分别对应xml与txt标注文件并给出每类框数fire共15380个、smoke共12613个总计27993个标注框便于训练和评估火灾检测模型。压缩包内仅有1个docx文件大小约5.06MB内容除基础格式说明外还包含labelImg标注工具的使用规则、实际图片预览与标注示例帮助用户直观理解标注的准确性和具体细节。该资料适用于森林防火智能视觉系统、航拍图像目标检测等场景无论是初学者核验数据组织方式还是研究者开展模型训练前的数据分布评估都能从中获得清晰的参照。目前已有62人学习下载可作为启动相关检测任务时快速了解标注规范与数据统计的实用参考。1. 俯拍森林火灾目标检测这份 6116 张的 VOCYOLO 数据集到底值不值得用做目标检测的同行应该都有同感通用场景的公开数据集一抓一大把但一换到俯拍航拍场景尤其是森林火灾这种强烟雾、小目标、背景杂乱的检测任务能直接拿来训练的数据集立刻变得稀缺。这份标题里的「俯拍航拍森林火灾检测数据集 VOCYOLO 格式 6116 张 2 类别」解决的就是目标检测里航拍场景数据冷启动的问题——你不需要再从零标注几千张无人机画面而是直接拿到一份已经按 VOC 和 YOLO 两种主流格式组织好的训练素材类别围绕火和烟两类核心目标展开。适合的人群很明确正在做森林防火巡检、无人机火情识别、遥感目标检测落地的算法工程师和学生。因为它的标注格式是双轨的你既可以用 YOLO 系框架直接开训也可以退回 VOC 生态做细粒度调试这是它和单格式数据集最大的区别。这类数据集的实际可用性关键不在张数而在标注质量、场景分布和类别平衡。6116 张这个量级对于二分类火灾检测来说不算小但如果全部是晴天、近距离、大火特写那模型换到真实巡检视角基本废掉。所以这篇笔记抛开标题本身站在一线训练的角度把这份数据集的格式结构、转换风险、训练参数、验证方法和踩坑记录完整讲一遍。包括中途踩过的坑也一并写出来——凌晨三点调参到心态崩掉的那种。目标是在你看完目录结构后能直接落一条训练命令跑通并知道结果出来之后怎么判断它真能用还是虚胖。2. VOC 和 YOLO 双格式目录结构差异、XML 与 txt 的转换逻辑2.1 同一批图片为什么要维护两套标注文件目标检测数据集的标注格式林林总总最常碰到的就是 PASCAL VOC 和 YOLO 这两套。VOC 格式是早期学术验证和比赛的标准姿势一张图配一个 XML 文件里面用object节点描述每个目标的类别名和边界框坐标。坐标是绝对像素值左上角xmin/ymin左下角xmax/ymax人眼直接能读在做数据核查、画框调试和语义分析时非常直观。而 YOLO 格式走的是归一化 txt 路线每行一个目标依次是类别 id 和归一化后的中心点坐标cx cy w h所有值都缩放到 0 到 1 之间。模型训练时加载这种格式成本低不用做坐标换算Dataloader 可以直接按比例映射到任意输入分辨率。现在 YOLOv5 之后的整个 Ultralytics 生态、YOLOv8、YOLOv11 甚至一些端侧推理框架都默认吃这种 txt。所以一个数据集同时给 VOC 和 YOLO 两种格式本质是降低使用门槛你想用经典的 Faster R-CNN 或者 SSD 做对比实验直接读 XML你想用 YOLO 系快速出结果打开训练目录就能跑。2.2 从 VOC 的 XML 结构到 YOLO 的 txt 文本最小解析脚本这份数据集的核心价值在标注而想要彻底理解它的组织方式最直接的做法是自己写一次 VOC 到 YOLO 的格式解析。即使你拿到的数据集已经内置了 YOLO 格式这个转换脚本依然是全行业通用的保底工具——因为后续你一定会往数据集里追加自己的航拍素材而新标注出来的 XML 需要和原有 YOLO txt 合并。下面是一个很常见的转换做法基于 Python 的 ElementTree 解析 XML再通过 PIL 读取原图尺寸完成归一化import os import xml.etree.ElementTree as ET from PIL import Image def voc_xml_to_yolo_txt(xml_path, output_label_path, image_dir, class_names): tree ET.parse(xml_path) root tree.getroot() # 读取图片尺寸注意这里是 XML 里的 size 节点 size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) # 用 PIL 二次核对原图实际尺寸防止 XML 里记录尺寸和真实图不一致 image_name os.path.splitext(os.path.basename(xml_path))[0] .jpg with Image.open(os.path.join(image_dir, image_name)) as im: real_w, real_h im.size if (real_w, real_h) ! (img_w, img_h): img_w, img_h real_w, real_h lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_names: continue class_id class_names.index(name) bndbox obj.find(bndbox) xmin float(bndbox.find(xmin).text) ymin float(bndbox.find(ymin).text) xmax float(bndbox.find(xmax).text) ymax float(bndbox.find(ymax).text) # 关键一步把绝对坐标转成 YOLO 的归一化中心点加宽高 x_center (xmin xmax) / 2.0 / img_w y_center (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h # 防呆归一化后坐标理论上应在 0~1 之间超出可能是标注越界 x_center min(max(x_center, 0.0), 1.0) y_center min(max(y_center, 0.0), 1.0) w min(max(w, 0.0), 1.0) h min(max(h, 0.0), 1.0) lines.append(f{class_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}) with open(output_label_path, w) as f: f.write(\n.join(lines))这个脚本的核心风险控制点有三个。一是图片实际尺寸和 XMLsize节点不一致的情况在二手数据集里太常见了——有的标注工具会残留下错误宽高如果直接信 XML 里的数字归一化后的坐标会整体偏移训练出来的检测框全偏。所以我一般会用 PIL 实际打开图片重新读一遍尺寸宁可多花一点 IO 时间也不要赌标注软件的良心。二是类别名过滤逻辑class_names列表的顺序直接决定了 txt 里类别 id 的编码这份森林火灾数据集的 2 个类别顺序如果调整过训练时必须保持一致否则模型输出的类别和标注对不上损失函数直接混乱。三是越界裁剪边界框贴图边缘时浮点误差可能让cx w / 2超过 1.0不 clip 会导致 YOLO 训练时出现 NaN 梯度。2.3 双格式共存的目录组织与 ImageSets 分组逻辑拿到这份数据集后VOC 部分的目录结构是约定俗成的Annotations目录放所有 XMLJPEGImages放所有 JPG 图片ImageSets/Main下面放train.txt、val.txt和test.txt。其中 train.txt 和 val.txt 是关键每行一个不带扩展名的图片文件名标定哪些图进训练集、哪些图进验证集。这套目录划分逻辑的潜台词是数据划分已经替你做好了直接按文件列表读取即可。而 YOLO 部分的目录一般是images/train、images/val和labels/train、labels/val训练集和验证集的图片与 txt 一一对应。要注意的是两份划分是否一致——如果 VOC 版和 YOLO 版的训练验证划分比例不一样那你做对比实验时基线就乱了。我拿到这类双格式数据集的第一件事就是比对两个划分文件的重合度把相同图片的归属列出来不一致的话强烈建议以其中一个为准重新划分不要偷懒。3. 用 YOLOv8 训练这份航拍火灾数据集从目录整理到出权重的完整流程3.1 先组织数据目录YOLO 格式的硬性要求拿到下载好的数据集压缩包后第一件事不是跑训练是把目录整理成 Ultralytics 能看懂的样子。常见做法是以fire_data为根下面建images/train、images/val、labels/train、labels/val四个子目录。如果你的数据本身只有图片和 txt没有划分好的 train/val就用 sklearn 的train_test_split按 8:2 或 9:1 切一次注意要按图片名配对拷贝代码很简单但漏掉一张后续 debug 全是玄学。import os import shutil from sklearn.model_selection import train_test_split image_dir datasets/fire_dataset/JPEGImages # 所有原图 label_dir datasets/fire_dataset/labels # 所有 YOLO 格式 txt # 只保留既有 jpg 又有对应 txt 的图片防止脏样本混入训练 valid_images [] for img_name in os.listdir(image_dir): stem os.path.splitext(img_name)[0] if os.path.exists(os.path.join(label_dir, stem .txt)): valid_images.append(img_name) train_imgs, val_imgs train_test_split(valid_images, test_size0.2, random_state42) for split, img_list in [(train, train_imgs), (val, val_imgs)]: os.makedirs(fdatasets/fire_data/images/{split}, exist_okTrue) os.makedirs(fdatasets/fire_data/labels/{split}, exist_okTrue) for img_name in img_list: stem os.path.splitext(img_name)[0] shutil.copy(os.path.join(image_dir, img_name), fdatasets/fire_data/images/{split}/{img_name}) shutil.copy(os.path.join(label_dir, stem .txt), fdatasets/fire_data/labels/{split}/{stem}.txt)逻辑说明这个脚本在做的是样本有效性过滤和配对拷贝因为很多公开数据集里存在图片有、但标签缺失或者标签存在但图片损坏的情况直接全量拷过去最后训练时会有 Dataloader 报错。random_state42固定随机种子保证每次重跑脚本划分结果一致后续排查问题时可以复现。test_size0.2对于 6116 张图意味着验证集大概 1223 张这个比例在森林火灾检测里是足够了的因为场景重复度高不需要太大验证集反而训练集能多喂一点是一点。3.2 写 data.yaml类别顺序必须和训练时的模型输出对齐Ultralytics 框架训练时需要一个data.yaml文件描述数据路径和类别信息。路径建议用绝对路径尤其是新手阶段不要用相对路径碰运气省下来的都是血压。class names 的顺序必须和 txt 文件里的类别 id 严格对齐比如你约定 id 0 是 smokeid 1 是 fire那 yaml 里names列表的第一个必须写smoke。# fire_data.yaml train: /home/user/fire_data/images/train val: /home/user/fire_data/images/val nc: 2 names: 0: smoke 1: fire参数说明train和val指向的是图片目录不是标签目录框架会根据图片路径自动推导同前缀的 txt 路径所以标签目录的命名必须严格保持labels且和images同级。nc是类别数这份数据集固定在 2 类。还有一个隐藏细节yaml 文件里不要写test字段尤其是刚开始跑通流程时多了反而容易因为路径不存在导致校验失败。3.3 训练命令的选型与关键参数解释YOLOv8 是目前 Ultralytics 生态里最成熟的训练入口选它不是因为版本最新而是它和 YOLOv5 的权重迁移兼容性好且训练日志里的输出信息对排错更友好——尤其是每个类别的 AP 值会单独打出来这对二分类火灾检测判断哪类拖后腿很有价值。训练命令我一般这么写yolo detect train \ modelyolov8s.pt \ data/home/user/fire_data/fire_data.yaml \ epochs100 \ batch16 \ imgsz1280 \ device0 \ workers8 \ patience30 \ projectruns/fire_detect \ nameexp_smoke_fire参数逻辑选择yolov8s.pt而非 n 或 m是因为森林火灾里火和烟在航拍画面中往往是中小目标n 模型的特征提取层太浅对边界模糊的烟雾容易欠拟合m 模型精度高但训练慢而且 6116 张的量级喂给 m 有轻微过拟合风险。imgsz1280是这份数据集最值得注意的设定——俯拍图里火焰的像素占比通常远小于通用目标检测数据集640 输入容易让火苗缩小到十几个像素特征图里直接消失1280 至少能保留一定的细节信息代价是显存占用约翻倍实测 RTX 3090 上 batch16 刚好压在边缘。patience30是早期停止的容忍度连续 30 轮验证 mAP 不涨就停防过拟合同时省时间。3.4 训练过程监控损失曲线跌到多少才算稳训练跑起来之后不要只看控制台刷屏要看runs/fire_detect/exp_smoke_fire/results.csv里 box loss 和 cls loss 的曲线走势。火灾检测这种二分类任务box loss 稳定在 1.5 以下、cls loss 稳定在 0.5 以下训练后期基本是平稳下降就说明梯度没炸。如果 cls loss 出现先降后升的 U 形反转大概率是过拟合信号这时候就要回头检查是不是训练集和验证集有大量重复的连续帧图片——航拍数据集经常出现这种情况同一个机位拍的序列帧被随机切进了两个集合验证 mAP 虚高到你不敢相信。4. 6116 张航拍图的训练效果验证mAP 指标之外还要看什么4.1 验证命令与输出文件解读训练结束后验证环节并不是走过场。YOLOv8 自带val模式一条命令就能算出 mAP、Precision、Recall 和每类 APyolo detect val \ modelruns/fire_detect/exp_smoke_fire/weights/best.pt \ data/home/user/fire_data/fire_data.yaml \ imgsz1280 \ batch16 \ save_jsonTrue \ save_confTrue跑完看results.csv和confusion_matrix.png。其中比较关键的是每类 AP 的单独数值不要只看均值 mAP——如果 smoke 类 AP 是 0.86 而 fire 类 AP 只有 0.61整体 mAP 依旧好看但投入真实巡检系统后漏报的全是 flame 类别这种问题只有逐类看指标才能暴露。save_jsonTrue会输出一个包含每张图所有预测框的 JSON后续做误检分析时可以调用。4.2 mAP50 与 mAP50-95 的差距是航拍火灾检测最大的照妖镜mAP50 是 IoU 阈值在 0.5 时的平均精度mAP50-95 是 0.5 到 0.95 每隔 0.05 取一次阈值的平均。这两者之间的数值差非常关键。通用检测任务里两者差 0.1 属于正常但航拍火灾检测里如果 mAP50 有 0.72、mAP50-95 只有 0.38说明模型预测框的位置稳定性很差——框的大致位置对了但边界抖动严重这和烟雾目标本身没有锐利边缘高度相关。这种情况下调 loss 权重作用有限不如直接检查标注质量烟雾的框本身是不是就是模糊的。我通常还会把模型在验证集上的预测结果图导出来人工抽查 20 张关注三件事一是有没有把树影、云层、裸露岩石误检成 smoke二是大块火焰区域是否被拆成了多个重叠的小框三是验证集里有没有标注漏掉的小火点而模型捡漏回来的情况。模型漏检小火点问题在小目标场景里尤其尖锐——如果模型输出了一个高置信度但标注里不存在的火框视觉上像是模型在加分实际上是因为真值标注漏了混淆矩阵里的 FP 数值是假的这一点直接影响你对数据集质量的判断。4.3 类别目标尺寸分布训练前就该算完的功课验证环节发现的很多问题其实是训练前就埋下的。这份数据集是航拍俯拍视角我建议在训练第一天对标注文件做一个目标尺寸分布统计画一个 w 和 h 的散点图看边界框面积占图片面积的比例。很多森林火灾数据集里 smoke 类目标面积占比集中在 0.01 到 0.08 之间而 fire 类可能只有 0.005 到 0.03——这个差异直接决定了 YOLO 是否需要开启多尺度训练以及是否要针对小目标做切片推理。如果发现大量目标边长小于 32 像素那你的 imgsz 需要进一步加高或者干脆用 SAHI 做推理端切片。5. 俯拍森林火灾检测避坑笔记5 条参数与标注层面的血泪教训5.1 现象小目标火点完全检测不到训练结束后测试集上肉眼可见的火点模型没有反应输出框全部集中在大烟雾区域。原因是俯拍画面中火苗通常只占几百个像素而默认imgsz640时下采样 32 倍后的特征图里目标只有个位数像素特征已经完全丢失。解决方式分两条路训练端把imgsz提到 1280 甚至 1536同时开启mosaic1.0让模型在训练时看到更多缩放大小的实例如果显存不够推理端改用 SAHI 切片推理把大图切成 512 的切片再逐个检测对小目标召回率的提升立竿见影。5.2 现象验证 mAP 很高但实测完全不可用模型在验证集上 mAP50 达到了 0.85下放到实拍视频里却疯狂误报。原因是这份数据集的拍摄高度和角度分布太单一模型学到的其实是特定海拔和俯仰角下的纹理特征而不是火的本质特征。解决方法是重新审视数据划分按拍摄批次或场景分组而不是按文件名随机划分确保验证集包含模型没见过的拍摄条件。更彻底的做法是从原始视频里抽帧后先用聚类算法筛一遍场景相似度把相似度高的帧放到同一集合避免数据泄漏导致的虚高 mAP。5.3 现象VOC XML 和 YOLO txt 的标注范围不一致同一张图XML 里框的是整个烟雾扩散区域而 YOLO txt 里框的是烟雾核心浓密区。这种双格式数据集如果是从两个标注阶段拼接出来的很容易出现。后果是训练时同一个目标被不同的真值边界拉扯box loss 降不下去。解决方式是在训练前写脚本对两张图的归一化坐标做 IoU 比对找出差异大于 0.3 的同名目标人工介入修正而不是无脑信任其中某一套。5.4 现象烟雾类别正负样本比例失衡训练时 fire 类 AP 一直上不去6116 张图 2 个类别看起来简单的二分类问题但实际统计后 fire 类实例数可能只是 smoke 的五分之一甚至更低。YOLO 默认对所有类别一视同仁地计算分类损失少数类就会被多数类淹没。解决方法是先统计每个类别的实例数量如果差距过大可以在 loss 层面给 fire 类调高cls_gain或者对 fire 类做离线复制粘贴增强——把包含 fire 的图在训练时额外随机复制进 batch本质上改变采样权重。5.5 现象训练到一半 loss 变成 NaN网络训练到第 40 轮左右cls_loss突然变成 nan控制台直接刷红线。排查后发现是标注文件里有几行 txt 的目标边缘坐标等于 0 或 1.0归一化后宽高为 0导致 loss 计算时除法分母为零。这个坑在二手数据集中极其常见解决方式是在训练脚本前加一个数据清洗步骤逐行读 txt把 w 或 h 小于 0.001 的行直接过滤掉同时检查是否有整行负坐标的脏数据——不要在训练中途才爆出来那种晚上十点排查的酸爽体验相信经历过的人都懂。6. 往生产方向走SAHI 切片推理与 TensorRT 部署思路验证完模型精度后下一步通常是从离线验证挪到实时巡检或者批量视频分析。这里最值得先说透的是 SAHI 切片推理——直接作用在航拍大图上把 4000x3000 的原始帧切成 640x640 的小块每个小块独立跑检测再通过 NMS 合并重叠区域输出框。在森林火灾这种超高分辨率俯拍场景里SAHI 几乎是把 YOLOv8 的小目标 AP 上调 10 个百分点的最省事手段不需要重新训练。部署端的习惯做法是先导出 ONNX再通过 TensorRT 转成 engine 文件。航拍巡检设备上常见的是 Jetson Orin 或者工业工控机TensorRT 用 FP16 精度模式配合固定 batch 对 1280 输入做优化单路视频流的延迟可以压到 15ms 以内。需要提醒一下转 TensorRT 时imgsz必须固定为你训练时用的尺度动态尺寸虽然支持但会触发 CUDA 内存重分配反而把延迟拉高。检测置信度阈值建议在部署环境里重新标定一次航拍场景视野远、目标小0.25 的置信度可能带来大量误报实际放到 0.45 到 0.5 之间会更稳。这个方向走到最后瓶颈往往不在模型而在数据迭代——每飞一个新的地块、换一个季节都要把新的难例抽帧回来重新标注、增量训练。我自己的习惯是每个巡检项目结束都保留一批模型预测失败且人工确认的样本按季度合并进训练集持续滚动的数据集比反复调参性价比高得多。希望这些从格式转换到部署全流程的细节能帮你少走几段弯路尤其是格式解析和切片推理这两个环节前者能保证不翻车后者才是把航拍火灾检测真正推进到实用状态的那一步。本文还有配套的精品资源点击获取