简介：这是一套针对打火机细粒度识别场景的图像数据集，已按COCO标准格式完成标注，适用于目标检测、实例分割等深度学习模型的训练与评估。资源共含1004个文件，其中1000张为真实场景拍摄的打火机图片，覆盖常见类型、不同角度和光照条件，并附带2份json标注文件与2份txt说明文件。json文件保存了类别与边界框坐标信息，txt文件可用于快速浏览数据集构成，整体结构清晰，可直接接入YOLO、MMDetection、Detectron2等主流检测框架，省去自行采集和标注的繁琐过程。压缩包仅39.82MB，体积紧凑，下载解压后即可投入使用。数据集既适合刚入门目标检测的开发者完整走通数据加载、模型训练与验证流程，也能为算法工程师提供细分场景下的基准测试数据，辅助评估不同网络结构的识别效果。目前已有803人学习浏览，在打火机这类垂直识别任务中具备不错的参考价值，图片保留原始编号，后续也可按需扩充。

1. 打火机识别数据集：COCO格式能直接喂给 YOLO 和 Detectron2 吗

打火机识别看着小众，实际需求比你想的多：安检 X 光图里找违禁品、电商平台过滤违规商品图、回收分拣线区分一次性打火机和防风机，都得先解决「在图片里把打火机框出来」这个事。这份「各种类型的打火机识别数据集 COCO 格式」就是把图片和标注打包好的现成数据，zip 解压后能看到 jpg 原图和 json 标注文件，是标准的 COCO 标注体系。适合刚拿到 yolov8 想训练自己的数据集、但对标注格式还没完全吃透的开发者，也适合做目标检测评估但不想花一周时间自己标数据的人。

2. COCO 格式解构：从 zip 解压到看懂 annotations 字段

2.1 解压后先别急着训练，看清文件目录结构

拿到 zip 先别急着解压完就跑训练，COCO 格式的数据集目录结构是有讲究的。常见做法是解压后分成 images 和 annotations 两个目录，images 里全是 jpg 图片，annotations 里只有一个 json 文件。这份数据集的文件名带着20230817_095837_023_jpg.rf.xxxxx这种前缀，.rf.是 Roboflow 平台导出的标记，说明图片经过统一缩放，标注坐标已经同步映射过，不会出现图是 1920 的、标注却按 640 算的事。

unzip 各种类型的打火机识别数据集coco格式.zip -d lighter_dataset cd lighter_dataset find . -type f | head -20

这段命令把 zip 解压到 lighter_dataset 目录，然后列出前 20 个文件确认结构。我一般会顺手用du -sh看一下整体大小，再用find . -name "*.json"确认标注文件路径，因为后面所有脚本都要写死这个路径。解压完成后第一件事是看一眼类别名和图片数量，别直接开训。

2.2 COCO 标注格式的五个核心字段

COCO 格式的核心是那个 json 文件，结构分五块：info存储数据集说明，images是图片列表，annotations是标注框列表，categories是类别映射，licenses是版权信息。训练模型时真正用到的只有images、annotations、categories三个。

{ "images": [ {"id": 1, "file_name": "20230817_095837_023_jpg.rf.e53b34f8b6dc1f2edc6393fe5268b23c.jpg", "width": 640, "height": 640} ], "annotations": [ {"id": 1, "image_id": 1, "category_id": 0, "bbox": [125, 92, 84, 152], "area": 12768} ], "categories": [ {"id": 0, "name": "lighter_general"} ] }

这个片段展示了单张图片、单个标注框、单个类别的最小结构。bbox数组的四个数依次是左上角 x 坐标、左上角 y 坐标、框宽度、框高度，单位是像素。area是框面积，COCO 评测指标计算 AP 时会按面积分桶统计，小目标、中目标、大目标分开算。注意category_id是从 0 开始还是从 1 开始，不同工具导出习惯不同，YOLO 系列一般从 0 开始，Detectron2 也要求从 0 开始连续编号，如果 json 里是 1 开头，转 YOLO 格式时类别就得统一减 1。

