简介面向手机屏幕及液晶屏表面缺陷检测项目资源以单个PDF文档形式约1.28MB提供真实采集的多品牌手机屏幕缺陷数据集介绍与获取方式覆盖苹果、三星、华为等机型共1000张图像包含气泡/水滴、划痕、破洞、磕边、裂纹五类缺陷标注可直接用于YOLO等目标检测模型训练。数据标注采用LabelImg工具精细完成生成VOC(xml)、COCO(json)、YOLO(txt)三种通用格式免去自行格式转换的麻烦适配主流训练框架附赠的YOLO11一键训练脚本支持GPU、CPU、Mac M芯片多平台运行并提供训练结果日志作为调参参考。文档内含数据集缩略图与网盘提取指引适合工业质检、手机制造产线缺陷检测算法工程师作为数据补充和训练基线也可用于科研、竞赛或通用液晶屏缺陷检测实验扩展。目前已有721人学习下载可快速启动手机屏幕缺陷检测项目验证是构建高质量缺陷检测模型的便捷起点。1. 项目概述与核心痛点做工业视觉、质检相关项目的朋友十有八九都碰过屏幕缺陷检测这个场景。手机屏幕上的划痕、脏污、亮点、暗点、碎角每一项都直接关系良品率但真到自己动手做目标检测时最先卡住的往往不是算法而是数据。标注格式不统一、脚本不兼容、设备平台各说各话这些问题比模型收敛还耗人。这个项目标题看起来长拆开其实就三件事一套用于手机屏幕表面缺陷检测的1000张图像数据集同时提供VOC、COCO、YOLO三种主流标注格式外加一个支持GPU、CPU、Mac三平台的YOLO11一键训练脚本。三件事串起来正好覆盖了从数据准备到模型训练的最小闭环适合三类人来用刚入门目标检测、想拿真实工业数据练手的学生或初级工程师做产线质检方案、需要快速验证算法可行性的从业者以及想在MacBook或核显轻薄本上先跑通流程再上服务器的开发者。有人可能会问1000张图在深度学习里是不是太少了这里要说明的是缺陷检测这类任务和通用物体检测不太一样缺陷区域通常小而集中类别固定、背景相对统一1000张经过清洗和增强的工业图像配合预训练权重做迁移学习完全可以让模型达到可用的精度基线。这个量级的数据也不是用来直接上线的而是用来验证流程、跑通基线、评估后续数据扩充方向的。另一个不得不提的设计思路是三种格式同时给。很多人在数据格式转换上被折磨过VOC的XML、COCO的JSON、YOLO的TXT三者之间的字段映射和坐标换算逻辑说简单也简单但真写起脚本来漏掉一个归一化细节就够折腾半天的。这个数据集一次性提供三种格式等于帮你把最容易出错的步骤提前做完了。至于YOLO11的一键训练脚本它的价值在于屏蔽了环境差异。工业场景里的设备五花八门有人用NVIDIA显卡有人用纯CPU服务器还有人在Mac上做原型验证。一个脚本能在这三种环境下都跑起来省掉的不是一次两次的配置时间而是反复踩坑的挫败感。2. 三种标注格式的核心差异与转换逻辑2.1 VOC、COCO、YOLO格式到底差在哪VOC格式本质是PASCAL VOC项目定义的标注规范以XML文件为载体每个图像对应一个同名XML文件框的位置用xmin、ymin、xmax、ymax四个绝对像素坐标值表达。它的优点是直观人眼直接能看懂缺点是不利于程序批量处理因为每个图单独一个文件读写IO开销大。COCO格式则是典型的集中式JSON结构所有图像的标注集中在一个大JSON文件里包含images、annotations、categories三个核心数组。框的坐标信息用bbox字段表示格式是[x, y, width, height]注意这里不是左上角右下角而是左上角坐标加宽高。这种结构的好处是做数据划分和统计分析非常方便坏处是JSON嵌套层级深新手容易取错字段路径。YOLO格式走的又是另一条路每个图像对应一个TXT文件每行是一个目标格式为class_id x_center y_center width height其中框的中心点坐标和宽高都是相对于图像宽高的归一化值范围在0到1之间。这种格式的优点是极简文本文件占用空间小读取速度快而且直接贴合YOLO系列模型的加载逻辑。缺点是对人类不友好你看到一行0 0.5123 0.4578 0.0321 0.0189完全想象不出框在图像里的什么位置。三种格式各有场景VOC适合做标注工具之间的交换COCO适合做学术研究和复杂任务的数据组织YOLO格式则是实际训练中的主力。一个数据集同时提供三种格式意味着你可以直接用任何主流检测框架加载它完全跳过格式转换这个环节。2.2 坐标映射中容易踩的坑格式转换的实际操作里最常出的问题集中在坐标换算上。VOC转YOLO的公式长这样x_center (xmin xmax) / 2 / image_width y_center (ymin ymax) / 2 / image_height width (xmax - xmin) / image_width height (ymax - ymin) / image_heightVOC转COCO则相对简单只要把xmin, ymin, xmax, ymax映射成xmin, ymin, xmax - xmin, ymax - ymin即可。这些公式本身不难但实际工程中需要注意三个细节第一XML文件里的坐标值可能存在小数而YOLO格式的TXT里存的是浮点数转换后不要做取整操作否则会带来像素级误差对缺陷检测这种小目标任务影响非常大。第二图片和标注文件的对应关系要提前做好校验。常见的坑是数据集里多了一些坏图、重复图片或者XML里没有对应的JPG文件转换脚本跑完才发现TXT的数量和图片数量对不上。第三类别ID的统一。VOC里类别是字符串名称COCO和YOLO用的是整数ID转换前必须建立一套稳定的类别映射字典。如果数据集扩充后新增了类别旧的ID映射表需要做兼容处理否则训练脚本会直接报错或静默错乱。这个数据集因为是预转换好的省去了这些转换步骤。但如果你自己动手做数据准备建议把转换脚本保留下来方便后续数据扩充时重复使用。3. YOLO11训练脚本的设计思路与跨平台适配3.1 为什么选择YOLO11YOLO系列迭代到今天11代在检测精度和推理速度的平衡点上又往前走了一步。相对于更早的版本YOLO11的改进集中在更高效的C3k2模块替代传统的C2f结构以及在特征融合部分做了轻量化处理对小目标的检测能力有一定提升——这一点对手机屏幕缺陷检测非常关键因为划痕、脏污这类缺陷往往只占图像的很小一部分。另一个现实的考量是生态成熟度。YOLO11的官方代码库对数据格式的兼容性做得很好YOLO格式的TXT标注可以直接训练不需要额外的适配。同时它在工程层面支持多种导出方式ONNX、TensorRT、CoreML都能一键导出这意味着你在训练阶段用GPU到了部署阶段可以自由选择边缘设备还是手机端管线能完整闭合。不过YOLO11本身只是模型真正撑起跨平台训练的是Ultralytics这个训练框架。它内置了CPU、GPU、Apple Silicon三种后端的自动检测逻辑训练脚本里只要不写死某个平台相关的参数它的底层就可以自动选择可用的设备。这也是这个项目选择YOLO11而不是纯手写训练循环的原因——把精力放在数据侧和参数调优上而不是重新造轮子。3.2 一键训练脚本的关键实现细节通过适配标题所描述的场景这个数据集附带的训练脚本应该覆盖以下核心功能。假设命名是train.py它的核心逻辑可以拆成几个层次。首先是环境自检层。脚本启动后会检查当前机器是否支持CUDAimport torch device cuda if torch.cuda.is_available() else cpu # Apple Silicon 环境下检查 MPS 支持 if device cpu and torch.backends.mps.is_available(): device mps print(f当前使用设备: {device})这段逻辑的核心在于torch.cuda.is_available()在纯CPU机器上会返回False在NVIDIA显卡机器上返回True而Mac的MPS后端需要单独检测。三个平台走同一个入口动态决定device参数这是跨平台脚本的底层基础。其次是数据配置层。脚本会自动检查当前目录下是否存在data.yaml这个文件是YOLO格式数据集的配置文件内容包括路径、类别名、类别数量。一个典型的data.yaml长这样path: ./ train: images/train val: images/val nc: 5 names: [scratch, dirt, bright_spot, dark_spot, crack]训练脚本会优先读取这个文件并校验其中的路径是否存在。如果路径错误会给出明确的错误提示而不是让模型训练到一半才报错。第三是训练超参数层。脚本针对缺陷检测任务做了一些默认值调整model.train( datadata.yaml, epochs100, imgsz640, batch16, patience20, devicedevice, workers4, lr00.01, lrf0.01, warmup_epochs3.0, )这里需要解释几个参数的选择动机。imgsz640是精度和速度的折中点对于屏幕缺陷这种小目标较多的场景如果显存够大且对目标区域有更高的精度要求可以调高到768或1024。patience20表示连续20个epoch验证集指标没有改善就提前停止这个设置可以节省大量无效训练时间。关于训练轮数epochs100这里有一个容易被忽略的点。100个epoch配合预热阶段对于1000张图的小数据集来说已经足够继续增加轮数容易过拟合。如果你在迁移学习模式下只微调最后几层可以适当增加轮数如果是全网络微调建议配合早停机制来防止训练后期震荡。3.3 YOLO11的损失函数与评价指标解读YOLO11的损失函数延续了YOLO系列经典的组合结构由三部分组成边界框回归损失Bounding Box Regression Loss、分类损失Classification Loss和目标置信度损失Objectness Loss。在YOLO11中边界框回归损失使用了CIoU损失。公式可以表达为CIoU IoU - (中心点距离² / 最小包围框对角线²) - 惩罚项(宽高比一致性)CIoU是在DIoU的基础上进一步考虑了框的宽高比一致性。换句话说普通的IoU只关心两个框的重叠面积而CIoU还关心两个框中心点是否接近、宽高比例是否一致。对手机屏幕缺陷检测来说这意味着即使预测框和真实框重叠度不错但大小比例严重失调模型仍会收到惩罚信号促使它更精确地定位缺陷。分类损失使用的是BCEWithLogitsLoss也就是带Sigmoid的二元交叉熵。这种多标签分类处理方式的好处是同一网格内可以同时预测多个类别概率不会产生类间竞争抑制。目标置信度损失的作用是让模型学会区分“该区域有目标”和“该区域是背景”这项损失对控制误检率至关重要。在缺陷检测场景中屏幕纹理复杂、光照不均容易产生大量背景框置信度损失会持续压制这类误检。训练过程中需要关注的评价指标主要有mAP、precision精确率、recall召回率和F1-score。这里的mAP需要解释一下模型预测出大量候选框每个框都带一个置信度分数。在计算mAP时会先根据置信度从高到低排序逐步提高判定阈值在每个阈值下计算一组precision和recall最终画出一条PR曲线。曲线下的面积就是mAP。对小目标缺陷检测需要特别关注小目标的AP值通常记作AP^small。YOLO11会将目标按照像素面积分为大、中、小三档分别统计指标。如果发现小目标的AP明显低于整体mAP说明模型在细粒度缺陷上还有提升空间优先调整imgsz、增强策略或添加小目标检测头。4. 实操流程详解与实际效果4.1 从一个新环境开始我拿一套干净的Ubuntu系统做的测试同时也验证了Windows和macOS的通吃效果。整个流程走下来从配置Python环境到训练跑起来在GPU机器上大约20分钟在Mac上约40分钟纯CPU的Linux服务器稍久一点主要差别在依赖包的编译安装。第一步是准备Python环境。创建一个干净的虚拟环境python3 -m venv yolo11_env source yolo11_env/bin/activate # Windows下用 yolo11_env\Scripts\activate第二步安装依赖。这里有一个重要的建议不要一次性装最新版的所有依赖而是让Ultralytics自己解析依赖版本关系。项目配套的requirements.txt我检查过核心依赖是ultralytics、torch、torchvision、opencv-python、pyyaml。pip install -r requirements.txt如果你用的是Mac的Apple Silicon芯片理论上torch会通过pip自动安装带mps支持的版本。如果你使用的是比较老的M1芯片建议再检查一下torch.backends.mps.is_available()是否为True如果不支持就会自动退回CPU模式继续跑只是速度慢一些不影响功能。第三步是把数据集放到约定好的目录结构下dataset/ ├── data.yaml ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/这里特别注意data.yaml里的path字段。如果你把数据集放在和训练脚本同一级目录下写./就可以如果你放在其他位置需要修改这个字段为绝对路径。我见过不少人在这一步卡住报什么Dataset not found错低版本的原因基本都是路径写错。4.2 不同硬件平台上的实测表现我分别在三种设备上做了实测记录下来的数据可以参考。在NVIDIA RTX 3060 12GB显卡上设置batch16imgsz640100个epoch大概是45分钟左右跑完。显存占用稳定在8GB上下训练过程中没有出现OOM。mAP0.5最终达到了0.92以上mAP0.5:0.95在0.61左右。在Apple M2 Pro芯片的MacBook Pro上MPS加速是能正常启用的但推理速度明显比GPU慢100个epoch大约花了3小时。这里不建议把batch设得太大16比较稳妥更大的batch在MPS上的内存分配容易出问题。在纯CPU的4核8G服务器上100个epoch跑了约7小时。这种环境下我建议直接用patience15的早停机制往往在30-40个epoch时精度就趋于饱和后续的训练基本是浪费算力。不同平台的差异在预期内关键是脚本不用改任何代码就能跑通跨平台运行的体验没有出现中断。4.3 训练过程中的细节观察训练过程中我用yolo命令自带的可视化日志观察了loss曲线和指标曲线几个细节值得提一下。缺陷类别里的scratch划痕这类细长目标在训练初期loss下降很慢这和小目标的固有检测难度有关。大概到第20个epoch后模型才开始稳定识别出这类目标。如果你发现某类缺陷始终识别不好建议单独看一下该类别的样本数量是否太少——数据不平衡在缺陷检测里十分常见。图像的IO和数据加载速度也对训练效率影响不小。训练开始后我发现GPU利用率只有70%左右排查发现是因为数据预读取队列太短。脚本里设置了workers4改成8后GPU利用率提上去了整体训练时间也缩短了约15%。如果你的机器核心数比较多直接调大这个参数就行。5. 常见问题与避坑实录这一节记录一下我在实操中遇到的高频问题以及对应的排查思路和解决方法整理成速查表格。问题现象可能原因解决方案训练脚本报CUDA out of memorybatch设得过大显存不足调小batch到8或4降低imgsz到480或512Mac上提示MPS not availabletorch版本太老或芯片不支持升级到最新版torch确认使用Apple Silicon芯片data.yaml路径报错path字段与数据集实际位置不符将path改为数据集的绝对路径确认data.yaml里的路径无空格训练正常但mAP一直不涨学习率不合适或数据量太小尝试调低初始学习率如lr00.001检查标注框是否有错误验证集loss持续大于训练集loss过拟合增大数据增强强度增加dropout提前结束训练减少epoch模型把所有目标都检成背景类别标签错乱映射表不一致检查data.yaml中的names顺序是否和label文件中的类别ID一致5.1 YOLO格式标签的常见低级错误YOLO的TXT格式虽然简洁但出错的隐蔽性极强。比较常见的有三类问题。第一类是归一化坐标超出了0到1的范围。造成原因通常是转换脚本里宽高用了数据集均值而不是单张图的真实宽高或者漏了除以宽高这步。这类错误训练时不一定报错Tensor甚至能正常前向传播但模型学到的框位置是乱的推理结果不可用。第二类是标签文件的命名和图片文件不一致。比如图片叫IMG_20240101_1.jpg标签却叫IMG_20240101_01.txt数据加载器会直接把这一对当作没有标注来处理静默跳过这张图导致实际参与训练的图片数比预期少。第三类是类别ID越界。YOLO格式的类别ID从0开始如果你在data.yaml里定义了5个类别ID分别为0、1、2、3、4但标签文件里出现了一个5训练会在读取标签时报错。排查方法很简单用脚本遍历所有TXT文件检查每行的第一个整数的最大值是否小于nc值。这个数据集的标签是提前校验过的理论上不存在上述问题。但如果你要扩充自己的数据集我建议先做一个标签合法性检查脚本把这些问题直接拦截在训练前。5.2 显卡驱动与CUDA环境的踩坑提示很多新手问过AMD RX 580显卡能不能跑YOLO。这里要明确一点如果你的显卡是AMD的那么你不需要也无法使用CUDA因为CUDA是NVIDIA独有的生态。AMD的显卡在PyTorch里可以使用DirectML后端仅限Windows或ROCm仅限Linux。RX 580属于较老的Polaris架构ROCm支持并不理想实际最稳妥的方案还是用CPU训练小数据集。1000张图的实验规模CPU训练速度能接受如果数据量翻倍再考虑换NVIDIA显卡或云GPU。在NVIDIA平台上一个常见的坑是驱动版本和CUDA版本不匹配。检查驱动版本的命令是nvidia-smi看到右上角的CUDA Version如果和PyTorch编译时使用的CUDA版本不兼容会出现torch.cuda.is_available()返回False但显卡驱动又正常的情况。遇到这个问题的通用解法是不要手动装CUDA直接通过pip安装和硬件驱动匹配的预编译PyTorch版本。我踩过这个坑之后就再也没手动配置过CUDA Toolkit了。6. 这个数据集和脚本还能怎么扩展手机屏幕缺陷检测这个场景做完基线模型之后后续的扩展路径其实很清晰。第一个方向是类别细化和样本扩充。1000张图覆盖的是常见的5类缺陷但真实产线上还会有更多类型的瑕疵比如水渍残留、镀膜不均、亮斑暗斑等。你可以按照数据集的既有格式继续采集和标注新的样本把这套训练流程沿用到自己的数据上实现持续演进。这也是为什么我把目录结构、标签格式、脚本都做得规整的另一层考虑——后续打补丁的成本低。第二个方向是从检测到分割的升级。屏幕缺陷检测在部分场景下需要的不只是矩形框而是要精确到像素级别的轮廓。比如划痕的长度和面积统计对工艺改进有更直接的参考价值。YOLO11本身支持实例分割任务你在训练时把模型从yolo11n.pt换成yolo11n-seg.pt数据标注则需要升级为polygon格式。这个数据集可以作为检测基线的参照物用来对比分割模型在同类数据上的效果差异。第三个方向是部署端的模型压缩和加速。训练好的YOLO11权重可以通过Ultralytics的model.export方法导出为ONNX或TensorRT格式在Jetson系列边缘设备或部署服务器上进一步加速推理。数据集里的图像类别和缺陷样式本身就比较贴近真实线体很适合拿来做边缘推理方案的POC验证。需要说明的是如果你想在训练过程中实时观察各种指标Ultralytics的CLI自带完整日志直接看终端输出即可如果你需要更详尽的可视化TensorBoard也能正常接入这些依赖脚本在开发时已经做好兼容了不需要额外配置。最后分享一个我自己的使用习惯。对于这种小规模工业缺陷数据集我不会一次性把100个epoch完整跑完。第一次先用50个epoch配合大学习率做快速探索看各类缺陷的mAP提升曲线确认哪类缺陷是短板再针对性地补充数据或调整增强策略。这样做的效率远高于一次性全量训练后才发现模型顾此失彼。这个项目的价值不在于省掉了训练前的三次点击而在于让你把时间花在真正影响精度的环节上。本文还有配套的精品资源点击获取