简介：面向工业质检、目标检测入门及毕设场景的易拉罐底部缺陷检测数据集，包含1122张标注图片与3308个真实标注框，覆盖FB、can、hole、scratch、stamped共5个类别，可用于训练缺陷分类与定位模型。数据同时提供Pascal VOC和YOLO两种格式，xml与txt标注一一对应，借助labelImg完成矩形框标注，便于直接接入主流检测框架。资源共2000个文件，含1122个xml、878个txt，整体约45.77MB。图片部分由原始样本增强得到，适合做数据增广对比实验，也可作为制造质检类课程设计或论文验证的数据基础。已有165人学习使用，适合希望快速获取工业质检标注数据并开展YOLO/VOC训练的开发者与研究人员。
1. 这包数据到底解决什么：从「分拣线上的黑匣子」说起
我跟产线自动化的人聊缺陷检测，最常听到的一句话是「模型效果不行」。但真到现场一看，很多项目根本轮不到模型出场：标注格式没对齐、类别分布没看过、训练数据里混着大量无效样本。这包 1122 张、VOC+YOLO 双格式、5 个类别的易拉罐底部缺陷检测数据集，解决的正是「从数据到可训练」这段路。它适合两类人：一是要做罐体质检方案但手头缺标注样本的工程师，二是在 YOLO 上练手、想跑通「数据集→训练→评估」全流程的学生。下面我不打算讲这个数据集多「标准」，而是按我拿到这类压缩包后的真实动作走一遍：先解开它、读懂它，再把它喂给模型。
2. 先看清货架：1122张图的构成与类别分布决定了你的验收标准
拿到.7z别急着解压就开训。缺陷检测项目里，数据整理的耗时经常超过模型训练本身。我一般先把压缩包当成一个「黑匣子」做三件事：校验完整性、看目录结构、统计类别分布。这三步做完，你对这个数据集能不能用、用在哪、上限在哪，基本就有数了。
2.1 解压前先确认压缩包状态：7z 校验与三种平台的解压姿势
Linux 服务器是训模型的常态环境，先确认7z命令在不在：
# Debian/Ubuntu 安装 p7zip；CentOS/RHEL 用 yum install p7zip which 7z || sudo apt install p7zip-full -y # 测试压缩包完整性，不解压，只读 CRC 校验 7z t 易拉罐底部缺陷检测数据集VOC+YOLO格式1122张5类别.7z # 解压到指定目录，避免文件散落一地 7z x 易拉罐底部缺陷检测数据集VOC+YOLO格式1122张5类别.7z -o./can_defect_data/7z t这一步容易被跳过，但它能提前暴露「压缩包传了一半」「分卷缺失」这类问题。解压后我还习惯跑一句du -sh can_defect_data/，看实际体积和压缩包规模是否对得上；如果目录体积小得反常，说明解压中途失败或压缩包本身不完整。Windows 上我一般用 7-Zip 或 Bandizip，macOS 用 p7zip，右键解压虽然省事，但遇到文件名编码问题时会直接翻车，后面第 5 章专门讲。
解压完先看顶层结构。这类双格式数据集常见的布局是：
VOC/下面按Annotations/、JPEGImages/、ImageSets/Main/组织，xml 是标注，jpg 是原图；YOLO/下面按images/和labels/分目录，labels 里是class_id x_center y_center w h格式的 txt；- 也可能有一个
classes.txt或names.txt告诉你 5 个类各自的名字。
如果压缩包里两类目录都有，先确认图片是不是同一份、标注是不是一一对应，别出现「VOC 里有 50 张图但 YOLO 的 labels 里没有对应 txt」这种错位。
2.2 统计 5 类缺陷的分布：先读标注再谈训练
打开 VOC 的 Annotations 目录，用一段短脚本把 5 个类别的样本量统计出来：
import xml.etree.ElementTree as ET from collections import Counter from pathlib import Path xml_dir = Path("VOC/Annotations") counter = Counter() empty_xml = 0 for xml_path in xml_dir.glob("*.xml"): root = ET.parse(xml_path).getroot() names = [obj.find("name").text for obj in root.iter("object")] if not names: empty_xml += 1 counter.update(names) print("类别分布:", dict(counter)) print("无标注的 xml 数量:", empty_xml)这段脚本做了两件事：统计每个类别一共出现在多少张图里，同时找出完全没有目标的 xml。后者很重要——如果 1122 张图里有几十张是「干净罐底」负样本，YOLO 能把它们当背景训练，这是好事；但如果空标注 xml 是上游导出的脏数据，就要在训练前单独处理。
5 个类别具体是什么，以解压后的classes.txt为准。按罐体质检的常见分法，底部缺陷一般落在拉环区域异常、罐底划伤、凹痕变形、污渍锈斑、边缘毛刺这几类里。统计完你立刻会面对一个现实：缺陷检测数据集的类别分布几乎不可能均匀，某类可能只有几十张。对 1122 张规模来说，少于 50 张的类别在训练时基本属于「陪跑」，后面要靠数据增强或接受漏检来兜底。
我还会顺手查一下标注框的面积分布。方法是遍历 xml 里每个 bndbox，算(x2-x1)*(y2-y1) / (图宽*图高)。缺陷标注的正常情况是小框居多、占图面积比在 5% 以下；如果发现大量框占图面积 50% 以上，多半是标注员把整个罐底圈进去了，这种「虚标」对损失函数的污染比漏标还大。发现问题后我会用 OpenCV 把这些可疑图的标注框画出来逐张看，确认是标注习惯问题还是真实缺陷形态，再决定要不要修标注。
3. 把 VOC 转成 YOLO：转换脚本与四个边界坑
数据集虽然标了「VOC+YOLO 格式」，我拿到手仍然会自己重转一遍。原因很朴素：上游导出的标注不一定可靠，格式转换里出的错最隐蔽，而且我经常需要把 1122 张重新按 train/val 划分，沿用别人分好的文件列表不如自己控制随机种子更安心。转换脚本逻辑不复杂，但四个边界坑踩中一个，训练时 Loss 就乱了。
3.1 最小可用的 VOC 转 YOLO 脚本
把 VOC 的 xml 转成 YOLO 的 txt，核心是坐标归一化：
import xml.etree.ElementTree as ET from pathlib import Path # class_names 的顺序必须和后续 data.yaml 里的 names 完全一致 class_names = ["tear", "scratch", "dent", "stain", "burr"] def convert_one(xml_path: Path, img_dir: Path, out_dir: Path): tree = ET.parse(xml_path) root = tree.getroot() img_name = root.find("filename").text img_path = img_dir / img_name if not img_path.exists(): print(f"[跳过] 图片不存在: {img_path}") return img_w = float(root.find("size/width").text) img_h = float(root.find("size/height").text) lines = [] for obj in root.iter("object"): name = obj.find("name").text if name not in class_names: continue cls_id = class_names.index(name) box = obj.find("bndbox") x1 = float(box.find("xmin").text) y1 = float(box.find("ymin").text) x2 = float(box.find("xmax").text) y2 = float(box.find("ymax").text) # 归一化到 [0, 1]；宽高非正数的脏框直接丢弃 bw, bh = x2 - x1, y2 - y1 if bw <= 0 or bh <= 0: continue x_c = ((x1 + x2) / 2) / img_w y_c = ((y1 + y2) / 2) / img_h w = bw / img_w h = bh / img_h lines.append(f"{cls_id} {x_c:.6f} {y_c:.6f} {w:.6f} {h:.6f}") out_path = out_dir / (xml_path.stem + ".txt") out_path.write_text("\n".join(lines), encoding="utf-8") # 用法：遍历 VOC/Annotations 下所有 xml xml_dir = Path("VOC/Annotations") img_dir = Path("VOC/JPEGImages") out_dir = Path("yolo_labels") out_dir.mkdir(exist_ok=True) for xml_file in sorted(xml_dir.glob("*.xml")): convert_one(xml_file, img_dir, out_dir)逻辑上就三步：把 xml 里的像素坐标读出来，换成相对图片宽高的中心点坐标，按class_id x_center y_center w h写进 txt。参数上有两个容易错的地方：class_names列表的顺序决定了类别数字编号，必须和后面训练时data.yaml里的names顺序一致，否则模型学的「1 号类」和你以为的「1 号类」不是同一个缺陷；坐标保留 6 位小数足够，工业标注本身就有像素级误差，写太多位没有意义。
3.2 四个边界坑：除零、空标注、类别错位、路径漂移
第一个坑是除零。有些 xml 的 width 或 height 字段是 0，或者 bndbox 的 xmin/xmax 相等导致宽高为 0。转换脚本里我加了bw <= 0 or bh <= 0的过滤，但更稳的做法是在开头加断言，把异常 xml 单独列出来人工看，而不是静默跳过。
第二个坑是空标注。VOC 里允许存在没有 object 的 xml，转换脚本要正常输出一个空 txt 文件，而不是报错中断。空 txt 对 YOLO 来说代表「这张图没有目标」，训练时会作为纯背景参与损失计算。如果你直接跳过空 xml，YOLO 会认为这张图没有对应标签，训练时自动忽略它，样本数就对不上了。
第三个坑是类别错位。VOC 的 xml 里存的是缺陷名字符串，转成数字编号时靠class_names.index(name)——一旦class_names列表顺序和训练配置不一致，比如scratch是第 2 类但你写成了第 1 类，训练出来的模型判断全是错的，而且 Loss 曲线看起来还挺正常。这是最隐蔽的错位，排查成本极高。我的习惯是转完后随机挑 5 个 txt，手动拿坐标画框回图上，肉眼对比一次再进训练。
第四个坑是路径漂移。图片文件名带中文、大小写不一致（IMG_001.JPG对img_001.jpg）、jpg 和 xml 分散在不同目录，都会让训练时「图片找到了但标签没找到」。转换脚本里先检查img_path.exists()就是干这个。文件名统一用Path.stem做匹配，不依赖原始后缀。
4. 用 YOLOv8 训练这 1122 张图：标签分布与损失曲线的第一性排查
数据格式清理干净后，训练本身反而没什么玄学。我用 YOLOv8 起步，因为它对小数据集友好、命令行接口干净、损失函数拆得清楚。1122 张图不算多，但作为缺陷检测的专用数据集，训练策略和通用目标检测不太一样：类别不平衡是常态、小目标占比高、测试时漏检比误检更致命。
4.1 组织数据集目录与 data.yaml：最小可训练配置
先把图片和标签按 YOLO 习惯的目录结构放好：
can_yolo/ ├── images/ │ ├── train/ # 约 900 张 │ └── val/ # 约 220 张 ├── labels/ │ ├── train/ │ └── val/ └── data.yaml划分时我用固定随机种子，保证结果可复现。具体做法是把所有图片路径读出来，random.seed(42)后按 8:2 划分，然后把对应标签文件同步拷到 train/val 目录。这一步看着简单，实际问题很多——有人只拷了图片没拷 labels，有人 train 和 val 里有重复图片，都会让评估结果虚高。
data.yaml是最容易写错的文件：
path: /absolute/path/to/can_yolo train: images/train val: images/val nc: 5 names: 0: tear 1: scratch 2: dent 3: stain 4: burr训练命令用 YOLOv8 的 CLI 直接跑：
yolo detect train \ model=yolov8s.pt \ data=can_yolo/data.yaml \ epochs=150 \ imgsz=640 \ batch=16 \ workers=4 \ device=0几个参数按你的硬件调：model我用yolov8s.pt起步，多数工控机跑得动，精度比n版本高一截；imgsz默认 640，但如果你的缺陷集中在拉环细纹这种小区域，我建议直接试960，后面第 5 章会解释为什么；batch以不爆显存为准，16 是 12G 显存常见的值；device=0指定单卡，别让 YOLO 自动检测把 CPU 也牵扯进来。epochs=150对 900 张训练图够用，不必一上来就 300。
4.2 类别不平衡下的损失函数观察：cls_loss 不降先查这三件事
训练跑起来后，只看命令行里每秒刷新的三行 Loss：box_loss、cls_loss、dfl_loss。它们分别管定位、分类和框分布。缺陷检测数据集的常态是某类样本特别少，导致cls_loss尾大不掉。
cls_loss不降，我按这个顺序排查：先确认类别编号没错位，方法是用yolo detect val跑一版看混淆矩阵，如果某个类被系统性误判成相邻编号的类，八成是data.yaml的 names 顺序和转换脚本里class_names不一致；再确认是不是样本太少，少于 50 张的类别不降是正常的，这时候去加增强而不是调损失函数；最后看是不是标注把难例全标成大框，让模型学不到边界。调损失函数最怕玄学操作，改一堆超参不如先把 val 集上的 bad case 打出来看一遍。
box_loss降不下去通常是标注问题——框把罐底背景包进去了，模型不知道该学缺陷本身还是学背景纹理。dfl_loss震荡剧烈时，先查学习率是不是太大，YOLOv8 默认的 warmup 只有 3 个 epoch，小数据集上我会开到 10 个 epoch，让模型先用低学习率焐热参数，再进正常训练。
训练中断也是家常便饭。这时候last.pt就是后悔药：把断点续训命令跑起来，不用从头再来。用last.pt而不是best.pt续训，因为best.pt是历史最优快照，拿它续训会把之前学到的参数状态丢掉一部分。
5. 避坑：易拉罐表面反光、小目标漏检与 7z 解压异常
这章写几条血泪经验，都是缺陷检测项目里特别容易在交付前爆雷的地方。每一条都是「现象 → 原因 → 解决」的结构，你可以直接对照自己遇到的情况。
5.1 7z 解压报错：密码正确却提示错误，不是密码问题
现象：解压到 60% 或 90% 时弹
Headers Error或Data Error，但密码确认无误。
原因：大概率是压缩包在上传/下载过程中损坏，或者分卷压缩包只传了最后一个卷。中文文件名编码也会在 Windows 和 Linux 之间造成解出乱码目录。
解决：先在原平台用7z t测试完整性，确认哪个文件损坏；分卷压缩包必须拿到所有卷再解压。Linux 下解出乱码时，用7z x -mcp=936指定 GBK 编码，或换用unar这类自动识别编码的工具。Windows 下我用 Bandizip 的兼容性比 7-Zip 对中文名更稳。
解压时我还会注意一点：不要直接解压到桌面或临时目录，先把目标目录建好，-o参数指定干净路径。散落一地的文件在后续整理时特别容易漏。
5.2 罐底反光让模型误判：光照增强比单纯加噪更贴近工况
现象：模型在罐底高光区域频繁误检，正常罐底被框成缺陷；同一张图换个打光角度，检测结果截然不同。
原因：易拉罐底部是金属材质，冲压纹理和高光区域在图像里和划伤、凹痕视觉上高度相似。数据集里如果光线单一，模型学到的其实是「亮部 = 缺陷」这个伪特征。
解决：训练增强里把 HSV 的 S、V 通道扰动加大，hsv_s=0.8、hsv_v=0.6，让模型对光照不敏感；推理前对原图做 CLAHE 对比度增强，压制反光过曝区域。数据采集侧更彻底的做法是加偏振光源，但那是硬件改造，数据侧先用增强扛。
反光类缺陷在罐底检测里特别典型，因为拉环附近的冲压纹在特定光线下会呈现和裂纹几乎一样的纹理。这类问题靠调 Loss 解决不了，得从增强和数据采集两个方向同时下手。
5.3 拉环区域细纹漏检：imgsz、切片推理与实时性取舍
现象：划伤、拉环撕裂这类缺陷漏检率很高，其他类都正常。
原因：拉环区域占整罐底部面积不到 5%，在 640×640 的输入尺寸下，这部分特征只有几十个像素，下采样后信息基本丢失。
解决：把imgsz提到 960 或 1280，这是成本最低的改动，代价是推理变慢；如果还不行，用切片推理——把罐底图按 ROI 切成四块或九块分别检测，再把结果映射回原图。切片推理在离线质检场景可行，但高速产线上实时性不够，产线落地我一般建议换更大分辨率输入 + 更轻量的模型结构，而不是上 SAHI。
工业缺陷检测里「小目标」的定义和 COCO 不一样，不是几个像素的框，而是「占图面积很小但业务上致命」的区域。训练时我对这类缺陷专门做过增强：把包含拉环区域的图在随机位置复制粘贴放大，相当于人造了更多小目标样本。
5.4 训练中断的后悔药：last.pt 与 best.pt 的正确用法
现象：训练到第 80 个 epoch 时服务器崩了，重跑一次又是十几个小时。
原因：只备份了 best.pt，没意识到 last.pt 才是断点续训的入口。
解决：训练中断后直接指定model=runs/detect/train/weights/last.pt续训，命令和正常训练一样，YOLOv8 会自动从断点处继续。最佳实践是一边训练一边把last.pt同步到另一个磁盘或 NAS，避免单机故障导致全部白跑。
续训后我还会做一件事：拉出前 50 个 epoch 的曲线对比续训前后的 Loss 是否对得上，确认学习率调度器没有因为重启而重置到异常值。
6. 验证一套缺陷检测模型是否真的合格：漏检率、误检率与置信度阈值
训练结束不等于项目结束。缺陷检测的验收标准不是 mAP，而是产线上真正关心的两个数：漏检率和误检率。mAP 高可能只是因为置信度阈值取得巧，扎到具体工况就要重新校准。
我的做法是先跑一组不同置信度阈值下的评估：
yolo detect val \ model=runs/detect/train/weights/best.pt \ data=can_yolo/data.yaml \ conf=0.15 \ iou=0.5把conf从 0.1 扫到 0.5，每隔 0.05 跑一次，记录每组阈值下的 mAP50、每张图平均检测框数和明显误检数。对易拉罐底部缺陷来说，漏检一个缺陷的损失远大于多框一个误检，所以阈值我一般往低了推，落在 0.15~0.25 之间，而不是 YOLO 默认的 0.5。F1 值最高的阈值不一定适合产线，要把「漏检代价」加权进去自己定。
验证时我会把测试集里最容易漏的那类图单独拎出来过一遍模型，统计真实缺陷里有几个没被框出来。如果漏检集中出现在反光区域或拉环细纹上，说明前面说的增强和分辨率问题还没解决干净。每个项目交付前，我都会习惯性翻一遍 bad case，确认指标不是靠阈值卡出来的侥幸。缺陷检测这个方向，数据决定上限，耐心决定下限，希望帮到你。
本文还有配套的精品资源，点击获取