2.3 这份数据集的标注特点和适用场景

从文件名看，图片来自同一个采集批次，大概率是对着不同打火机实体拍摄后统一上传到标注平台处理。这类数据集常见的特点是背景相对干净、目标大小相对均衡，适合做模型选型验证和训练流程测试，但直接上生产环境做安检识别还需要补充复杂背景和遮挡样本。打火机识别的难点在于：一次性塑料打火机表面反光强、透明壳体导致目标边缘模糊、防风火机的金属喷嘴和壳体对比度低。这份数据如果覆盖了多个类型，训练出来的模型才有泛化价值。

3. 把 COCO 数据送进训练管线：加载、转换与数据划分实战

3.1 用 pycocotools 校验数据集完整性

很多人在训练时才报「json 解析失败」或者「图片路径不存在」，根源是没在训练前做完整性校验。这一步值得写个三四十行脚本跑一遍。pycocotools 是 COCO 官方工具库，能加载标注并给出类别统计、图片数量统计，还能可视化标注框覆盖情况。

from pycocotools.coco import COCO import os coco = COCO('annotations/instances_default.json') cat_ids = coco.getCatIds() print('类别数量:', len(cat_ids)) for cid in cat_ids: cat = coco.loadCats(cid)[0] img_ids = coco.getImgIds(catIds=cid) print(f"类别 {cat['name']} (id={cid}): {len(img_ids)} 张图片") img_ids = coco.getImgIds() print('总图片数:', len(img_ids)) for img_id in img_ids[:10]: img = coco.loadImgs(img_id)[0] path = os.path.join('images', img['file_name']) if not os.path.exists(path): print('缺图:', path)

这段脚本输出类别列表、每个类别关联的图片数，以及前 10 张图片的文件是否存在。输出结果能直接看出类别是否均衡、有没有图片丢失。注意instances_default.json是 Roboflow 导出 COCO 格式时的默认文件名，如果解压后不是这个名字，改成实际的 json 路径即可。

3.2 COCO 转 YOLO 格式：转换脚本与四个边界坑

yolov8 官方训练接口支持 COCO 格式，但实际用下来，更多人会先转成 YOLO 的 txt 格式再训练，因为老版本、以及一些工具链只认 txt。转换的核心是坐标换算：把 COCO 的 x、y、w、h 变成归一化的 center_x、center_y、width、height，再除以图片宽高。

import json, os with open('annotations/instances_default.json', 'r') as f: data = json.load(f) img_map = {img['id']: img for img in data['images']} cat_map = {cat['id']: i for i, cat in enumerate(data['categories'])} os.makedirs('labels', exist_ok=True) for ann in data['annotations']: img = img_map[ann['image_id']] w, h = img['width'], img['height'] x, y, bw, bh = ann['bbox'] cx, cy = (x + bw / 2) / w, (y + bh / 2) / h nw, nh = bw / w, bh / h if cx < 0 or cy < 0 or cx > 1 or cy > 1 or nw <= 0 or nh <= 0: print('异常框:', ann['id'], ann['bbox']) continue label_path = os.path.join('labels', img['file_name'].replace('.jpg', '.txt')) with open(label_path, 'a') as f: f.write(f"{cat_map[ann['category_id']]} {cx:.6f} {cy:.6f} {nw:.6f} {nh:.6f}\n")

四行核心计算里最容易翻车的有四处：一是没有除以图片宽高就写入，导致训练时边界框全在图片外；二是图片实际尺寸和 json 里记录的 width、height 不一致，这种情况常见于标注平台缩放过图；三是类别 id 没有重映射，COCO 的类别 id 通常是 1 开头，YOLO 要求 0 开头；四是写 txt 时用追加模式'a'，重复运行脚本会把旧标注重复写一行进去。这个脚本加上异常框检测会在坐标越界时打印出来，一般跑完看一眼输出有没有异常行就行。

3.3 划分训练集、验证集和测试集：随机抽样要点

