简介：面向安检场景的EDS X光危险物品识别检测数据集，共4718张图片，适用于机场、火车站智能安检及智能安防项目，可帮助算法工程师快速验证与迭代目标检测模型。数据集涵盖笔记本电脑、手机平板、打火机、剪刀、压力罐、充电宝、雨伞、玻璃瓶、塑料瓶、刀具等10类常见违禁物品，标注精确，数据量充足，多种检测算法可直接使用。压缩包共14155个文件，其中4718张jpg原图对应4718个xml（VOC格式）与4719个txt（YOLO格式），同时提供json标签，满足不同训练框架的数据导入需求，包体约499.67MB，目录结构清晰。已有1547人学习下载，该数据集源于实际安检落地项目，算法拟合效果好，数据质量可靠，适合从事智能安防、目标检测研究的学生和工程师用于模型训练、效果评估与算法优化。
1. EDS-安检X光危险物品识别检测数据集：安检场景为什么缺的正是这一份
做安检X光危险品检测最难的不是模型选型，而是找不到像样的训练数据。X光图像和自然图像差异很大：物体相互叠压、颜色单调、透视重叠，直接拿COCO预训练权重往下套，效果常常一言难尽。EDS-安检X光危险物品识别检测数据集正好补了这个缺口，4718张安检X光场景图像，配上VOC、YOLO、JSON三种格式的标签文件，覆盖常见危险物品类别。对要快速验证检测算法或做安检场景定制化训练的工程师来说，这份数据能从数据集准备阶段直接跳到模型训练阶段，省掉大量标注和格式转换的时间。新手拿来学YOLO训练流程，熟手拿来当迁移学习或格式转换的试验场，都比较顺手。
2. 三种标签格式结构拆解：VOC、YOLO、JSON的边界与选型
拿到数据集先别急着训练，把三种格式各自的结构和边界搞清楚，后面能少走很多弯路。VOC、YOLO、JSON虽然描述的是同一批标注信息，但组织方式和适用框架完全不同。
2.1 VOC：一个XML文件，描述一张图像的全部标注信息
VOC（Pascal VOC）是目标检测生态里最通用的数据组织方式之一，特点是一张图对应一个同名XML文件。在EDS-安检X光数据集中，每张X光图像的标注内容都记录在XML里，包括图片尺寸、目标类别，以及 节点下的四个坐标。
一个典型XML标注长这样：
<annotation> <folder>EDS</folder> <filename>img_0047.jpg</filename> <size> <width>1024</width> <height>768</height> <depth>3</depth> </size> <object> <name>gun</name> <pose>Unspecified</pose> <truncated>0</truncated> <difficult>0</difficult> <bndbox> <xmin>290</xmin> <ymin>210</ymin> <xmax>520</xmax> <ymax>430</ymax> </bndbox> </object> <object> <name>knife</name> <bndbox> <xmin>180</xmin> <ymin>330</ymin> <xmax>350</xmax> <ymax>490</ymax> </bndbox> </object> </annotation>里的四组坐标是图像像素绝对值， 是类别名字符串，正好是检测算法最需要的原始信息。VOC的优点在于坐标直观，人工复核方便，配合labelImg打开XML还能直接回改标注；缺点是一张图一个文件，批量解析速度比YOLO的TXT慢，做数据统计也不方便。
读取VOC标注时，常用的是Python标准库xml.etree.ElementTree，按节点逐层取值。需要注意的是 坐标范围是闭区间还是开区间。多数标注工具按闭区间存，xmin=90、xmax=120时实际占用像素是90到119。做归一化转换时按xmax-xmin计算宽度会多算1个像素，对640分辨率来说误差约0.0016，虽然不影响训练，但在做像素级裁剪或拼接验证时，这1像素偏差会让边界出现肉眼可见的不对齐。我一般会在转换代码里统一按xmax-xmin计算宽度，保证VOC转YOLO和YOLO转VOC用同一套规则，避免来回转换导致边界漂移。
2.2 YOLO：一行文本一个目标，训练读取效率最高
YOLO格式是YOLOv5、YOLOv8、YOLOv9这些框架训练时最顺手的格式。EDS数据集里，YOLO格式的TXT文件和图像同名，每一行代表一个目标，格式为“类别序号 中心x 中心y 宽度 高度”，四个坐标全部相对图像宽高做了归一化，取值范围在0到1之间。
例如2.1里那张图，对应的YOLO标注是两行：
0 0.403 0.417 0.225 0.286 1 0.259 0.534 0.166 0.208第一列类别序号由data.yaml里的names列表决定，后面四列分别是x_center、y_center、w、h。和VOC比，YOLO格式文件小、读取快，训练代码拿到就能用，不需要解析XML再换算坐标。但缺点也明显：坐标是归一化浮点数，人工核对不好读；类别只有数字没有文字，一旦names顺序写错，整份标注全乱且不报错。
YOLO格式的TXT对编码也比较敏感，遇到中文系统默认的GBK写入容易乱码，建议保存时统一指定UTF-8。另一个细节是TXT文件不要带BOM头，Ultralytics在读取带BOM的TXT时偶尔会把第一列解析错，现象是第一个目标的类别序号异常。检查方法很简单：用Python的open(..., 'rb')读一下文件头三个字节，出现EF BB BF就说明带BOM，存盘时用encoding='utf-8'且不写BOM重新保存即可。
2.3 JSON：COCO风格的annotations数组，集中管理全部标注信息
JSON格式是COCO数据集原生的标注结构，在Faster R-CNN、Mask R-CNN、DETR以及mmdetection这类框架里最常见。它不像VOC那样一张图一个XML，而是把整个数据集的图像信息、标注信息、类别信息集中到一个文件里，大概结构如下：
{ "images": [ {"id": 1, "file_name": "img_0047.jpg", "width": 1024, "height": 768} ], "annotations": [ {"id": 1, "image_id": 1, "category_id": 1, "bbox": [290, 210, 230, 220], "area": 50600} ], "categories": [ {"id": 1, "name": "gun"}, {"id": 2, "name": "knife"} ] }三个数组各有分工：images记录图像id和真实尺寸，annotations记录每个目标从属于哪张图、类别id、bbox和面积，categories定义类别映射。用pycocotools计算mAP时，这种格式是直接对接的，不需要额外写转换器。
比较关键的是COCO的bbox是[x, y, width, height]，而VOC的bndbox是[xmin, ymin, xmax, ymax]，一个是“起点加宽高”，一个是“对角点”。做互转时不注意这个差异，坐标就会整体错位。另外area字段在COCO评估时会直接使用，如果转换时area算错，mAP计算结果会异常但不会报错，这种隐性错误很难排查。我一般会在转换后重新按bbox计算area覆盖写回，不用原标注里的值。
2.4 选格式的实用标准：先看训练框架，再看前后处理
三种格式各有适用场景，一上来就全部统一成一种格式反而给自己挖坑。我的取舍逻辑有三条线。
训练YOLOv5、YOLOv8、YOLOv9系列时，直接用YOLO格式目录，不需要碰XML和JSON。准备用mmdetection或其他带COCO接口的框架时，用JSON格式最省事，因为框架自带的CocoDataset就是读这个格式。VOC格式则用来做原始标注保存和人工复核，尤其是需要二次修标注、标注团队交接的场景，VOC的可读性最有价值。
所以我的习惯是三份都留着：VOC当唯一原始标注源，YOLO当训练主格式，JSON当评估与迁移格式。后面做格式互转时也建议以VOC为转出源头，而不是YOLO和JSON之间直接互转，避免两套转换逻辑不一致导致的双向误差。
3. 用YOLO格式训练安检模型：目录整理、data.yaml和必调参数
这一章直接落到YOLO训练。4718张图的数据量不大，但足够走完一轮完整的训练、验证、调参流程。前提是目录结构、类别配置和训练参数别出岔子。
3.1 按YOLO习惯整理数据集目录
YOLOv5/8/9的默认约定是images目录放图片、labels目录放TXT标签，各自再按train和val分成两个子集。EDS数据集拿到手后，先按这个习惯规整目录：
dataset/ ├── images/ │ ├── train/ │ │ ├── img_0001.jpg │ │ └── ... │ └── val/ │ ├── img_0045.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── img_0001.txt │ │ └── ... │ └── val/ │ ├── img_0045.txt │ └── ... └── data.yaml如果原始目录不是这个结构，写个脚本按比例拆分。4718张按8:2分，大约3775张训练、943张验证，足够支撑一轮完整实验。我常用的拆分脚本长这样：
import os import random import shutil random.seed(42) img_src = 'raw_images' # 原始图片目录 label_src = 'raw_labels' # 原始TXT标签目录 out_root = 'dataset' split_ratio = 0.8 images = [f for f in os.listdir(img_src) if f.endswith('.jpg')] random.shuffle(images) split_idx = int(len(images) * split_ratio) for phase, subset in [('train', images[:split_idx]), ('val', images[split_idx:])]: os.makedirs(f'{out_root}/images/{phase}', exist_ok=True) os.makedirs(f'{out_root}/labels/{phase}', exist_ok=True) for img in subset: txt = img.replace('.jpg', '.txt') shutil.copy(os.path.join(img_src, img), f'{out_root}/images/{phase}/{img}') # 关键：用同名替换生成txt路径，保证jpg和txt永远一起走 shutil.copy(os.path.join(label_src, txt), f'{out_root}/labels/{phase}/{txt}')拆分逻辑的核心是：先对全部图片名单做shuffle，再按同一份名单复制图片和标签。txt路径用jpg名单replace后缀得到，从机制上避免图片标签顺序错位。random.seed(42)保证每次跑同一个脚本得到完全相同的拆分结果，复现实验时很重要。
还有个细节：数据集里如果存在没有标注文件的图片，上面的脚本直接复制会报错。写正式流程前最好加一个os.path.exists判断，把没有对应txt的图片单独挑出来，否则训练时会遇到“孤儿图片”，报错样式多种多样，不好排查。
注意：拆分完成后跑一条统计命令，对比train/images和train/labels两个目录的文件数，数量不一致就先别训练。
3.2 data.yaml：类别顺序千万别改
YOLO格式训练时，data.yaml承担着把TXT里的数字序号映射为具体类别的职责。一个基本配置如下（类别名以数据集实际标注为准）：
path: ./dataset train: images/train val: images/val nc: 4 names: 0: gun 1: knife 2: bottle 3: explosivekey point是names的顺序必须和TXT文件里的第一列数字严格对应。TXT里的类别序号不是类别名，如果只改names顺序不改TXT内容，训练不会报错但所有框的类别整体错位。更隐蔽的是，如果换了一组类别名但数量不变，loss曲线看起来依然正常，只有混淆矩阵能看出类别互相串位。
检查方法很直接：拆分完成后随机抽几个TXT，把第一列数字在names里查一遍，再对照原图视觉确认类别是否一致。如果是JSON或VOC转过来的YOLO，建议转换脚本里顺便打印一次完整映射表，转换时不打印映射表等于给自己留隐患。
3.3 YOLOv8训练命令：从预训练权重到自训练
用Ultralytics框架训练，最小命令只需要这一条：
pip install ultralytics yolo detect train \ model=yolov8n.pt \ data=dataset/data.yaml \ epochs=100 \ imgsz=640 \ batch=16 \ device=0如果想从零训练、不加载任何预训练权重，把model参数换成yolov8n.yaml：
yolo detect train \ model=yolov8n.yaml \ data=dataset/data.yaml \ epochs=100 \ imgsz=640 \ batch=16建议先用yolov8n.pt做迁移学习。安检X光图像和自然图像差异大，但COCO预训练的基础特征提取能力依然能显著加快收敛。4类目标、4718张图的数据量，用n级模型跑100个epoch，训练成本和推理速度都比较划算；s级模型精度更高但显存需求也大，根据自己显卡情况权衡。
关键参数逐个说：imgsz=640是默认值，如果原图是1024以上，提到768或1024对小目标和密集目标有帮助，但训练时间几乎翻倍。batch先从16试，显存溢出就降到8或4，别硬撑。epochs不建议一上来就调大，先跑100看loss曲线形态再决定加练还是提前收。
X光成像里存在大量半透明叠影和低对比度目标，对分辨率的需求比自然图像更高。如果在val集上频繁漏检小物件，比如刀具的刀刃，第一个该动的是imgsz而不是直接换更大模型。这个顺序调错会浪费很多时间。
3.4 训练结果怎么看：认准best.pt和三条曲线
训练结束后，成果默认落在runs/detect/train/目录下，weights/best.pt和weights/last.pt是两个核心文件。best.pt按验证集指标选取，last.pt是最后一个epoch状态。实际部署优先选best.pt，不要因为last.pt训练loss更低就换它，训练loss低不代表泛化好。
训练过程中重点盯三条曲线：val/box_loss、metrics/precision、metrics/recall。正常节奏是前20到30个epoch快速下降，之后缓慢收敛。如果precision和recall从头到尾抖动不收敛，优先检查两类问题：一是data.yaml类别顺序和TXT不一致，二是train/val拆分时图片和标签走散。
4718张图不算大，但足够检验一个检测模型在安检场景下的基础能力。第一次训练结果如果mAP50能到0.7以上，说明数据质量和训练流程没问题，下一步重点是调参数和扩难例。如果mAP50在0.5以下，基本可以断定存在数据或配置层面的系统性问题，先回头复查前两章的内容，别急着换模型。
4. 三种格式互转的脚本写法与避坑清单
数据集同时提供VOC、YOLO、JSON三种格式，本意是让你直接按需取用。但实际项目里经常会遇到格式不匹配的情况，比如YOLO格式的类别顺序和你的需求不同，或者你想用mmdetection接收JSON但缺几个字段。这一章讲清楚互转脚本怎么写，以及我自己踩过的一堆坑。
4.1 VOC转YOLO：中心点和宽高的换算公式别记反
VOC转YOLO是最高频的需求。VOC里四个值是xmin、ymin、xmax、ymax，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完整转换脚本：
import xml.etree.ElementTree as ET import os xml_dir = 'VOC/xmls' # VOC格式XML目录 txt_dir = 'YOLO/txts' # YOLO格式TXT输出目录 os.makedirs(txt_dir, exist_ok=True) # 类别名到序号映射，按实际数据集的类别定义调整 class_map = { 'gun': 0, 'knife': 1, 'bottle': 2, 'explosive': 3, } def voc_to_yolo(xml_path, txt_path): 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) lines = [] for obj in root.findall('object'): # 注意是findall不是find name = obj.find('name').text if name not in class_map: continue cls_id = class_map[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 w = (xmax - xmin) / img_w h = (ymax - ymin) / img_h lines.append(f"{cls_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}\n") with open(txt_path, 'w', encoding='utf-8') as f: f.writelines(lines) for file in os.listdir(xml_dir): if file.endswith('.xml'): voc_to_yolo( os.path.join(xml_dir, file), os.path.join(txt_dir, file.replace('.xml', '.txt')) )逻辑上重点检查三点：类别映射表是否完整、图片尺寸是否取的真实图像尺寸、输出浮点数精度是否够。6位小数对640分辨率足够，误差在千分之一像素级别；如果只保留3位小数，会在高分辨率训练时造成框的轻微抖动，影响结果复现性。脚本里我特意用了findall而不是find，用find会只取第一个object，转换后TXT行数明显少于XML里的目标总数，这种错误很隐蔽。
4.2 JSON转VOC：category_id和坐标格式是两个不对齐的坑
从COCO风格的JSON向VOC转，最大的坑不是坐标换算，而是category_id的语义。COCO的categories数组id从1开始，VOC里类别名没有数字序号，YOLO的类别序号习惯从0开始。直接把category_id当YOLO类别号用，所有类别统一偏移一位，训练结果全错。
另一个容易错的是把COCO的bbox直接抄进XML。bndbox需要xmin、ymin、xmax、ymax，COCO bbox给的是x、y、width、height，转换时要xmax=x+width、ymax=y+height：
# JSON转VOC的核心片段 for ann in annotations: x, y, w, h = ann['bbox'] xmin, ymin = int(x), int(y) xmax, ymax = int(x + w), int(y + h) cat_id = ann['category_id'] cls_name = categories[cat_id] # categories是id->name的映射字典 # 接下来用cls_name和xmin/ymin/xmax/ymax生成XML节点category_id对齐的做法是转换开始前先把categories数组打印一遍，确认id是从1开始还是从0开始，有没有跳号。很多COCO风格数据集的annotations对象category_id都做了归一化，但也有例外。稳妥做法是把类别表改成以id为key的字典，不要用数组下标访问，这样即使id从200开始也能准确对应类别名。
4.3 JSON转YOLO和YOLO转JSON：归一化和反归一化的基线要一致
数据集同时提供三种格式，意味着你转换时有一个天然的标准答案可以用来校准。比如YOLO转回JSON时，归一化坐标要乘回图像宽高，这里的宽高必须来自images数组里记录的原始尺寸，而不是训练时的resize尺寸。反过来JSON转YOLO时，归一化的除数也要用同一份原始尺寸。
隐藏的坑是：有的X光数据集在导出JSON时，images字段里的width/height记录的是原始大图尺寸，但annotations里的bbox坐标却是基于缩略图标注的。这种情况下直接按images宽高做归一化，出来的YOLO框全部变形。最稳妥的兜底做法是转换后用PIL打开原图核对真实尺寸：
from PIL import Image img = Image.open('path/to/img_0047.jpg') real_w, real_h = img.size如果JSON元数据不可信，就用真实尺寸做归一化。但要注意，如果图像在数据集生成阶段确实被压缩过，且标注是压缩后画的，那用原图尺寸反而不对，这时要以标注时的尺寸为准。判断方法是对照同一张图的VOC标注，如果VOC和YOLO两个坐标系都能和图像内容对齐，说明尺寸选对了；对不齐就说明基准错了。
地面真实情况是，这种“元数据和实际标注脱节”的问题很难提前发现，只能靠转换后再人工抽几张图像核对。省掉这一步，后面训练出了问题都不知道是模型问题还是数据问题。
4.4 转换和训练过程中的6个真实踩坑
前面几节是转换逻辑，这一节把常见现象按“现象→原因→解决”拆开，方便直接对照。
坑1：转换后所有框都不在原位
现象：用转换后的YOLO标注训练，预测框位置整体偏移，看起来每框都画在物体旁边，但文件读取和训练log都正常。
原因：VOC转YOLO时使用了XML里的size做归一化，但XML尺寸和图像实际尺寸不一致，常见于数据集被压缩resize后没同步更新XML。
解决：转换代码里直接读图像文件获取真实尺寸，或至少加断言检查XML里的size和实际图片尺寸一致，不一致就停止转换并打印警告。
坑2：类别全部错位一位
现象：训练不收敛，混淆矩阵中预测类别集中在相邻几个类别上，本来完全不同的两类却经常互相混淆。
原因：JSON的category_id从1开始，YOLO的类别序号从0开始，转换时没有做偏移。
解决：建立显式的id映射字典，转换完成后随机抽3个样本，把TXT里数字查表得到的类别名与原图对照。
坑3：TXT里出现小于0或大于1的坐标
现象：训练日志大量输出warn，部分样本的验证指标异常波动。
原因：标注框本身超出图像边界，或者转换脚本用了错误的尺寸，导致归一化后坐标越界。
解决：转换后加一道clip操作，把坐标限制到[0,1]。同时把越界原始框单独列出来，确认是标注问题还是转换问题。框超出边界不多就手动clip掉，超出很多多半是尺寸用错了。
坑4：train/val拆完发现图片和标签对不上
现象：训练时报大量“No labels found”，验证集标签文件夹几乎是空的，但目录里看文件确实都在。
原因：拆分脚本分别获取了jpg和txt两个列表，各自shuffle后按各自顺序截取，两边文件名没有配对。
解决：拆分逻辑改成以图片为基准，用jpg名replace出txt名，同一循环里移动配对文件。拆分结束后统计train/images和train/labels的文件数，不等就重拆。
坑5：一个XML里多个同类目标，转换后漏掉一部分
现象：转换出来的TXT行数明显小于XML里object节点数量。
原因：转换脚本用了find('object')只取了第一个目标，应该用findall('object')遍历全部。
解决：统一用findall，转换后做计数校验：每个TXT的行数要等于对应XML里的object总数，不等就报错。
坑6：loss掉得很快但mAP一直上不去
现象：val loss低，precision和recall持续偏低，训练曲线看起来很健康。
原因：类别分布严重不均，占多数的类别主导了loss下降，少数类别几乎没学到特征。
解决：先统计每个类别的样本量，对样本少的类别调整cls loss权重或做上采样，也可以用更轻量的模型配合更长epochs训练。
5. 验证模型别只盯着mAP：安检场景的三个额外检查
mAP是评估模型的核心指标，但安检X光危险品检测里只看mAP容易漏掉真实问题。安检图像目标互相遮挡、透明叠影多，模型可能在mAP上表现不错，一到实际图像就频频漏检。建议在模型验证阶段加上三个额外检查项。
第一项是recall优先。安检场景的核心诉求是不漏检，误报可以被复检环节过滤，漏报直接造成安全风险。用验证集画出P-R曲线，找到recall稳定在0.9以上的置信度点做阈值，再评估这个阈值下的precision。如果业务方对误报率高敏感，再加一层二次过滤处理低置信度的false positive。这个取舍逻辑比单纯追求mAP贴近业务实际。
第二项是难例切片验证。从验证集里挑出背包多物品互相重叠、目标密集的图像单独归一个hard子集，专门跑一轮模型验证。这类图像最容易暴露模型短板。如果hard子集上recall跌得厉害，优先尝试提高imgsz或做tile切片推理，这两种做法在小范围子集上可以快速对比，不需要重训整个模型。
第三项是数据闭环。4718张图对安检场景的复杂性来说不算大，跑完第一轮后把验证集里预测失败但置信度高的图像捞出来，二次标注后并回训练集。这样迭代两到三轮的收益，通常会大于调参和换模型结构的收益。
我自己盯这些检查项时，习惯把每一轮的混淆矩阵和hard子集recall单独存档，回看前后改动到底提升在哪。安检场景的模型能不能上线，最终不看单个指标，而是看典型失败样本有没有被一个个消灭。这份EDS-安检X光数据集本身是个合适的试验场，把流程跑通后再切回自己的业务图像，剩下的只是数据适配问题。希望这一路踩坑记录能帮到你。
本文还有配套的精品资源，点击获取
