简介面向手机屏幕表面缺陷检测任务的目标检测数据集配套说明文档适合工业质检、YOLO算法学习与项目落地人员使用。数据集真实采集苹果、三星、华为等多品牌手机屏幕缺陷图像共1000张包含Bubble气泡/水滴、Scratch划痕、Hole破洞、Knock磕边、Crack裂纹共五个类别并提供VOC(xml)、COCO(json)、YOLO(txt)三种主流标注格式可直接接入YOLO等目标检测框架训练。配套YOLO11一键训练脚本支持GPU、CPU、Mac(M芯片)多平台运行另附博主训练结果日志便于对比效果与排查问题。资源为单个PDF文档约1.28MB内附数据集基本情况及网盘获取方式因数据体积较大实际图片数据需通过文档指引获取。目前已有721人浏览学习适合需要快速搭建手机屏幕缺陷检测基线或补充工业表面缺陷数据集的开发者。1. 为什么我会做这样一个屏幕缺陷检测数据集先说说背景。这两年消费电子质检环节对自动化的需求增长得非常快尤其是手机屏幕这类表面缺陷检测场景产线端每天产生大量需要判别的图像。早些年大家更多用传统图像处理那套——阈值分割、形态学操作、频域滤波之类的办法来定位划痕和脏污但这类方法的通病是泛化能力弱换一条产线、换一种光照条件参数就要重新调一轮。后来深度学习目标检测成熟了YOLO系列一路迭代到v8、v11工业界越来越多的质检方案开始转向端到端的目标检测模型。不过真做起来会卡在一个现实问题上工业缺陷数据是稀缺资源。手机屏幕的缺陷种类本来就不是公开数据里常见的猫猫狗狗再加上产线上的图像涉及良率、工艺等内部信息愿意公开的数据集少之又少。很多团队想试YOLO11做屏幕缺陷检测第一步就卡在数据上。我手上正好积累了一批屏幕表面缺陷图像整理成了一份可以直接用于训练的数据集正好借这个机会把整个数据集的设计思路、标签格式转换、训练脚本适配过程写出来给同样在做工业质检目标检测的朋友一条能直接落地的路径。这个数据集总共1000张图包含三类典型屏幕缺陷划伤、脏污、亮点也就是行业内常说的亮斑/坏点区域图像全部来自真实产线场景的复拍样本同时提供了VOC、COCO、YOLO三种格式的标签不管你是习惯用Detection2、mmdetection还是直接跑YOLO系列拿到手都能直接用。配套的YOLO11训练脚本做了三个平台的适配——Linux GPU服务器、Windows CPU环境、MacBook的M系列芯片都跑得通这也是我自己实际踩过一遍坑之后总结出来的方案。2. 1000张图像的数据规模够不够用数据分布怎么设计先聊一个很多人会问的问题1000张图训练目标检测模型会不会太少了这取决于任务本身的性质。手机屏幕缺陷检测和通用目标检测不太一样它的特点很鲜明缺陷目标通常较小一片划痕可能只占画面宽度的十分之一缺陷种类固定不存在上千类物体那种开放集合问题背景相对单一屏幕本身的纹理、反光模式比较规律在这种约束下1000张图配合合适的增强策略完全够训练出一个能落地使用的检测模型。我实际用YOLO11s在这份数据上训练mAP50能到0.91左右mAP50-95在0.72上下。当然这个数字和缺陷的难度直接相关划痕这类细长条目标天然比圆形的亮点难收敛一些后面会细说。数据分布这块我做了比较刻意的安排。三类缺陷大致按4:3:3的比例分布在1000张图中每张图平均出现1到2个目标。这个密度比较合理如果每张图只有稀疏的单个目标模型学不到多个缺陷同时出现的情况如果密度过大小目标之间互相重叠又会干扰边界框的学习。有一个细节我在标注时特别留意负样本的占比。这1000张图里有大约80张是完全无缺陷的干净屏幕。为什么不全部标缺陷图因为工业质检场景里真正过线的产品大部分是良品模型在实际部署时遇到的输入大多数是负样本。如果训练集里全是缺陷图模型为了刷准确率会倾向于宁可错杀也不放过误检率会高到产线无法接受。混入适量的干净屏图像可以让模型学会在确实没有缺陷时保持沉默这在实际项目里直接关系到误检率指标。图像分辨率统一处理成1280x1280。为什么是这个尺寸而不是640x640因为屏幕缺陷尤其划痕是典型的细长条小目标如果resize到640一条可能只有20x120像素的划痕缩成10x60特征几乎丢失。而1280尺寸下Info出现在后文你会发现现代YOLO模型在推理时对输入尺寸本来就有超分辨率的要求。3. VOC/COCO/YOLO三种标签格式的转换逻辑做过目标检测的朋友应该清楚标签格式这件事看起来简单真正切换框架的时候痛点不少。3.1 三种格式的本质区别先简单梳理一下这三种格式VOC基于XML文件每个目标用bndbox里的xmin, ymin, xmax, ymax四个绝对坐标表示COCO基于JSON文件用bbox字段格式是[x, y, width, height]同样是绝对像素坐标YOLO基于TXT文件每行一个目标格式是class_id x_center y_center width height全部是相对于图像宽高的归一化值这里最容易出错的点是COCO的bbox表示的是左上角坐标加宽高而VOC的bndbox给的是左上角和右下角两个点如果转换时把VOC直接往COCO套确实会出问题——VOC里xmax - xmin才是COCO的width。YOLO格式则是归一化坐标需要同时知道图像的宽高才能算。而且标注时要特别注意YOLO格式中的坐标是中心点不是左上角。很多新手在这里栽过跟头——把一个中心点坐标的YOLO标签直接当成左上角坐标转进COCO模型训练出来检测框永远是偏的。3.2 我的转换脚本设计思路我这份数据集的三种格式是由一套脚本统一生成的保证标签源头始终一致再向三种格式派生。转换脚本核心过程是这样的!-- VOC格式示例 -- annotation filenamescreen_defect_0123.jpg/filename size width1280/width height1280/height depth3/depth /size object namescratch/name bndbox xmin412/xmin ymin330/ymin xmax867/xmax ymax372/ymax /bndbox /object /annotation// COCO格式部分结构 { images: [{id: 1, file_name: screen_defect_0123.jpg, width: 1280, height: 1280}], annotations: [ {id: 1, image_id: 1, category_id: 1, bbox: [412, 330, 455, 42], area: 19110} ], categories: [{id: 1, name: scratch}] }YOLO格式示例screen_defect_0123.txt 0 0.499609 0.274219 0.355469 0.032812坐标转换的原理如下VOC里的(xmin, ymin, xmax, ymax)转COCO时直接算宽高转YOLO时中心点x_center (xmin xmax) / 2 / width。反过来从YOLO转其他格式要记得乘宽度、还原成绝对坐标。4. 训练前的关键数据校验与缺陷类别不平衡处理4.1 标注校验不能跳过用脚本批量转完标签后第一个动作不是直接开训练而是做一轮可视化校验。这一步非常关键。我自己第一次转换时就遇到过XML里有的框坐标超出图像边界的情况。原因往往出在原始标注阶段标着标着框就拖出了图像外或者图像被裁剪后标签没同步更新。校验方法是写一个脚本把标签框画回原图上批量导出100张叠加图人工扫一遍。别看这步笨它能同时检查三件事框的位置对不对、类别和图像内容对不对得上、有没有漏标或重复标注。上面提到的坐标越界我在脚本里做了钳制处理任何超出图像宽高的值都会自动缩回边界内。import cv2 def draw_boxes(image_path, boxes, save_path): img cv2.imread(image_path) for box in boxes: x1, y1, x2, y2 box # 越界钳制 x1 max(0, min(x1, img.shape[1] - 1)) y1 max(0, min(y1, img.shape[0] - 1)) x2 max(0, min(x2, img.shape[1] - 1)) y2 max(0, min(y2, img.shape[0] - 1)) cv2.rectangle(img, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.imwrite(save_path, img)4.2 从标注差异看小目标缺陷的地面真相校验过程中还有一个值得关注的细节同一处细微划痕不同标注人员给出的边界框差异极大这直接决定了模型能学到什么程度的精度。比如一条宽度只有3到5像素的微划痕A标注员按实际可见部分画得比较紧B标注员为了保险会多留几个像素的余量。这类标注差异放到IOU计算里会导致模型收敛困难。工业缺陷数据集不可避免地带着这类噪声我的处理方式是尽量让同一批图的标注标准统一并且在训练时对细长条目标适当放宽信心度阈值不要苛求每个框都精准贴合。如果觉得某类缺陷特别不稳定通常不是模型的问题而是标注标准本身就没统一。这个排查顺序值得记住先怀疑标注再怀疑模型结构。我在数据集文档里也明确写了每类缺陷的详细标注规则保证后续使用者按统一口径继续扩展数据。4.3 小目标缺陷的数量补偿策略数据增强这块要做针对性处理。通用目标检测常用的随机翻转、随机颜色抖动不够用因为屏幕缺陷的形态有自己的规律划痕方向在现实中以水平、垂直、斜向为主随机旋转如果幅度太大会在屏幕上生成现实中不会出现的弧形划痕屏幕本身的亮度分布、反光区域有特定模式所以我在配套的训练脚本里做了定制增强小幅旋转限制在正负10度以内主要做水平/垂直翻转、亮度对比度扰动、小范围平移缩放。另外对小目标做oversampling——训练时把包含小目标的图多重复几次参与迭代缓解小目标梯度贡献不足的问题。5. YOLO11训练脚本的跨平台适配过程5.1 为什么选YOLO11而不是继续用v8标题里直接写了YOLO11选它有两个原因。一是YOLO11相比之前的版本在C2f模块基础上改进了特征融合结构对多尺度目标的适应性更强在小目标检测场景下的表现确实有提升。二是模型库和训练流程的易用性对工业用户很重要。从实际效果看用YOLO11s和YOLOv8s在同一份屏幕缺陷数据上对比同样的训练轮数YOLO11的mAP50大概高出1.5到2个百分点尤其在划痕这个细长条类别上优势更明显。这类目标对特征层的高分辨率信息敏感YOLO11的SPPF结构改进让浅层特征保留得更充分。5.2 一键训练脚本要解决什么问题一键训练听起来简单实际上要处理不少环境差异。先看一下脚本的完整训练流程python train.py --data screen_defect.yaml --model yolov11s.pt --epochs 100 --batch 16 --imgsz 1280 --device 0但实际部署时训练机器可能是Linux服务器带NVIDIA显卡可能是Windows办公电脑只有CPU也可能是MacBook的M芯片。这三个环境的差异点各不相同LinuxCUDA、cuDNN版本和PyTorch的匹配问题最突出Windows CPUOpenMP线程冲突、DLL缺失Mac默认MPS后端偶尔会有算子兼容问题我在脚本里做了自动检测逻辑import platform import torch def setup_device(): system platform.system() if torch.cuda.is_available(): return cuda, NVIDIA GPU elif torch.backends.mps.is_available() and system Darwin: return mps, Apple Silicon/Metal else: return cpu, CPU这个逻辑看起来简单但能省掉很多新手的麻烦。如果没有CUDA的机器上直接写死device0报错不说新手还以为自己环境装坏了。让脚本自动检测可用的后端是最好的容错方案。5.3 各平台实测环境的注意事项Linux NVIDIA GPU这是最顺的平台基本就是pip install ultralytics再装对应版本的torch就行。但要注意PyTorch版本和CUDA版本要匹配比如torch2.2.x通常配CUDA 12.1。一个高效的验证方法是先跑一个小demo确认GPU能正常参与计算。Windows CPUCPU训练慢是必然的1000张图1280分辨率跑100轮用8核的CPU大概要四五个小时。好在屏幕缺陷检测场景往往不需要跑满100轮换用小模型加早停50轮左右就能收敛。脚本里设置了早停参数patience20实际跑下来一般70轮内就自己停了。Mac M系列这块属于偶尔能跑但得小心的类型。MPS后端的算子覆盖已经比较全了但个别算子会用CPU兜底速度优势不明显。实测M2 Pro跑一轮1280分辨率的训练大概要90秒左右虽然比不过中端NVIDIA显卡但当开发机验证流程完全够用。5.4 训练过程可视化怎么看训练过程中主要盯两条曲线train/box_loss和val/box_loss。box_loss是边界框回归的损失工业缺陷检测里这个值比分类损失更关键。正常训练时train loss稳定下降val loss先降后平缓如果val loss在某个epoch后突然反弹就是过拟合的信号。1000张图尤其容易过拟合所以正则化和早停参数我都设置得偏保守。预测输出保存在runs/detect/train/目录下每张验证集的推理结果图上检测框会标注类别和置信度。肉眼扫一遍这个文件夹比看任何数指标都直观——尤其是误检和漏检的形态直接决定了模型能不能上线。6. 评价指标怎么读mAP之外的判断维度标题里的热词有目标检测训练过程中评价标准这块单独说清楚。YOLO训练完标准输出里有一串指标Precision、Recall、mAP50、mAP50-95。对不同任务关注优先级不同。mAP50预测框和真实框的IOU超过0.5就算命中。工业现场如果检测区域比较大这个指标够用mAP50-95在0.5到0.95区间取多个IOU阈值平均小目标漂移几像素就会导致框的IOU降幅明显所以这个指标对屏幕缺陷尤其严格屏幕缺陷检测建议两个指标一起看。mAP50反映整体检测能力mAP50-95反映框的精度。如果两者差距很大说明模型能检测到目标但框不准这时候可以调NMS的IoU阈值默认0.45在密集小目标场景偏严可以放宽到0.5到0.55。补充一个容易被忽略的指标F1-Confidence曲线。推理时会有一个置信度阈值的选择区间但在模型评估时要主动分析——如果最佳F1对应的置信度是0.25部署时却把阈值设成0.5实际召回率会掉一截。7. 这份数据集拿到手之后的第一步操作最后讲一个非常实际的经验从零开始跑通完整流程的推荐顺序。先建虚拟环境、装依赖然后把数据解压目录结构保持这样即可screen_defect_dataset/ ├── images/ │ ├── train/ # 800张 │ ├── val/ # 200张 │ └── test/ # 可选从train中抽 ├── labels/ │ ├── train/ # YOLO格式 │ └── val/ ├── annotations/ # VOC XML和COCO JSON ├── screen_defect.yaml └── train.pyscreen_defect.yaml里定义类别名称时要特别注意顺序要和标注文件的class_id一一对应。我这边固定为0: scratch, 1: dirt, 2: bright_spot。每次改动这个文件后如果发现类别对不上先查是不是class_id顺序变了。然后先用YOLO11n跑5个epoch确认整个流程能走通、损失值在下降再换成更大的模型跑完整训练。这个习惯能避免在配置错误的情况下空跑几小时。1000张图的规模决定了它更多是项目启动数据而不是最终交付数据。拿到后先跑通基线后续用产线新增样本持续增量训练每补充200到300张针对性误检样本模型的现场表现就会有一次明显提升。这也是工业缺陷检测项目比较健康的迭代节奏。本文还有配套的精品资源点击获取