数据划分是另一个容易出问题的环节。COCO 格式没有内置划分机制，需要按图片 id 随机打散。常见比例是 70% 训练、20% 验证、10% 测试。但注意需要保证每个类别在三个集合里都有一定数量，纯随机有可能出现某个类别全部落在训练集的情况。

# 在数据集根目录下执行 mkdir -p images/train images/val images/test # 按 7:2:1 比例划分，先打乱再分配 python -c " import os, random, shutil from pycocotools.coco import COCO coco = COCO('annotations/instances_default.json') imgs = coco.getImgIds() random.seed(42) random.shuffle(imgs) n = len(imgs) for idx, img_id in enumerate(imgs): fname = coco.loadImgs(img_id)[0]['file_name'] src = os.path.join('images', fname) if idx < int(n * 0.7): dst = 'images/train/' elif idx < int(n * 0.9): dst = 'images/val/' else: dst = 'images/test/' shutil.copy(src, dst + fname) "

这段命令把图片按 7:2:1 分到三个子目录。随机种子固定成 42，保证每次运行结果一致。划分之后需要同步生成对应的标注文件，如果用 COCO 格式训练，就得把标注 json 也拆成三份，只保留对应图片 id 的 annotations 记录。如果嫌麻烦，直接按目录结构建 YOLO 格式数据集，yolov8 的data.yaml里指定 train、val 路径就行。

4. 打火机识别数据集避坑：训练前必须知道的五个问题

4.1 标注框类别错位：category_id 不连续导致模型输出错乱

现象：训练过程中 loss 正常下降，验证时 mAP 很低，打印预测结果发现类别名对不上，比如把防风打火机识别成了普通打火机。

原因：COCO json 里的category_id不是连续的。Roboflow 导出的类别 id 有时从 1 开始且间隔不固定，而 YOLO 和 Detectron2 要求从 0 开始的连续整数。转换脚本如果没有做重映射，模型看到的类别索引和实际类别对不上，整个训练白跑。

解决：写转换脚本时强制用枚举替代原始 id。用{cat_id: idx for idx, cat_id in enumerate(coco.getCatIds())}建立映射表，再生成 YOLO 格式的 txt 文件。训练完用model.names打印类别列表验证顺序，别直接信配置文件的数字。

4.2 图片尺寸和标注尺寸不匹配：坐标全部偏移

现象：训练出来的模型框总是偏左上或右下，甚至框贴在目标边缘但没有压实。可视化检查时发现标注框整体偏移一段距离。

原因：很多标注平台导出的 json 里写的还是原始图片尺寸，但 zip 里实际放的图片已经缩放过了。文件名里的.rf.标记说明 Roboflow 处理过，但 json 里有时保留了原尺寸信息，这会导致归一化坐标全部算错。我遇到过图片实际是 640 的、json 里写 1280 的情况，转换后目标框整体左上偏移。

解决：校验环节加一步，随机抽 5 到 10 张图片，读取真实宽高和 json 里的宽高对比，不一致就按图片实际尺寸重新计算。用 Python 的 PIL 或 cv2 读取图片尺寸，题目中提到的图片尺寸在转换前必须对齐。

4.3 透明打火机壳体导致标注框过大

现象：模型对透明塑料打火机的检测框明显比目标大一圈，或者把背景也算进去了。验证集上这种类别的 AP 明显低于其他类别。

原因：打火机这一类的标注本身就难，透明壳体的视觉边界不清晰，不同标注员的框选习惯不同。有的框选最大外轮廓，有的框选不透明部分，同一个类别的框一致性差，模型学到的边界是模糊的，预测时框的范围就飘。

解决：训练前用可视化脚本把所有标注框画出来检查一遍。发现问题多就做类别拆分，把「透明壳体打火机」和「金属打火机」分成两个类别，让模型分别学，最后再在推理阶段合并成同一个输出。这份数据如果类别本身已经细分，就直接用细分类别训练，别图省事合并。

4.4 小目标占比低导致模型漏检

现象：验证时大目标识别率高，但小目标几乎全漏，尤其图片里打火机离镜头远的时候。mAP 看着还行，实际应用一测就翻车。

