做工业检测项目的时间长了你会发现手机屏幕质检是个特别典型的场景。产线上一天要过几千块屏划伤、亮点、暗斑、崩边这些缺陷全靠人眼盯师傅看久了眼睛吃力漏检率还不好控。我接触过不少做视觉的同行都在琢磨怎么把这块用算法接过来。今天聊的这个项目就是基于YOLOv8搭的一套手机屏幕缺陷检测系统支持图像、视频和摄像头实时检测PyTorch框架Python源码整体思路和踩坑记录都能直接复用。如果你也在做表面缺陷检测、工业质检或者类似的图像识别项目这篇内容值得认真看一遍。项目本身的边界很清楚不是做复杂的产线级MES系统而是把最核心的“检测能力”跑通——给一张图能标出缺陷的位置和类别给一段视频能逐帧分析接上摄像头能近乎实时地看到检测结果。这三个场景对应的是研发验证、离线批处理和产线试点的不同需求。整套代码用PyTorch实现模型基于YOLOv8训练和推理链路完整属于那种“拿到就能跑、改改就能用”的项目。1. 项目定位与核心思路拆解1.1 手机屏幕质检的典型场景与痛点手机屏幕的缺陷检测和普通零部件的缺陷检测还不一样。屏幕本身是玻璃加显示面板的复合结构透光、反光缺陷种类杂。常见的有划伤、亮点、暗点、污渍、气泡、崩边、色斑等。其中划伤和崩边这类外观缺陷靠轮廓和纹理特征能看出来亮暗点这类显示缺陷需要特定的打光方式才明显。这些缺陷的尺寸往往很小有的只有几个像素和背景对比度又很低传统的图像处理算法做起来非常痛苦——阈值分割可能今天调好明天就失效换一条产线又得重来。我见过很多做视觉的同学一上来就想着用opencv做预处理加形态学操作结果项目越做越复杂规则越堆越多最后维护成本完全失控。深度学习检测模型在这类场景下的优势很明显不需要手工设计特征只需要把不同状态的缺陷图喂给模型让它自己学习特征表达泛化能力也更好。而YOLO系列又是目前工业落地最成熟的检测框架之一速度够快、精度不差、部署方案完善用它来做手机屏幕缺陷检测是性价比非常高的选择。1.2 为什么选YOLOv8而不是更早的检测模型很多人会问为什么是YOLOv8不是Faster R-CNN也不是YOLOv5我的答案很直接工程落地图个省心。先说不选Faster R-CNN的原因。两阶段检测器精度确实高但速度是硬伤。在产线上或者说在摄像头实时检测场景下FPS达不到要求就是没法用。手机屏幕检测属于大批量、短节拍的应用检测一帧的耗时必须控制得住。YOLO这种一阶段方案把分类和定位统一回归速度直接翻几倍。再说YOLOv8相比YOLOv5的提升。v8把检测头换成了Anchor-Free结构不再需要预设锚框减少了一堆需要调的参数。C2f模块替换了原来的C3模块梯度流更丰富特征提取能力更强。训练过程也做了不少优化比如解耦头设计分类和回归分支分开收敛更快、精度也更稳。实际测下来在同样精度的前提下v8的模型体积和推理速度都比v5有优势。当然选YOLOv8还有一个现实原因PyTorch生态太成熟了。ultralytics官方仓库把训练、验证、导出、部署的链路都打通了模型文件一个.pt搞定导出ONNX也就一行命令。对于做项目交付的人来说没有比这更省事的了。1.3 图像、视频、摄像头三类检测的架构差异这个项目最大的特点就是检测入口多图像、视频、摄像头。很多人一开始不理解觉得不就是换一个数据来源嘛实际上差得远了。图像检测是最简单的。读一张图推理一次出结果。核心关注点是推理速度、精度、可视化效果。视频检测就不一样了。视频本质上是一帧一帧的图片序列但帧之间有时间连续性处理逻辑要考虑抽帧频率、逐帧还是跳帧、是否做结果平滑。如果每帧全量推理算力消耗大如果跳帧太多又会漏掉一闪而过的缺陷。这里需要根据实际场景平衡。摄像头实时检测是难度最高的。因为它是连续的视频流而且是无限长的流内存管理、帧缓冲、延迟控制都要考虑。摄像头检测不能像图像检测那样一次性读入再处理也不能像视频处理那样可以离线慢慢算它必须在一个生产-消费模型里不断循环。更关键的是延迟。产线上如果算法处理一帧要200毫秒那屏幕上看到的画面就有明显的卡顿感操作体验会很差。所以这个项目的代码里三路检测并不是简单复用一个函数而是各自有独立的处理流程但又共享同一个推理核心。这也是我在设计时比较满意的一点模型只有一个接口统一但适配不同场景的吞吐需求。2. 缺陷定义、数据准备与模型训练的关键细节2.1 屏幕缺陷的常见类型与标注建议做检测项目第一步永远是定义清楚“到底要检测什么”。这个项目里我建议把缺陷类别控制在5到8类不要贪多。类别太多样本收集压力大模型也容易混淆。实际项目里常用的类别划分是这样的缺陷类别特征描述标注建议划伤(scratch)细长亮线方向不规则用多边形或矩形紧贴缺陷区域不要包含正常纹理亮点(bright_spot)局部高亮圆点矩形框略收缩避免把光晕包含进来暗点(dark_spot)局部亮度偏低的小点标注最小外接框即可污渍(stain)片状脏污边界模糊尽量贴近实际轮廓不要框得太大崩边(chip)玻璃边缘缺损沿破损边缘标注标注框可稍微外扩气泡(bubble)圆形或椭圆形透亮区域按实际形状标注重叠气泡建议分开框这里有一个很重要的标注原则标注框宁可稍微紧一点也不要松。因为YOLO这类目标检测模型对目标位置的回归是基于边界框的如果框得太松模型学到的是“大概那块区域有缺陷”位置精度会下降后续做坐标统计或者固定检测位的时候误差会很大。我在项目初期就吃过这个亏标注员为了省事每个框都往外扩了一圈看起来没啥大问题但模型训练出来之后在精度评估里AP值掉了好几个点后来重新规范标注才拉回来。还有一个容易被忽视的点一张图里有多个缺陷是正常的不要嫌多就把小的过滤掉。尤其是亮点和暗点这类小目标本身尺寸就小样本已经很难收集了标注的时候再漏几个那模型基本就学不到这类特征了。数据集规模方面我个人的经验是每类缺陷至少要有200到500个标注实例。手机屏幕的缺陷样本不太好收集产线上不良品本来就不多。当时项目里的做法是先把历史积累的缺陷图全部翻出来能标注的尽量标再配合数据增强把规模扩大。如果原始样本实在不够可以考虑先用公开的表面缺陷数据集做预训练然后在自己的数据上微调效果会比直接小样本训练好很多。2.2 数据增强与样本均衡策略屏幕缺陷检测的数据增强和通用目标检测的增强逻辑不太一样。不能盲目地做随机旋转和随机裁剪因为屏幕图像有固定的方向性划伤横向和纵向的视觉形态是不一样的90度旋转或者水平翻转会改变缺陷的形态语义干扰模型学习。我在项目里实际采用的增强策略是这样的亮度对比度调整。屏幕缺陷和光照关系很大模拟不同打光条件下的亮度变化帮助模型学出更鲁棒的特征。轻微模糊与噪声。模拟传感器噪声和聚焦不准的情况增加模型对画质下降的容忍度。随机缩放与平移。模拟不同分辨率下缺陷的尺度差异这个对小目标检测特别有用。Mosaic增强。ultralytics默认会开Mosaic把四张图拼成一张可以显著增加样本多样性对提高小目标检出效果帮助很大。但不做90度旋转和上下翻转因为屏幕的方向是固定的反了反而不合理。样本不均衡在工业缺陷检测里几乎必现。比如划伤很常见气泡很少见。如果训练集里划伤占了70%气泡只占1%模型大概率会把气泡漏检掉。应对方法有两种一是采样时按类别比例控制多用欠采样或过采样二是在训练时调整类别权重让稀有缺陷的loss占比更大。我建议两个都做前者是数据层面的兜底后者是训练层面的补偿。另外还有一个技巧值得尝试把正常样本也放一些进来训练但只用来做背景不标注目标。这能帮助模型学会“没有缺陷的时候不要乱框”对降低误检率很有帮助。2.3 训练参数配置与调优经验YOLOv8用ultralytics框架训练非常方便但默认参数是给COCO这种通用数据集准备的用在屏幕缺陷检测上需要做几个关键调整。我用的训练配置大概是这样的参数建议值说明modelyolov8s.pt先用s版本跑通后续按精度需求换m或limgsz640屏幕缺陷普遍较小如果资源允许可以试1280batch16或32看显卡显存12G显存建议batch16epochs100到150缺陷检测任务建议多训一些早停阈值设严一点lr00.01默认即可如果loss震荡就降到0.005mosaic1.0前期开最后10个epoch关掉patience20连续20轮没提升就早停optimizerAdamW比SGD收敛稳小数据集上表现更好我第一个版本直接拿yolov8s的默认epoch跑了50轮效果还行但不理想有些漏检。后来把epoch拉到150轮配合早停模型收敛得更充分mAP50从0.82提升到0.9以上。另外一个提升明显的操作是最后10个epoch关闭Mosaic增强这会让模型在真实分布上做精调精度能再涨一点。这里有个坑如果显存不够batch太小会导致BN层统计不稳定loss波动明显。解决方案是适当增大batch、降低输入分辨率或者直接用yolov8n这种小模型做实验。3. 系统实现三路检测模块的代码拆解3.1 环境准备与项目组织PyTorch和ultralytics的环境配置不算复杂但在项目里踩了几次坑之后我总结了一套相对稳的组合。Python版本建议3.9或3.10PyTorch装2.0以上ultralytics库直接用对应版本即可。CUDA版本要匹配显卡驱动我试过最省心的方式是先用CPU环境把代码跑通再切换到GPU环境这样至少能确保逻辑本身没问题。显式依赖关系大概是这样的pip install torch2.0 pip install ultralytics pip install opencv-python项目文件组织上我习惯把检测逻辑和界面逻辑分开。核心目录大致是weights目录放训练好的权重datasets目录放数据集scripts目录放训练和推理脚本utils目录放公共工具函数。这样后面做模型迭代的时候只需要替换weights文件不用动业务代码。3.2 图像检测单帧推理与结果可视化图像检测是最常用的功能主要用来做批量验证和缺陷报告。核心逻辑是加载模型、读取图片、推理、绘制结果、保存。代码框架如下from ultralytics import YOLO import cv2 model YOLO(weights/best.pt) img cv2.imread(test_images/screen_01.jpg) results model.predict(sourceimg, imgsz640, conf0.25, verboseFalse) for r in results: boxes r.boxes for box in boxes: cls_id int(box.cls) conf float(box.conf) x1, y1, x2, y2 [int(v) for v in box.xyxy[0]] label f{model.names[cls_id]} {conf:.2f} cv2.rectangle(img, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(img, label, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) cv2.imwrite(output/screen_result.jpg, img)这段代码看起来简单实际使用中有几个细节值得注意。conf阈值不能设得太低我一开始设了0.1结果误检框特别多大片无缺陷区域被画上红框产线工人看了直摇头。后来把conf提到0.25到0.35之间误检明显下降真正有缺陷的目标基本没有漏。还有一个经验如果单张图片很大比如手机的原始拍摄图是4000x3000像素直接用原图推理会很慢。可以先等比缩放到1280以内再做推理检测完再把检测框坐标映射回原图。这个处理在批量检测时能节省大量时间。3.3 视频检测帧序列处理与结果稳定性视频检测和图像检测的区别不只是多一个循环读帧还有帧率和稳定性的问题。视频检测的核心代码如下from ultralytics import YOLO import cv2 model YOLO(weights/best.pt) cap cv2.VideoCapture(test_videos/defect_01.mp4) out cv2.VideoWriter(output/defect_result.mp4, cv2.VideoWriter_fourcc(*mp4v), cap.get(cv2.CAP_PROP_FPS), (int(cap.get(cv2.CAP_PROP_WIDTH)), int(cap.get(cv2.CAP_PROP_HEIGHT)))) frame_id 0 while cap.isOpened(): ret, frame cap.read() if not ret: break if frame_id % 3 ! 0: # 抽帧处理间隔2帧跑一次推理 frame_id 1 continue results model.predict(frame, imgsz640, conf0.3, verboseFalse) annotated results[0].plot() out.write(annotated) frame_id 1 cap.release() out.release()这里我要强调一下跳帧策略。我当时做视频检测时追求画面流畅结果每帧都跑推理一个30秒的视频跑了七八分钟完全没有实用价值。后来改成每3帧抽1帧推理检测速度明显改善缺陷出现在帧间的概率也不高因为一个缺陷在视频里通常会持续十几帧不会一帧就消失。但是跳帧处理有一个副作用结果框会有轻微抖动。因为模型在每帧上的预测坐标不完全一致画面看起来有点跳。解决办法是在所有检测框上做一个轻量的均值滤波比如记录当前帧和历史5帧的坐标取平均之后绘制。这样画面就平稳很多。虽然理论上有极小的响应延迟但在工程上完全可接受。3.4 摄像头实时检测流式推理与延迟控制摄像头实时检测是这个项目里最有意思的部分也是真正接近产线场景的一环。核心逻辑是持续从摄像头读帧推理显示结果形成循环。大体代码如下from ultralytics import YOLO import cv2 model YOLO(weights/best.pt) cap cv2.VideoCapture(0) # 0代表默认摄像头产线上从RTSP地址读流 cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) while True: ret, frame cap.read() if not ret: break # 缩小后再推理降低延迟 small cv2.resize(frame, (640, 640)) results model.predict(small, imgsz640, conf0.3, verboseFalse) annotated results[0].plot() annotated cv2.resize(annotated, (1280, 720)) cv2.imshow(Screen Defect Detection, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()实际部署中摄像头实时检测的瓶颈往往不在模型推理本身而在视频流的读取和解码。我遇到过一种情况摄像头本身输出30帧但opencv的VideoCapture在Windows下读RTSP流时自带缓冲导致画面延迟非常明显屏幕上看到的画面比实际慢了一两秒。这在产线上是完全不能接受的因为操作员看到的是“过去”的画面根本没有参考意义。解决方案是用多线程或者专门做一个视频队列把读帧和推理解耦。读帧线程不断把新帧放入队列推理线程从队列里取帧处理这样可以减小读帧延迟对推理的影响。还有一个trick是每次读帧后主动丢弃队列中的旧帧保证处理的是最新画面实时性会好很多。4. 模型加速与部署优化4.1 权重导出与推理提速训练好的.pt权重可以在Python环境里直接推理但要做真正的项目部署尤其到产线边缘设备上跑效率还不够。我习惯把模型导出成ONNX格式再用ONNX Runtime进行推理速度通常能提升30%到50%。导出代码很简单model YOLO(weights/best.pt) model.export(formatonnx, imgsz640, opset12)导出时会提示一条警告信息大意是部分操作符在指定opset版本里不是最优实现一般不用管不影响精度。导出完可以在测试集上对比一下PyTorch推理和ONNX推理的结果正常情况下mAP差异应该在0.5%以内。如果发现ONNX推理精度明显下降常见原因是image shape变成了动态维度建议导出时固定shape或者用dynamicTrue导出并在推理时保持一致的输入尺寸。ONNX Runtime的推理API比直接调model.predict稍微麻烦一点但速度优势明显import onnxruntime as ort import numpy as np import cv2 session ort.InferenceSession(weights/best.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider]) img cv2.imread(test_images/screen_02.jpg) img cv2.resize(img, (640, 640)) img img[:, :, ::-1] # BGR转RGB img img.transpose(2, 0, 1) img np.ascontiguousarray(img) img img.astype(np.float32) / 255.0 img np.expand_dims(img, axis0) inputs {session.get_inputs()[0].name: img} outputs session.run(None, inputs)ONNX输出的原始tensor需要做后处理包括解码预测框、NMS过滤等这也是很多人认为ONNX推理“麻烦”的原因。不过好处是这一步可以完全掌控后处理逻辑针对特定缺陷类别做定制化处理比如过滤掉面积过小的框等。4.2 精度与速度的平衡策略做检测系统最终是要回答一个问题多少算力换多少精度是划算的。YOLOv8提供了n、s、m、l、x五个尺寸的模型在手机屏幕缺陷这个任务上我建议从s级开始验证而不是一上来就用x级。yolov8n确实很快CPU上都能跑得动但小模型对弱纹理和小目标的特征提取能力有限划伤这类细长缺陷容易被漏检。我之前在验证机上跑yolov8nmAP50只有0.78换成yolov8s直接跳到0.85。而yolov8l提升相对有限到0.88左右但推理时间增加了差不多一倍。对屏幕缺陷检测来说yolov8s是性价比很平衡的一个选择。如果算力允许可以尝试把输入分辨率从640提升到1280。实验结果显示对亮点、暗点和细小划伤这些小目标分辨率提升带来的召回率提升非常明显。但也别盲目上大分辨率显存占用和推理时间都会相应翻倍部署端不一定扛得住。5. 踩坑实录与排查手册5.1 检出率不高的系统性排查如果你训练出来的模型对某些缺陷总检不出来不要急着调参先按这个顺序排查一遍。第一看数据。这类缺陷的标注实例够不够如果只有几十个样本模型基本学不出来。第二看标注质量。标注框是紧贴目标还是偏大偏小如果标注得乱七八糟再好的模型也学不好。第三看增强策略。是不是把不合理的增强开得太猛导致训练集中缺陷形态被破坏第四看训练配置。epoch太短、学习率不合适、或者tensorboard里loss曲线根本没收敛都会导致效果不好。我遇到过最诡异的情况是某个类别的mAP是0也就是模型完全没检出。查了数据才发现训练集里这个类别的图片全部集中在某一天采集的当天打光角度和后续所有数据都不一样模型学到了那个特定光照下的模式换一个光照就废了。后面在数据采集时特意让产线师傅换了不同灯光环境重新采了一批问题才解决。这个案例说明工业场景里“数据代表性”比“数据量”更重要。5.2 误检多的分析与对策误检多和漏检多是两个相反的痛点。误检通常表现为明明没有缺陷模型画了一堆框。这种情况第一嫌疑是conf阈值太低。我建议把阈值提到0.35以上看看效果。如果阈值提高后误检还是多就要审视训练数据里是不是缺少正常的无缺陷样本。一个有效的做法是加入负样本训练。把没有缺陷的屏幕图也放进数据集但不做任何标注。模型在这些图上只会输出背景预测相当于学会了“没有目标时输出什么也不框”。我试过在数据集中加入15%左右的负样本误检率下降非常明显而且对漏检率几乎没有负面影响。还有一种误检属于“定位松动”比如屏幕边角的亮区容易被误判为污渍。这种通常可以通过后处理规则过滤掉。比如利用手机屏幕在图像中的位置通常是固定的特点把检测结果中在屏幕范围外的框过滤掉或者把面积过小、置信度偏低的框丢弃。5.3 实时性不足的瓶颈定位摄像头检测卡顿、视频检测太慢这类问题先定位瓶颈在哪一层再去优化不要盲目下结论。我习惯用分段计时的办法排查。先用time.time()分别统计读帧耗时、推理耗时、绘制耗时。很多时候你会惊讶地发现模型推理只占了一小半时间反而是opencv的imshow绘制和图像resize拖了后腿。把绘制分辨率降低、避免在每帧上做全尺寸的图形绘制效率可以提升不少。如果推理确实慢优先考虑换onnx推理、模型蒸馏或者换更小的模型。还有一点容易忽略摄像头读流本身如果用的是软解CPU占用本身就高留给模型推理的资源就更少了。有条件的话用支持硬解的摄像头或者直接用硬件解码管线整个系统的实时性会有本质提升。5.4 一个容易被忽视的问题光照与反光做手机屏幕缺陷检测最难的不是模型而是图像质量。屏幕是玻璃面板对光线极其敏感。不同的打光角度、光源亮度拍摄出的缺陷形态差异巨大。划伤在侧光下是一条白亮的线但在正面光下可能完全看不见亮点在水滴光斑的干扰下可能被误判为暗点。这个问题在数据层面无解必须从采集端入手。打光方案直接影响模型能发挥的上限。我在项目里和产线同事反复试了几种光源方案最终选的是低角度环光加漫射光的组合既能突出划伤和崩边又能保证整体亮度均匀模型表现比打光方案调整前好了不止一个档次。做工业检测项目的朋友一定要记住算法解决不了物理世界采不到的信息打光是检测系统里最值得花心思的地方。我个人在实际操作中的体会是一个完整的手机屏幕缺陷检测系统技术栈只是基础真正有价值的反而是那些踩过坑之后攒下来的工程判断。数据是否具备代表性、打光是不是稳定、推理链路有没有被无关操作拖慢、标注规范是不是所有人都在遵守——这些问题的答案决定了系统能不能从demo走向真正的产线使用。YOLOv8和PyTorch把模型训练和推理的门槛降得很低但把检测系统的整体表现做到让人放心需要的是对细节的耐心打磨。这个项目的代码结构把图像、视频、摄像头三种模式的检测链路都跑通了后面如果再扩展可以考虑加入缺陷分类的置信度统计、按缺陷类别输出检测报告、甚至把多个摄像头部署成分布式检测节点。方向很多先把核心系统做好就成功了大半。 
长河君 · 2026/10/20 19:55:57 · 阅读 1.2k 基于YOLOv8的手机屏幕缺陷检测系统：图像/视频/摄像头实时检测实战
做工业检测项目的时间长了你会发现手机屏幕质检是个特别典型的场景。产线上一天要过几千块屏划伤、亮点、暗斑、崩边这些缺陷全靠人眼盯师傅看久了眼睛吃力漏检率还不好控。我接触过不少做视觉的同行都在琢磨怎么把这块用算法接过来。今天聊的这个项目就是基于YOLOv8搭的一套手机屏幕缺陷检测系统支持图像、视频和摄像头实时检测PyTorch框架Python源码整体思路和踩坑记录都能直接复用。如果你也在做表面缺陷检测、工业质检或者类似的图像识别项目这篇内容值得认真看一遍。项目本身的边界很清楚不是做复杂的产线级MES系统而是把最核心的“检测能力”跑通——给一张图能标出缺陷的位置和类别给一段视频能逐帧分析接上摄像头能近乎实时地看到检测结果。这三个场景对应的是研发验证、离线批处理和产线试点的不同需求。整套代码用PyTorch实现模型基于YOLOv8训练和推理链路完整属于那种“拿到就能跑、改改就能用”的项目。1. 项目定位与核心思路拆解1.1 手机屏幕质检的典型场景与痛点手机屏幕的缺陷检测和普通零部件的缺陷检测还不一样。屏幕本身是玻璃加显示面板的复合结构透光、反光缺陷种类杂。常见的有划伤、亮点、暗点、污渍、气泡、崩边、色斑等。其中划伤和崩边这类外观缺陷靠轮廓和纹理特征能看出来亮暗点这类显示缺陷需要特定的打光方式才明显。这些缺陷的尺寸往往很小有的只有几个像素和背景对比度又很低传统的图像处理算法做起来非常痛苦——阈值分割可能今天调好明天就失效换一条产线又得重来。我见过很多做视觉的同学一上来就想着用opencv做预处理加形态学操作结果项目越做越复杂规则越堆越多最后维护成本完全失控。深度学习检测模型在这类场景下的优势很明显不需要手工设计特征只需要把不同状态的缺陷图喂给模型让它自己学习特征表达泛化能力也更好。而YOLO系列又是目前工业落地最成熟的检测框架之一速度够快、精度不差、部署方案完善用它来做手机屏幕缺陷检测是性价比非常高的选择。1.2 为什么选YOLOv8而不是更早的检测模型很多人会问为什么是YOLOv8不是Faster R-CNN也不是YOLOv5我的答案很直接工程落地图个省心。先说不选Faster R-CNN的原因。两阶段检测器精度确实高但速度是硬伤。在产线上或者说在摄像头实时检测场景下FPS达不到要求就是没法用。手机屏幕检测属于大批量、短节拍的应用检测一帧的耗时必须控制得住。YOLO这种一阶段方案把分类和定位统一回归速度直接翻几倍。再说YOLOv8相比YOLOv5的提升。v8把检测头换成了Anchor-Free结构不再需要预设锚框减少了一堆需要调的参数。C2f模块替换了原来的C3模块梯度流更丰富特征提取能力更强。训练过程也做了不少优化比如解耦头设计分类和回归分支分开收敛更快、精度也更稳。实际测下来在同样精度的前提下v8的模型体积和推理速度都比v5有优势。当然选YOLOv8还有一个现实原因PyTorch生态太成熟了。ultralytics官方仓库把训练、验证、导出、部署的链路都打通了模型文件一个.pt搞定导出ONNX也就一行命令。对于做项目交付的人来说没有比这更省事的了。1.3 图像、视频、摄像头三类检测的架构差异这个项目最大的特点就是检测入口多图像、视频、摄像头。很多人一开始不理解觉得不就是换一个数据来源嘛实际上差得远了。图像检测是最简单的。读一张图推理一次出结果。核心关注点是推理速度、精度、可视化效果。视频检测就不一样了。视频本质上是一帧一帧的图片序列但帧之间有时间连续性处理逻辑要考虑抽帧频率、逐帧还是跳帧、是否做结果平滑。如果每帧全量推理算力消耗大如果跳帧太多又会漏掉一闪而过的缺陷。这里需要根据实际场景平衡。摄像头实时检测是难度最高的。因为它是连续的视频流而且是无限长的流内存管理、帧缓冲、延迟控制都要考虑。摄像头检测不能像图像检测那样一次性读入再处理也不能像视频处理那样可以离线慢慢算它必须在一个生产-消费模型里不断循环。更关键的是延迟。产线上如果算法处理一帧要200毫秒那屏幕上看到的画面就有明显的卡顿感操作体验会很差。所以这个项目的代码里三路检测并不是简单复用一个函数而是各自有独立的处理流程但又共享同一个推理核心。这也是我在设计时比较满意的一点模型只有一个接口统一但适配不同场景的吞吐需求。2. 缺陷定义、数据准备与模型训练的关键细节2.1 屏幕缺陷的常见类型与标注建议做检测项目第一步永远是定义清楚“到底要检测什么”。这个项目里我建议把缺陷类别控制在5到8类不要贪多。类别太多样本收集压力大模型也容易混淆。实际项目里常用的类别划分是这样的缺陷类别特征描述标注建议划伤(scratch)细长亮线方向不规则用多边形或矩形紧贴缺陷区域不要包含正常纹理亮点(bright_spot)局部高亮圆点矩形框略收缩避免把光晕包含进来暗点(dark_spot)局部亮度偏低的小点标注最小外接框即可污渍(stain)片状脏污边界模糊尽量贴近实际轮廓不要框得太大崩边(chip)玻璃边缘缺损沿破损边缘标注标注框可稍微外扩气泡(bubble)圆形或椭圆形透亮区域按实际形状标注重叠气泡建议分开框这里有一个很重要的标注原则标注框宁可稍微紧一点也不要松。因为YOLO这类目标检测模型对目标位置的回归是基于边界框的如果框得太松模型学到的是“大概那块区域有缺陷”位置精度会下降后续做坐标统计或者固定检测位的时候误差会很大。我在项目初期就吃过这个亏标注员为了省事每个框都往外扩了一圈看起来没啥大问题但模型训练出来之后在精度评估里AP值掉了好几个点后来重新规范标注才拉回来。还有一个容易被忽视的点一张图里有多个缺陷是正常的不要嫌多就把小的过滤掉。尤其是亮点和暗点这类小目标本身尺寸就小样本已经很难收集了标注的时候再漏几个那模型基本就学不到这类特征了。数据集规模方面我个人的经验是每类缺陷至少要有200到500个标注实例。手机屏幕的缺陷样本不太好收集产线上不良品本来就不多。当时项目里的做法是先把历史积累的缺陷图全部翻出来能标注的尽量标再配合数据增强把规模扩大。如果原始样本实在不够可以考虑先用公开的表面缺陷数据集做预训练然后在自己的数据上微调效果会比直接小样本训练好很多。2.2 数据增强与样本均衡策略屏幕缺陷检测的数据增强和通用目标检测的增强逻辑不太一样。不能盲目地做随机旋转和随机裁剪因为屏幕图像有固定的方向性划伤横向和纵向的视觉形态是不一样的90度旋转或者水平翻转会改变缺陷的形态语义干扰模型学习。我在项目里实际采用的增强策略是这样的亮度对比度调整。屏幕缺陷和光照关系很大模拟不同打光条件下的亮度变化帮助模型学出更鲁棒的特征。轻微模糊与噪声。模拟传感器噪声和聚焦不准的情况增加模型对画质下降的容忍度。随机缩放与平移。模拟不同分辨率下缺陷的尺度差异这个对小目标检测特别有用。Mosaic增强。ultralytics默认会开Mosaic把四张图拼成一张可以显著增加样本多样性对提高小目标检出效果帮助很大。但不做90度旋转和上下翻转因为屏幕的方向是固定的反了反而不合理。样本不均衡在工业缺陷检测里几乎必现。比如划伤很常见气泡很少见。如果训练集里划伤占了70%气泡只占1%模型大概率会把气泡漏检掉。应对方法有两种一是采样时按类别比例控制多用欠采样或过采样二是在训练时调整类别权重让稀有缺陷的loss占比更大。我建议两个都做前者是数据层面的兜底后者是训练层面的补偿。另外还有一个技巧值得尝试把正常样本也放一些进来训练但只用来做背景不标注目标。这能帮助模型学会“没有缺陷的时候不要乱框”对降低误检率很有帮助。2.3 训练参数配置与调优经验YOLOv8用ultralytics框架训练非常方便但默认参数是给COCO这种通用数据集准备的用在屏幕缺陷检测上需要做几个关键调整。我用的训练配置大概是这样的参数建议值说明modelyolov8s.pt先用s版本跑通后续按精度需求换m或limgsz640屏幕缺陷普遍较小如果资源允许可以试1280batch16或32看显卡显存12G显存建议batch16epochs100到150缺陷检测任务建议多训一些早停阈值设严一点lr00.01默认即可如果loss震荡就降到0.005mosaic1.0前期开最后10个epoch关掉patience20连续20轮没提升就早停optimizerAdamW比SGD收敛稳小数据集上表现更好我第一个版本直接拿yolov8s的默认epoch跑了50轮效果还行但不理想有些漏检。后来把epoch拉到150轮配合早停模型收敛得更充分mAP50从0.82提升到0.9以上。另外一个提升明显的操作是最后10个epoch关闭Mosaic增强这会让模型在真实分布上做精调精度能再涨一点。这里有个坑如果显存不够batch太小会导致BN层统计不稳定loss波动明显。解决方案是适当增大batch、降低输入分辨率或者直接用yolov8n这种小模型做实验。3. 系统实现三路检测模块的代码拆解3.1 环境准备与项目组织PyTorch和ultralytics的环境配置不算复杂但在项目里踩了几次坑之后我总结了一套相对稳的组合。Python版本建议3.9或3.10PyTorch装2.0以上ultralytics库直接用对应版本即可。CUDA版本要匹配显卡驱动我试过最省心的方式是先用CPU环境把代码跑通再切换到GPU环境这样至少能确保逻辑本身没问题。显式依赖关系大概是这样的pip install torch2.0 pip install ultralytics pip install opencv-python项目文件组织上我习惯把检测逻辑和界面逻辑分开。核心目录大致是weights目录放训练好的权重datasets目录放数据集scripts目录放训练和推理脚本utils目录放公共工具函数。这样后面做模型迭代的时候只需要替换weights文件不用动业务代码。3.2 图像检测单帧推理与结果可视化图像检测是最常用的功能主要用来做批量验证和缺陷报告。核心逻辑是加载模型、读取图片、推理、绘制结果、保存。代码框架如下from ultralytics import YOLO import cv2 model YOLO(weights/best.pt) img cv2.imread(test_images/screen_01.jpg) results model.predict(sourceimg, imgsz640, conf0.25, verboseFalse) for r in results: boxes r.boxes for box in boxes: cls_id int(box.cls) conf float(box.conf) x1, y1, x2, y2 [int(v) for v in box.xyxy[0]] label f{model.names[cls_id]} {conf:.2f} cv2.rectangle(img, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(img, label, (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) cv2.imwrite(output/screen_result.jpg, img)这段代码看起来简单实际使用中有几个细节值得注意。conf阈值不能设得太低我一开始设了0.1结果误检框特别多大片无缺陷区域被画上红框产线工人看了直摇头。后来把conf提到0.25到0.35之间误检明显下降真正有缺陷的目标基本没有漏。还有一个经验如果单张图片很大比如手机的原始拍摄图是4000x3000像素直接用原图推理会很慢。可以先等比缩放到1280以内再做推理检测完再把检测框坐标映射回原图。这个处理在批量检测时能节省大量时间。3.3 视频检测帧序列处理与结果稳定性视频检测和图像检测的区别不只是多一个循环读帧还有帧率和稳定性的问题。视频检测的核心代码如下from ultralytics import YOLO import cv2 model YOLO(weights/best.pt) cap cv2.VideoCapture(test_videos/defect_01.mp4) out cv2.VideoWriter(output/defect_result.mp4, cv2.VideoWriter_fourcc(*mp4v), cap.get(cv2.CAP_PROP_FPS), (int(cap.get(cv2.CAP_PROP_WIDTH)), int(cap.get(cv2.CAP_PROP_HEIGHT)))) frame_id 0 while cap.isOpened(): ret, frame cap.read() if not ret: break if frame_id % 3 ! 0: # 抽帧处理间隔2帧跑一次推理 frame_id 1 continue results model.predict(frame, imgsz640, conf0.3, verboseFalse) annotated results[0].plot() out.write(annotated) frame_id 1 cap.release() out.release()这里我要强调一下跳帧策略。我当时做视频检测时追求画面流畅结果每帧都跑推理一个30秒的视频跑了七八分钟完全没有实用价值。后来改成每3帧抽1帧推理检测速度明显改善缺陷出现在帧间的概率也不高因为一个缺陷在视频里通常会持续十几帧不会一帧就消失。但是跳帧处理有一个副作用结果框会有轻微抖动。因为模型在每帧上的预测坐标不完全一致画面看起来有点跳。解决办法是在所有检测框上做一个轻量的均值滤波比如记录当前帧和历史5帧的坐标取平均之后绘制。这样画面就平稳很多。虽然理论上有极小的响应延迟但在工程上完全可接受。3.4 摄像头实时检测流式推理与延迟控制摄像头实时检测是这个项目里最有意思的部分也是真正接近产线场景的一环。核心逻辑是持续从摄像头读帧推理显示结果形成循环。大体代码如下from ultralytics import YOLO import cv2 model YOLO(weights/best.pt) cap cv2.VideoCapture(0) # 0代表默认摄像头产线上从RTSP地址读流 cap.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) while True: ret, frame cap.read() if not ret: break # 缩小后再推理降低延迟 small cv2.resize(frame, (640, 640)) results model.predict(small, imgsz640, conf0.3, verboseFalse) annotated results[0].plot() annotated cv2.resize(annotated, (1280, 720)) cv2.imshow(Screen Defect Detection, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()实际部署中摄像头实时检测的瓶颈往往不在模型推理本身而在视频流的读取和解码。我遇到过一种情况摄像头本身输出30帧但opencv的VideoCapture在Windows下读RTSP流时自带缓冲导致画面延迟非常明显屏幕上看到的画面比实际慢了一两秒。这在产线上是完全不能接受的因为操作员看到的是“过去”的画面根本没有参考意义。解决方案是用多线程或者专门做一个视频队列把读帧和推理解耦。读帧线程不断把新帧放入队列推理线程从队列里取帧处理这样可以减小读帧延迟对推理的影响。还有一个trick是每次读帧后主动丢弃队列中的旧帧保证处理的是最新画面实时性会好很多。4. 模型加速与部署优化4.1 权重导出与推理提速训练好的.pt权重可以在Python环境里直接推理但要做真正的项目部署尤其到产线边缘设备上跑效率还不够。我习惯把模型导出成ONNX格式再用ONNX Runtime进行推理速度通常能提升30%到50%。导出代码很简单model YOLO(weights/best.pt) model.export(formatonnx, imgsz640, opset12)导出时会提示一条警告信息大意是部分操作符在指定opset版本里不是最优实现一般不用管不影响精度。导出完可以在测试集上对比一下PyTorch推理和ONNX推理的结果正常情况下mAP差异应该在0.5%以内。如果发现ONNX推理精度明显下降常见原因是image shape变成了动态维度建议导出时固定shape或者用dynamicTrue导出并在推理时保持一致的输入尺寸。ONNX Runtime的推理API比直接调model.predict稍微麻烦一点但速度优势明显import onnxruntime as ort import numpy as np import cv2 session ort.InferenceSession(weights/best.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider]) img cv2.imread(test_images/screen_02.jpg) img cv2.resize(img, (640, 640)) img img[:, :, ::-1] # BGR转RGB img img.transpose(2, 0, 1) img np.ascontiguousarray(img) img img.astype(np.float32) / 255.0 img np.expand_dims(img, axis0) inputs {session.get_inputs()[0].name: img} outputs session.run(None, inputs)ONNX输出的原始tensor需要做后处理包括解码预测框、NMS过滤等这也是很多人认为ONNX推理“麻烦”的原因。不过好处是这一步可以完全掌控后处理逻辑针对特定缺陷类别做定制化处理比如过滤掉面积过小的框等。4.2 精度与速度的平衡策略做检测系统最终是要回答一个问题多少算力换多少精度是划算的。YOLOv8提供了n、s、m、l、x五个尺寸的模型在手机屏幕缺陷这个任务上我建议从s级开始验证而不是一上来就用x级。yolov8n确实很快CPU上都能跑得动但小模型对弱纹理和小目标的特征提取能力有限划伤这类细长缺陷容易被漏检。我之前在验证机上跑yolov8nmAP50只有0.78换成yolov8s直接跳到0.85。而yolov8l提升相对有限到0.88左右但推理时间增加了差不多一倍。对屏幕缺陷检测来说yolov8s是性价比很平衡的一个选择。如果算力允许可以尝试把输入分辨率从640提升到1280。实验结果显示对亮点、暗点和细小划伤这些小目标分辨率提升带来的召回率提升非常明显。但也别盲目上大分辨率显存占用和推理时间都会相应翻倍部署端不一定扛得住。5. 踩坑实录与排查手册5.1 检出率不高的系统性排查如果你训练出来的模型对某些缺陷总检不出来不要急着调参先按这个顺序排查一遍。第一看数据。这类缺陷的标注实例够不够如果只有几十个样本模型基本学不出来。第二看标注质量。标注框是紧贴目标还是偏大偏小如果标注得乱七八糟再好的模型也学不好。第三看增强策略。是不是把不合理的增强开得太猛导致训练集中缺陷形态被破坏第四看训练配置。epoch太短、学习率不合适、或者tensorboard里loss曲线根本没收敛都会导致效果不好。我遇到过最诡异的情况是某个类别的mAP是0也就是模型完全没检出。查了数据才发现训练集里这个类别的图片全部集中在某一天采集的当天打光角度和后续所有数据都不一样模型学到了那个特定光照下的模式换一个光照就废了。后面在数据采集时特意让产线师傅换了不同灯光环境重新采了一批问题才解决。这个案例说明工业场景里“数据代表性”比“数据量”更重要。5.2 误检多的分析与对策误检多和漏检多是两个相反的痛点。误检通常表现为明明没有缺陷模型画了一堆框。这种情况第一嫌疑是conf阈值太低。我建议把阈值提到0.35以上看看效果。如果阈值提高后误检还是多就要审视训练数据里是不是缺少正常的无缺陷样本。一个有效的做法是加入负样本训练。把没有缺陷的屏幕图也放进数据集但不做任何标注。模型在这些图上只会输出背景预测相当于学会了“没有目标时输出什么也不框”。我试过在数据集中加入15%左右的负样本误检率下降非常明显而且对漏检率几乎没有负面影响。还有一种误检属于“定位松动”比如屏幕边角的亮区容易被误判为污渍。这种通常可以通过后处理规则过滤掉。比如利用手机屏幕在图像中的位置通常是固定的特点把检测结果中在屏幕范围外的框过滤掉或者把面积过小、置信度偏低的框丢弃。5.3 实时性不足的瓶颈定位摄像头检测卡顿、视频检测太慢这类问题先定位瓶颈在哪一层再去优化不要盲目下结论。我习惯用分段计时的办法排查。先用time.time()分别统计读帧耗时、推理耗时、绘制耗时。很多时候你会惊讶地发现模型推理只占了一小半时间反而是opencv的imshow绘制和图像resize拖了后腿。把绘制分辨率降低、避免在每帧上做全尺寸的图形绘制效率可以提升不少。如果推理确实慢优先考虑换onnx推理、模型蒸馏或者换更小的模型。还有一点容易忽略摄像头读流本身如果用的是软解CPU占用本身就高留给模型推理的资源就更少了。有条件的话用支持硬解的摄像头或者直接用硬件解码管线整个系统的实时性会有本质提升。5.4 一个容易被忽视的问题光照与反光做手机屏幕缺陷检测最难的不是模型而是图像质量。屏幕是玻璃面板对光线极其敏感。不同的打光角度、光源亮度拍摄出的缺陷形态差异巨大。划伤在侧光下是一条白亮的线但在正面光下可能完全看不见亮点在水滴光斑的干扰下可能被误判为暗点。这个问题在数据层面无解必须从采集端入手。打光方案直接影响模型能发挥的上限。我在项目里和产线同事反复试了几种光源方案最终选的是低角度环光加漫射光的组合既能突出划伤和崩边又能保证整体亮度均匀模型表现比打光方案调整前好了不止一个档次。做工业检测项目的朋友一定要记住算法解决不了物理世界采不到的信息打光是检测系统里最值得花心思的地方。我个人在实际操作中的体会是一个完整的手机屏幕缺陷检测系统技术栈只是基础真正有价值的反而是那些踩过坑之后攒下来的工程判断。数据是否具备代表性、打光是不是稳定、推理链路有没有被无关操作拖慢、标注规范是不是所有人都在遵守——这些问题的答案决定了系统能不能从demo走向真正的产线使用。YOLOv8和PyTorch把模型训练和推理的门槛降得很低但把检测系统的整体表现做到让人放心需要的是对细节的耐心打磨。这个项目的代码结构把图像、视频、摄像头三种模式的检测链路都跑通了后面如果再扩展可以考虑加入缺陷分类的置信度统计、按缺陷类别输出检测报告、甚至把多个摄像头部署成分布式检测节点。方向很多先把核心系统做好就成功了大半。