简介面向机场安检X光图像目标检测研究与YOLO模型训练的数据集适用于计算机视觉学习者、算法工程师及安检智能识别项目开发者。包含706张真实场景下由LabelImg标注的X光安检打火机图像类别统一为lighter。标签同时提供VOC格式xml与YOLO格式txt两套文件分别存放于独立文件夹可直接用于YOLO系列模型训练、验证与格式转换测试省去手动标注与格式整理时间。压缩包共2119个文件除706张jpg原图外另含706个xml标注文件和707个txt标注文件整体大小102.38MB文件命名与目录结构规整便于按需调用。已有979人浏览学习适合需要快速获取高质量X光打火机标注数据、开展安检目标检测实验或进行YOLO算法效果验证的开发者无论用于课程设计、毕业设计还是实际项目预研都能省去数据采集与人工标注的繁琐环节。1. 机场X光安检打火机识别这个YOLO数据集到底能不能直接用X光安检图上找打火机最反直觉的一点是你不能按“外观”去认。金属打火机的砂轮和防风罩在X光下是亮蓝色高亮塑料机身是淡绿色塞进行李里跟钥匙、充电宝、金属水杯混在一起人眼都得盯十几秒。传统图像处理用阈值加形状匹配做这套任务换一台安检机、换一种行李背景噪声就翻车。用YOLO做检测是目前的主流方案但YOLO本身不挑任务它挑数据——有多少张真实场景图、标注格式能不能直接喂进训练脚本。这套“YOLO机场X光安检打火机识别数据集”正好卡在这个需求点上真实X光图片labelimg标注同时给VOC和YOLO两套标签类别只有lighter一个适合做安检智能辅助的目标检测模型也适合拿来做数据集格式转换练习。配合YOLO预训练模型微调能快速验证这条路走不走得通。适合两类人一类是需要快速验证X光目标检测可行性的算法工程师另一类是毕设做安检识别方向、想搞清楚VOC和YOLO格式区别的初学者。2. 数据集解剖双格式标注的目录结构与格式差异2.1 目录结构从一个jpg文件名能读出什么拿到手先看文件命名。像006456301027524.jpg这种其实是安检机保存图像时自动生成的时间戳加设备序号不是标注信息也不代表任何类别。这类数据集常见目录组织方式是图片独占一个目录xml和txt各放一个目录文件名和图片保持一致前缀。. ├── images/ │ ├── 000132801015113.jpg │ ├── 001957501015060.jpg │ └── ... ├── xml/ │ ├── 000132801015113.xml │ └── ... ├── txt/ │ ├── 000132801015113.txt │ └── ... └── class.txt关键点是文件名前缀完全对齐。训练脚本是按前缀找对应标注文件的少了任何一个装载数据时就会报“no labels found”。这种以图片名为唯一关联键的设计在YOLO生态里是硬约定改错一个字母等于那张图白标。这张数据集的图片格式是jpg来源是真实安检机的X光成像不是网上随意抓的可见光图。X光图的特点是物体之间高度重叠金属和有机物密度差异大灰度动态范围宽这些都会直接影响标注质量和对后续训练结果的理解。2.2 VOC格式xml里到底存了什么labelimg默认保存成VOC格式的xml文件也就是Pascal VOC标准。抽出一个标注文件的内部结构annotation folderimages/folder filename000132801015113.jpg/filename size width1024/width height768/height depth3/depth /size object namelighter/name poseUnspecified/pose truncated0/truncated difficult0/difficult bndbox xmin312/xmin ymin209/ymin xmax356/xmax ymax268/ymax /bndbox /object /annotation这里最关键的三点第一size里的width和height必须与图片真实尺寸一致不一致的话转YOLO格式时归一化坐标全错第二object节点下的name是类别名类名统一写lighter不能一会儿lighter一会儿Lighter第三bndbox给的是左上角和右下角的绝对值像素坐标。如果一张图里有多个打火机xml里就会出现多个object节点。VOC格式的优点是可读性强、信息完整difficult和truncated标记都保留着做数据清洗时可以根据这些属性过滤难例。2.3 YOLO格式txt里的五个数意味着什么YOLO格式的txt标注每一行代表一个目标0 0.325683 0.310547 0.042968 0.076822五个数依次是类别id、目标中心点x坐标、目标中心点y坐标、目标宽度w、目标高度h。后四个都是归一化后的比例值取值范围0到1。计算方式是x_center等于xmin加xmax除以2再除以图片宽度w等于xmax减xmin除以图片宽度。这种归一化设计是为了让模型不依赖输入图片的绝对分辨率所以YOLO训练时不管把图resize到640还是1280标注都不需要重新计算。类别id从0开始这个数据集只有lighter一个类txt里的行首基本全是0。如果你打开class.txt发现里面不止一行就得留意id映射关系是否跟你训练时用的yaml保持一致。2.4 为什么同时给两套标注从使用角度说这个数据集的作者把VOC和YOLO两套格式都保留下来省掉了用户最痛苦的第一道工序。常见做法是训练脚本直接读YOLO的txt因为ultralytics YOLOv8和YOLOv5默认吃的就是这种格式而做可视化检查、数据增强或转COCO json时VOC的xml信息更完整。这份资源相当于给了你一个标准中间态图片、xml、txt三件套对齐想走哪条路线都不用先造轮子。对只想跑通YOLO训练的人来说直接可用对想改造数据的人也有一个干净的起点。3. VOC转YOLO格式一套脚本解决标注转换与归一化3.1 什么时候需要自己转虽然数据集已经给了txt但实际项目里你很可能要局部修改标注比如重新补标漏检的打火机这时labelimg存出来的又是xml。另一种情况是你拿到另一个只有VOC标注的X光数据集要合并进这个项目一起训练总不能手算归一化坐标。我把这个转换脚本固定下来以后拿到任何VOC格式的安检图都能直接跑。这里还有一层原因生成txt的过程本身就暴露数据质量问题比如size字段异常、坐标超出图像边界、类别名拼写不一致很多坑在转换阶段就会现形。3.2 转换脚本与目录约定import os import xml.etree.ElementTree as ET # 配置区 xml_dir ./Annotations # 存放xml文件的目录 out_dir ./labels # 输出的txt目录不存在会自动创建 class_names [lighter] # 类别清单顺序决定id os.makedirs(out_dir, exist_okTrue) def convert_one(xml_path, txt_path): tree ET.parse(xml_path) root tree.getroot() size root.find(size) width int(size.find(width).text) height int(size.find(height).text) 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) 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) # 防御性处理坐标可能被标反 if xmin xmax: xmin, xmax xmax, xmin if ymin ymax: ymin, ymax ymax, ymin x_center (xmin xmax) / 2.0 / width y_center (ymin ymax) / 2.0 / height w (xmax - xmin) / width h (ymax - ymin) / height # 归一化后越界钳制防止边界目标损坏标注 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(txt_path, w) as f: f.write(\n.join(lines)) for xml_name in os.listdir(xml_dir): if not xml_name.endswith(.xml): continue xml_path os.path.join(xml_dir, xml_name) txt_name xml_name.replace(.xml, .txt) txt_path os.path.join(out_dir, txt_name) convert_one(xml_path, txt_path) print(fconverted {xml_name}) print(done)逻辑说明脚本遍历Annotations目录下所有xml逐个解析出size和每个object的bndbox先防御性地纠正标反的坐标再按公式做归一化最后按“class x_center y_center w h”格式写入txt。参数说明class_names列表的顺序就是类别id的定义顺序必须跟你训练时用的yaml文件保持一致。如果以后新增一个类比如lighter_flame就追加到列表尾部前面类的id不要变动否则旧标注的id全部错位。xml解析用的是Python标准库不需要额外安装第三方包。整个转换过程理论上无损唯一丢的信息是xml里的difficult和truncated标记YOLO格式不支持丢了不影响训练。3.3 转换完怎么验证转换完先别急着训练用可视化脚本验一遍才是正经事。import cv2 img_path images/000132801015113.jpg txt_path labels/000132801015113.txt img cv2.imread(img_path) height, width img.shape[:2] color (0, 255, 0) for line in open(txt_path): parts line.strip().split() cls_id, x, y, w, h map(float, parts) x1 int((x - w / 2) * width) y1 int((y - h / 2) * height) x2 int((x w / 2) * width) y2 int((y h / 2) * height) cv2.rectangle(img, (x1, y1), (x2, y2), color, 2) cv2.imwrite(check.jpg, img)这段代码把txt里的归一化坐标还原成像素坐标画框。如果框和打火机轮廓明显对不上先反过来查xml的size和图片真实尺寸是否一致。我自己踩过一次坑合并另一个VOC数据集时跑完转换不做验证结果每个框都偏离真值一大截查了半天发现那个xml里的size节点被标注工具写成了0归一化计算直接失控。从那以后转换完第一件事永远是抽三张图画框再谈训练。4. 用YOLOv8训练打火机检测从切分数据到损失函数调优4.1 数据切分与yaml配置拿到这个数据集第一件事是切分train和val并确认每个子集都有对应的标注文件。常见做法是纯随机切分但安检场景里同一个行李包可能有多张连续帧如果这些图同时出现在训练集和验证集模型会“记住”包内特征造成指标虚高。这个数据集文件名的连续性不强先用随机切分跑通流程没问题后续如果发现val mAP偏高而实际效果差再按包分组重切。import os import random images [f for f in os.listdir(images) if f.endswith(.jpg)] random.seed(42) random.shuffle(images) train_ratio 0.8 split int(len(images) * train_ratio) train_list images[:split] val_list images[split:] os.makedirs(train/images, exist_okTrue) os.makedirs(train/labels, exist_okTrue) os.makedirs(val/images, exist_okTrue) os.makedirs(val/labels, exist_okTrue) for name in train_list: os.rename(fimages/{name}, ftrain/images/{name}) os.rename(flabels/{name.replace(.jpg, .txt)}, ftrain/labels/{name.replace(.jpg, .txt)}) for name in val_list: os.rename(fimages/{name}, fval/images/{name}) os.rename(flabels/{name.replace(.jpg, .txt)}, fval/labels/{name.replace(.jpg, .txt)})然后写data.yamlpath: . train: train/images val: val/images names: 0: lighter这个yaml给ultralytics YOLOv8用path是项目根目录train和val给的是相对path的图片目录。模型会自动到同级labels目录找txt。如果你的标注还是xml训练时就会报读不到标签所以转换那一步不能省。names字段的顺序和id必须严格对应txt行首的数字这里只有0对应lighter。4.2 预训练模型选择与训练命令训练前要决定用哪个yolo预训练模型。yolov8n参数量最小适合快速验证数据集能不能被网络吸收特征yolov8s精度高一截但速度掉一点对X光这种单类小目标场景我一般先用yolov8n跑通再切yolov8s或yolov8m提升召回。不要一上来就上yolov8x训练时间成倍涨对小目标检测的收益却很有限。这是安检场景的数据量和目标尺寸结构决定的不是模型越重越好。yolo detect train \ datadata.yaml \ modelyolov8n.pt \ epochs100 \ imgsz1280 \ batch16 \ lr00.005 \ patience10 \ save_period10 \ projectruns/detect \ namelighter_xray参数说明imgsz设1280是刻意为之。安检机原图常见在1280x768上下打火机可能只占几十个像素resize到640后特征在骨干网络下采样阶段就可能消失。拉到1280能保住小目标细节代价是显存和训练时长明显上升显存不够降到960或640但要接受漏检率上升。lr0压到0.005而不是默认0.01因为X光灰度分布和ImageNet差太远预训练权重里的纹理特征基本用不上学习率太大会导致收敛不稳甚至出现训练loss震荡。patience10表示验证指标连续10轮不升就早停save_period10表示每10轮存一版权重避免电脑断电白跑。训练完成后看runs/detect/lighter_xray目录weights里有best.pt和last.pt。训练中如果发现loss曲线在第10轮附近震荡不降优先怀疑batch太小导致BN统计不稳定这在yolov8里很常见现象就是BN崩溃、loss突然变nan解决方法是把batch从8提到16或者把lr0再降一半。4.3 损失函数与过拟合判断YOLOv8默认的检测头包含分类损失、DFL和CIoU。DFL负责回归边界框分布CIoU让预测框和真实框的重合度更高。对打火机这种小目标任务默认损失函数基本不用改真正要盯的是训练日志里的box_loss和cls_loss。如果cls_loss降到0.01以下但val的mAP50还徘徊在0.5左右说明分类语义已经学到位问题出在定位精度——检查标注框是不是包得太紧把打火机的砂轮和机身裁掉了一半或者打火机在行李里被其他物体严重遮挡GT框之间重叠度高导致模型不知道该守哪个。X光图里物体叠放是常态一个打火机可能和充电宝、金属水杯在投影方向上完全重叠这在自然图像数据集里很少见。所以训练过程中如果发现mAP50不低但mAP50-95低多半是框定位不准别急着改损失函数先去可视化几批标注看看GT框是不是在打火机轮廓上框都画歪的话什么损失函数都救不回来。5. 实战避坑排查训练失控、小目标漏检与类别对齐5.1 训练loss变NaNBN崩溃与学习率过高现象训练跑到第20多轮loss突然变成nan然后所有指标全线飘红训练日志里inf和nan刷屏。原因一是学习率过高lr0默认0.01在安检灰度图上瞬时梯度太大二是batch太小BN统计量在每步之间的抖动过大陷入BN崩溃三是labels目录里混进了空txt文件空文件本身不报错但会让该图的分类分支损失计算异常累积到一定程度触发数值溢出。解决先把lr0从0.01降到0.002batch提到16以上。如果还在崩停掉训练检查labels目录里有没有size为0的空文件有就删掉或补标。修改后重开训练用last.pt不是为了省时间而是确认崩溃前学到的特征没有白费。5.2 mAP50不低但肉眼漏检小目标与resize的矛盾现象验证集mAP50有0.72单张含打火机的图测试模型就是不出框换个角度拍又出了。原因mAP是平均指标验证集里大尺寸目标的贡献会盖过小目标的失败。打火机在行李箱里往往只有指甲盖大小原图1280宽的情况下目标高度可能只有30像素resize到640后只剩十几个像素骨干网络连续下采样后特征彻底消失。解决训练和推理都用imgsz1280不能再低。显存不够的机器先试试把batch从16降到8而不是降分辨率。更进一步的做法是把原图按左右切分成两块分别推理再合并结果X光图是横向长条形左右切比上下切更合理切分重叠带保留20像素避免目标正好卡在切缝上。5.3 训练一切正常但整个类mAP为0类别名与id错位现象训练能跑loss能降最后的mAP50-95是0Class Index 0指标全空但训练日志里每轮的图片数量都正常。原因yaml里写了names: [Lighter]而标注txt里是lighter首字母大小写不一致时ultralytics不一定报错会在类别映射时全部错位。或者xml转txt时class_names列表的排序和yaml里的names顺序不一致导致id对应到根本不存在的类。解决训练前随机抽三张图跑可视化脚本确认txt行首是0、框位置正确。再小batch训10个epoch看第一轮的mAP有没有从0开始往上走。这是最便宜的验证方式十分钟能筛掉八成标注对齐问题。5.4 验证集效果好、换上真实安检机图片就翻车现象训练验证都正常部署到安检机现场误检率高得吓人背景里的螺丝刀、钥匙扣被成片框成lighter。原因现场设备输出的图像不是训练集的jpg安检机往往输出12bit深度灰度流带背板反光和不均匀亮度和训练数据里jpg经转换后的灰度分布完全不同。模型等于换了一个推理数据分布之前学的背景纹理特征全部失效。解决训练阶段把jpg统一转成三通道灰度输入不要保留原彩色图里的颜色信息——X光机的伪彩本身不稳定。推理时同样把灰度流转成三通道等长输入归一化的均值和标准差与训练时保持一致。更严格的做法是采集目标安检机的灰度直方图在训练集上做灰度抖动增强让模型对亮度漂移不敏感。这属于部署前必须做的适配动作不是模型能做好的事。6. 从混淆矩阵到模型量化部署前的最后一千米6.1 用混淆矩阵定位误检训练结束后YOLOv8会在runs/detect/lighter_xray/下生成confusion_matrix.png这是判断模型能不能真正上线而不是只在指标上好看的第一份证据。打火机这类单类任务混淆矩阵里最该关心的是background这一列如果大量真实目标被识别成lighter同时background那一列也有不少被误判成lighter说明模型学会了响应金属边缘的高亮特征但没学会区分打火机轮廓和其他金属的强反射。此时补负样本——收集不包含打火机的普通行李X光图——比调损失函数更直接有效。6.2 导出ONNX做INT8量化部署安检机工控机普遍没有高性能显卡推理主要靠CPU。我一般把best.pt导出成onnx再用openvino做INT8量化命令如下yolo export modelruns/detect/lighter_xray/weights/best.pt formatonnx imgsz1280导出后检查输出层的三个输出头shape是否正确然后用openvino的benchmark tool跑一轮延迟看单图耗时是否满足安检过包速度。如果延迟超标先把导出imgsz降到960压缩计算量同时尽量保住小目标还不行就退回yolov8n权重重新量一遍这一步往往能把推理时间压到可接受区间。INT8量化对精度的影响在单类小目标任务上通常只有2到3个点的mAP损失但由于分布已经稳定效果可以接受。从那以后我每次拿到任何目标检测数据集都强制先跑一遍可视化检查txt与图片对齐再训10轮验证指标不为0这两步已经成为固定动作能在十分钟内筛掉八成标注质量问题。希望帮到你。本文还有配套的精品资源点击获取