原因：打火机本身是小目标，一张 640x640 的图里打火机可能只占 60x120 像素。如果标注框面积小于图片面积的 1%，COCO 评估时按 small 目标算，这一类模型的 recall 通常偏低。数据集中小目标样本少，训练时模型根本没见过足够多的小目标正样本。

解决：检查标注里 bbox 面积分布，如果小目标占比低，训练时把imgsz从 640 提到 960 或 1280，相当于把目标放大后再训练。另外可以用 mosaic 增强和 Copy-Paste 增强复制小目标到其他图，yolov8 的augment参数里有相关配置。用了之后验证集 small 目标的 AP 一般能提升 3 到 5 个点。

4.5 解压后文件名带特殊字符导致读取失败

现象：训练启动时报某个图片路径找不到，或者在 Windows 上解压后文件名乱码。

原因：Roboflow 导出的文件名带有_jpg.rf.这种中缀，有些平台还会在文件名里加空格或特殊符号。Windows 的文件系统容忍度比 Linux 低，解压工具不同也可能截断或转义文件名。

解决：解压后先批量重命名，把文件名规范成img_0001.jpg这种带序号的形式，同步更新 json 里的file_name字段。这一步虽然麻烦，但在 Windows 上能避开后续所有路径兼容性问题。命令行工具如果是在 Windows 上用，建议先用 PowerShell 跑一遍重命名再进 Linux 服务器训练。

5. 用这套数据集训练目标检测模型：YOLOv8 和 Detectron2 的实战参数

5.1 选择模型：这份数据的规模适合什么模型

打火机识别属于中等难度目标检测，类别数量少、目标外观差异不算极端，但透明材质和反光是难点。数据量如果不大（几百张到一两千张），YOLOv8s 或 YOLOv8m 是性价比最高的选择，训练速度快、显存占用低、容易调通。数据量大且追求精度，再考虑 YOLOv8x 或 RT-DETR。Detectron2 在这类任务上的优势不大，除非你已经在这套框架里有现成的前处理流水线，否则不建议新手直接上手。

5.2 YOLOv8 训练配置：从 data.yaml 到训练命令

把数据集组织成 YOLO 格式后，核心是写对data.yaml。这个文件指定训练图片路径、验证图片路径、类别数量和类别名。

# data.yaml path: /data/lighter_dataset train: images/train val: images/val nc: 2 names: ['fire_lighter', 'gas_lighter']

path是数据集根目录的绝对路径，train和val是相对路径，nc必须和names的长度一致，多一个少一个都会在训练启动时报维度错误。类别名的顺序要和转换标注时用的顺序完全一致，这个顺序由转换脚本里的枚举顺序决定。然后用下面的命令训练：

yolo detect train \ model=yolov8s.pt \ data=data.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ lr0=0.01 \ augment=True \ patience=20

model=yolov8s.pt表示加载预训练权重做迁移学习，比从零训练收敛快很多；imgsz是训练输入尺寸，打火机目标小时可以调到 960；batch按显存调，8GB 显存跑 16 没问题，更大可以试 32；patience=20表示连续 20 个 epoch 验证集没提升就早停，省时间。augment 默认开，但数据本身如果已经做过增强，可以关掉一部分。

5.3 Detectron2 训练：COCO 格式直接加载

Detectron2 内置了 COCO 数据加载器，用这份数据不用转 YOLO 格式，直接注册数据集就能训练。需要先注册数据集路径，再注册类别元信息。

from detectron2.data import DatasetCatalog, MetadataCatalog from detectron2.utils.visualizer import Visualizer from detectron2.config import get_cfg from detectron2.engine import DefaultTrainer import os def register_dataset(): DatasetCatalog.register("lighter_train", lambda: get_dicts("annotations/instances_default.json")) MetadataCatalog.get("lighter_train").set(thing_classes=["fire_lighter", "gas_lighter"]) def get_dicts(json_file): from detectron2.data.datasets import load_coco_json return load_coco_json(json_file, "images", "lighter_train")

注意load_coco_json的dataset_name参数必须和注册名一致，images是图片目录路径。Detectron2 对类别 id 的要求是从 0 开始且连续，如果 json 里的category_id从 1 开始，load_coco_json会返回空标注，这是一种容易踩的坑。用前面提到的重映射脚本先处理 json 再加载，别直接拿原始文件跑。

5.4 训练时监控什么：loss 曲线和验证指标的解读

训练过程中不要只盯总 loss，要分开看box_loss、cls_loss、dfl_loss三条曲线的走势。正常情况是三个 loss 都下降，然后趋于平缓。如果cls_loss降了但box_loss波动，说明框回归不稳定，考虑降低学习率或增大 batch。验证集上的mAP50和mAP50-95是两个指标，mAP50反映框是否大致卡住目标，mAP50-95反映框和真实标注的贴合度。打火机这种小目标任务，mAP50 可能到 0.95 但 mAP50-95 只有 0.6 左右，这是正常的，不用焦虑。

6. 验证成果：坏图排查、置信度阈值调优与模型导出

6.1 训练完跑一遍坏图排查脚本

训练完成后还要做一件事：用训练好的模型跑前 100 张验证图，把置信度低于某个阈值的预测结果挑出来人工看。很多问题在这个环节才会暴露，比如某些打火机类型因为样本太少，模型输出置信度普遍只有 0.3 到 0.4，阈值设太高直接全滤掉了。我一般的做法是：

from ultralytics import YOLO import cv2 model = YOLO('runs/detect/train/weights/best.pt') results = model.predict('images/val', conf=0.1, save=True) low_conf_files = [] for r in results: boxes = r.boxes for b in boxes: if b.conf.item() < 0.3: low_conf_files.append(r.path) print('低置信度文件数量:', len(low_conf_files))

这轮排查的目标是找出「模型大概率没学会」的图片，而不是找漏检。conf=0.1把阈值压低，让模型把不确定的结果也吐出来，这样才能看到哪些目标是被压线漏掉的。跑完后用save=True生成的图片逐张翻一下，把经常出现低置信度的图片挑出来，看是光照问题还是标注问题。

6.2 置信度阈值不是越高越好

很多人在验证时喜欢把置信度阈值调到 0.7 甚至 0.8，结果误检率降了、召回率崩了。打火机识别场景里，漏检的代价比误检高得多。做安监场景，一个漏检的打火机可能直接造成风险事件；做电商巡检，漏检意味着违规商品流出。所以生产环境应该用阈值扫描的方法确定最优值。

yolo val model=runs/detect/train/weights/best.pt data=data.yaml conf=0.25 yolo val model=runs/detect/train/weights/best.pt data=data.yaml conf=0.1

跑不同阈值下的验证结果，对比 precision 和 recall 的变化。你会发现 recall 从 0.9 跌到 0.8 时，precision 可能只涨了 1 个百分点，说明提高阈值得不偿失。工业落地时我的习惯是：默认阈值 0.25，对外输出结果再加一个「低置信度截图留存」的逻辑，宁可在人工复核时多看几十张图，不让漏检悄悄溜过去。

6.3 导出 ONNX 格式做实际部署

训练完的模型权重不能直接进生产链路，一般导出 ONNX 做推理加速或接入服务。导出命令很简单，但有一个参数值得注意。

yolo export model=runs/detect/train/weights/best.pt format=onnx imgsz=640 simplify=True

simplify=True会让 ONNX 图做一轮常量折叠，去掉冗余算子，推理速度提升明显。导出后建议用onnxruntime跑一次，对比 PyTorch 的输出结果，误差大于 1e-3 就说明导出有问题。从那以后我每次导出完都会把 PyTorch 和 ONNX 的推理结果拿 numpy 对比一遍，这个习惯救了我好几次——有一次就是因为 batch 维度写死，ONNX 输出和 PyTorch 结果完全对不上，排查了半天才发现是导出时imgsz和训练尺寸不一致。这套流程走完，打火机识别模型的训练、验证、部署链路就闭环了，希望帮到你。

本文还有配套的精品资源，点击获取