简介YOLOv8玻璃缺陷检测源码包面向深度学习开发者与工业视觉质检场景聚焦玻璃表面点状缺陷、划痕缺陷和擦伤缺陷三类目标检测任务。基于YOLOv8框架整套代码涵盖环境依赖配置、data.yaml标签文件创建、预训练模型调用、训练参数调整以及模型性能评估等环节并附带基于PyQt5的图形界面支持直接上传图像查看缺陷框选结果兼顾算法学习与工程落地。资源包共7个文件以Python训练脚本、GUI脚本、YAML配置及依赖清单为主体另有.gitignore与项目配置文件其中训练脚本对应数据准备到模型导出的完整流程GUI脚本提供交互式检测可视化YAML定义类别与数据路径txt列出运行环境依赖结构清晰压缩包仅10KB下载后即可对照学习。数据集包含8000张标注图片覆盖三类缺陷配套create_sample_dataset.py可生成样例数据辅助验证帮助快速理解YOLOv8在工业质检中的实践逻辑。目前已有98人学习下载尤其适合希望快速跑通缺陷检测原型、或系统学习目标检测流程的开发者。1. 玻璃缺陷检测为什么用 YOLOv8黑匣子之外的完整落地链路玻璃产线上的缺陷检测是个比想象中更刁钻的深度学习目标检测场景。透明材质、反光干扰、缺陷尺度差异大——气泡、划痕、杂质、裂纹甚至只有几十个像素的麻点都在一条高速产线上混着出现。很多团队试过传统图像处理阈值分割在半透明背景下经常翻车转向深度学习后又发现单张图里目标小、数量多、正负样本极不平衡通用目标检测模型直接套上去漏检率高得没法用。这套 YOLOv8玻璃缺陷检测可运行源码解决的就是这个具体问题它把 YOLOv8 目标检测、玻璃缺陷数据标注、训练配置、推理部署串成一条能直接跑通的链路。适合两类人一是刚接触深度学习目标检测的学生需要一个完整项目作为入门抓手二是产线或质检设备相关从业者想快速评估 YOLOv8 在玻璃缺陷场景下的真实表现而不是从头搭环境、写脚本。2. 为什么选 YOLOv8 做玻璃缺陷检测从模型结构到源码包结构2.1 YOLOv8 在透明材质检测上的三个结构优势玻璃缺陷检测和其他目标检测任务最大的区别在于背景本身是半透明甚至全透明的。普通物体检测模型学到的纹理特征在玻璃场景下大概率会学歪——模型容易把背景里的灰尘、光照不均的阴影当成缺陷同时漏掉真正细小的划痕。YOLOv8 能在这个场景里站住脚结构上有三个具体原因。第一Anchor-Free 的检测头设计。YOLOv8 取消了预设锚框检测头直接回归目标中心点和宽高。玻璃缺陷尤其是微小划痕和气泡长宽比极度不稳定用固定的 anchor 策略很容易产生大量负样本Anchor-Free 让模型对极端长宽比目标更友好这是它在小目标、异形目标上比 YOLOv5 更稳的原因。第二C2f 模块替换了 C3 模块。C2f 借鉴了 ELAN 的思路在特征融合时保留了更多梯度流分支浅层特征能被更充分地利用。玻璃缺陷里真正要命的是小目标——一个 30 像素的夹杂颗粒在深层特征图上可能只剩一个点。C2f 的特征复用机制对小目标召回率有实打实的提升。第三Decoupled Head 的分类与回归分离。YOLOv8 把分类和回归分支彻底解耦避免两个任务在训练时互相干扰。玻璃缺陷场景里划痕和裂纹在形态上非常接近分类分支需要更强的判别力解耦头让分类分支能更专注地学类别差异而不是被框回归的损失干扰。这些结构上的特性决定了 YOLOv8 是比较适合玻璃缺陷场景的起步模型。它不是精度天花板但它是性价比最稳的那一档——训练速度快、能吃不同来源的数据、部署生态成熟。2.2 源码包内部结构六个模块各管哪一段拿到这份可运行源码第一件事不是打开 README 从头读而是先看目录结构。合理的检测项目源码包一定有清晰的分层。这套包的模块划分大致遵循下面的逻辑glass_defect_yolov8/ ├── data/ # 数据预处理与增强 │ ├── split_dataset.py # 按缺陷分布划分训练/验证/测试集 │ └── check_labels.py # 检查标签越界、空标注、类别错误 ├── datasets/ │ ├── images/train/ # 训练图像 │ ├── images/val/ # 验证图像 │ ├── labels/train/ # 训练标签YOLO txt格式 │ └── labels/val/ # 验证标签 ├── configs/ │ ├── glass_defect.yaml # 数据集路径与类别配置 │ └── train_args.yaml # 训练超参数配置 ├── models/ # 预训练权重存放目录 ├── scripts/ │ ├── train.py # 训练入口脚本 │ ├── inference.py # 单图/批量推断脚本 │ └── export_onnx.py # 导出部署格式 ├── utils/ │ ├── metrics.py # 按类别计算AP、召回率的辅助工具 │ └── visualize.py # 检测结果可视化 └── requirements.txt我一般会在拿到任何源码包后先做两件事第一把 requirements.txt 里的版本约束通读一遍判断它基于哪个年代的依赖生态第二跑一遍 check_labels.py先确认数据和标签是干净的再谈训练。这个包这两点都考虑到了它把数据检查和可视化工具单独拆出来说明这不是随手拼的 demo而是有人真在产线数据上磨过。2.3 环境配置的实操顺序先把虚拟环境隔离干净环境配置是新手第一阶段最容易卡住的地方也是老手最容易踩坑的地方——版本冲突的根源几乎都是全局环境太脏。我建议严格按照下面的顺序操作# 1. 创建独立虚拟环境Python 版本优先选 3.10 或 3.11 conda create -n glass_yolov8 python3.11 -y conda activate glass_yolov8 # 2. 先安装 PyTorch再安装 ultralytics顺序不能反 # 如果机器有 NVIDIA 显卡先确认驱动支持 CUDA 11.8 或 12.1 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics # 3. 安装辅助依赖 pip install opencv-python albumentations onnxruntime为什么先装 PyTorch 再装 ultralytics因为 ultralytics 库在安装时会校验 torch 是否已存在并匹配其依赖约束如果先装 ultralyticspip 会自动拉一个默认版本的 torch很可能和你显卡的 CUDA 版本对不上后面推理时就会报“CUDA unavailable”。GPU 不可用时训练速度会慢到让人怀疑人生。这里有个关键参数值得说明--index-url指向的是 PyTorch 官方 wheel 源cu118 表示 CUDA 11.8 对应的预编译版本。如果你的显卡驱动只支持 CUDA 12.x把这个参数改成 cu121 再装。不要试图装一个 CUDA 版本高于驱动支持的 torch否则运行时会直接报错。装完环境后先跑一个极简的验证脚本确认环境无误再进入数据准备阶段。这一步能省掉后面至少三个小时的排查时间。提示如果你用的是 Apple Silicon 的 Mac也可以用pip install torch torchvision直接装 MPS 版本训练速度比 CPU 快但推理延迟会比 NVIDIA 显卡高不少。玻璃缺陷检测这类产线场景最终还是建议在 GPU 机器上跑。3. 玻璃缺陷数据集怎么喂给 YOLOv8标签格式与三个高发错误3.1 缺陷类别定义与标注边界先把标准定死数据标注是玻璃缺陷检测里最玄学的环节因为不同的人对“缺陷”边界的理解完全不一样。一套标准的标注规范至少要把四类问题定死。缺陷类型标注边界定义典型误标情况气泡圆形/椭圆形内部与周围有明显灰度差把背景的灰尘误标成气泡划痕细长条状长度大于 5 像素有明显方向性把玻璃表面的水渍纹误标成划痕杂质颗粒状灰度不均匀边缘模糊把反光点误标成杂质裂纹条状但伴随分叉长度通常大于 20 像素把两条相邻划痕合成一个大框最理想的做法是协议约标至少两个人标同一批图看标注一致性。一致性能到 90% 以上再放开标注否则训练出来的模型就是在一堆矛盾标签上拟合。这套源码包里虽然没有标注工具但它的 check_labels.py 支持检查类别编号是否符合 config这一点能在起步阶段筛掉不少低级错误。3.2 标注转 YOLO 格式转换脚本与归一化参数细节YOLOv8 的标签格式是每个图像对应一个 txt 文件每一行代表一个目标class_id center_x center_y width height注意这里的 center_x、center_y、width、height 全部是相对于图像宽高的归一化坐标取值在 0 到 1 之间。很多人第一次写转换脚本时容易把坐标保留成像素绝对值导致训练时检测框全飞到图像角落。import os import cv2 def convert_labelme_to_yolo(labelme_path, image_dir, output_dir, class_map): labelme 标注转 YOLO txt 格式 class_map: {bubble: 0, scratch: 1, inclusion: 2, crack: 3} os.makedirs(output_dir, exist_okTrue) for json_file in os.listdir(labelme_path): if not json_file.endswith(.json): continue img_name json_file.replace(.json, .jpg) img cv2.imread(os.path.join(image_dir, img_name)) if img is None: print(f图像读取失败{img_name}) continue h, w img.shape[:2] txt_path os.path.join(output_dir, json_file.replace(.json, .txt)) label_map parse_labelme_json(os.path.join(labelme_path, json_file)) with open(txt_path, w, encodingutf-8) as f: for annotation in label_map: class_id class_map.get(annotation[label]) if class_id is None: print(f未知类别{annotation[label]}跳过) continue # 像素坐标转归一化坐标 cx (annotation[x1] annotation[x2]) / 2 / w cy (annotation[y1] annotation[y2]) / 2 / h box_w (annotation[x2] - annotation[x1]) / w box_h (annotation[y2] - annotation[y1]) / h # 越界裁剪防止标注框超出图像范围 cx max(0.0, min(1.0, cx)) cy max(0.0, min(1.0, cy)) box_w max(0.0, min(1.0, box_w)) box_h max(0.0, min(1.0, box_h)) f.write(f{class_id} {cx:.6f} {cy:.6f} {box_w:.6f} {box_h:.6f}\n) print(转换完成)这段代码里的几个参数值得反复琢磨cx (x1 x2) / 2 / w先把两个端点的像素坐标转成归一化坐标再除以 2 得到中心点box_w (x2 - x1) / w是框宽占图像宽度的比例。最后做一次越界裁剪是为了防止标注框超出图像边界——如果标签里的坐标大于 1YOLOv8 训练时会直接报错或者在某些版本里静默地产生 NaN loss。3.3 数据集划分按缺陷分布划分别按目录随手切很多人在划分数据集时习惯直接按目录比例随机切比如 train 70% / val 30%这在普通分类任务里问题不大。但玻璃缺陷数据有一个显著特点不同类型缺陷的出现频率极不均衡。划痕可能占了 70%裂纹可能只有 3%。如果随手切验证集里可能一条裂纹都没有模型 val 阶段的 mAP 看着挺高但实际产线上裂纹一个都检不出来。这套源码包里的 split_dataset.py 正是针对这个问题做的它先统计每一类缺陷在样本中的分布再按缺陷类别做分层抽样。用法大致如下# 按图像数量分层抽样保证每个类别在验证集中都有占比 python data/split_dataset.py \ --label_dir datasets/labels/all \ --image_dir datasets/images/all \ --val_ratio 0.2 \ --seed 42关键参数是--seed 42。我在实际项目中吃过不固定随机种子的亏两次训练之间只改了某个无关参数结果精度波动了 3 个百分点很难判断是参数带来的提升还是数据划分差异带来的噪声。固定种子后数据划分结果可复现后面做的任何对比实验都更有说服力。注意分层抽样的核心原则是验证集的类别分布要和训练集一致并且每类缺陷在验证集里至少有 10 个以上实例。如果某一类缺陷实在太少宁可先去采集或合成补充也不要让这类缺陷在验证集里裸奔。4. 训练配置与调参六个关键参数定生死4.1 预训练权重怎么选yolov8n 起步s/m 做强度训练玻璃缺陷检测模型的第一步是决定用哪个预训练权重。源码包里的 models 目录预留了 yolov8n、yolov8s、yolov8m 三种权重的位置这个设计是合理的——先用轻量模型把链路打通再逐步加大模型。# 先跑通链路yolov8n 训练 50 轮 yolo detect train \ modelyolov8n.pt \ dataconfigs/glass_defect.yaml \ epochs50 \ batch16 \ imgsz640 \ device0 \ project./runs \ nameglass_n_50为什么第一个实验建议从 n 开始因为模型越小对数据量、标签质量、学习率设置的容错度越高。产线上的玻璃缺陷数据往往刚开始只有几百张图一上来就用 m 模型很容易过拟合——训练集 loss 一路走低验证集 mAP 纹丝不动典型的过拟合信号。等 n 模型能稳定跑出非零的验证集 mAP再换成 s 或者 m。判断标准是如果模型在验证集上的召回率明显偏低而且你有充足的数据量就值得加大模型如果召回率尚可但推理速度不达标反而应该考虑轻量化而不是加大。4.2 批次大小与图像尺寸显存不够时的降级策略训练阶段的 batch 和 imgsz 是显存消耗最大的两个参数它们之间是乘积关系。玻璃缺陷里的小目标比较依赖大图像尺寸但显存有限时优先保 imgsz 而不是 batch——因为小目标在低分辨率下甚至会丢失像素信息这是数据层面解决不了的问题。单卡 12GB 显存我一般这么配模型imgszbatch显存占用估算yolov8n64064约 6GByolov8n128016约 10GByolov8s64032约 8GByolov8s12808约 10GB重点解释一下 imgsz1280 的含义这个参数不只在训练时生效推理时也会默认用同样的尺寸去推断。图像分辨率提高后模型能看到更多小缺陷细节在玻璃缺陷这种小目标占比高的场景下从 640 提到 1280 往往比换更大的模型带来的提升更明显。但代价是训练和推理速度都慢将近一倍。如果显存只有 6GB用下面的降级策略yolo detect train \ modelyolov8n.pt \ dataconfigs/glass_defect.yaml \ epochs100 \ batch8 \ imgsz960 \ device0 \ fraction0.8fraction0.8的意思是只使用训练集的 80% 来做梯度更新效果近似于缩小有效 batch size同时保留数据多样性。这是显存受限时一个很实用的折中手段——比直接砍 batch 到 4 要稳因为过小的 batch 会导致 BatchNorm 统计量抖动训练过程容易不稳定。4.3 早停、学习率与数据增强训练日志里该盯哪些指标很多人的训练过程是“丢进去就不管了”等几十个小时候收结果发现结果不理想又不知道问题出在哪。我习惯在前 10 轮就把训练日志里的关键曲线看一遍。# 训练完成后查看训练曲线 tensorboard --logdir runs/glass_n_50重点关注三个信号。第一个是loss 曲线是否出现震荡如果 train_loss 在前 10 轮内出现明显上升再下降说明学习率太大或数据里有脏标签优先排查标签质量。第二个是验证集 mAP50 和 mAP50-95 的差距两者差距大说明模型的框定位精度不够考虑加大 imgsz两者都低说明模型欠拟合考虑加大模型或增加训练轮数。第三个是EarlyStopping 是否过早触发# configs/train_args.yaml 中早停相关配置 early_stop_patience: 20 # 连续 20 轮验证集无提升就停止 early_stop_min_delta: 0.001 # 最小提升阈值低于该值视为无提升如果 patience 设得太小比如 10而数据增强比较激进验证集 mAP 波动大特别容易在真正收敛前就提前停止。我习惯把 patience 设为 20 到 30给模型充分的收敛空间。数据增强方面YOLOv8 默认开启的增强对自然图像比较友好但对玻璃场景有两个问题一是过强的颜色增强会让玻璃的反光特征变得不真实二是随机裁剪可能把缺陷切成残缺形态干扰小目标学习。这套源码包里的 train_args.yaml 通常可以关掉部分增强hsv_h: 0.01 # 色相扰动调低玻璃场景颜色变化本身不大 hsv_s: 0.2 # 饱和度扰动适当降低 degrees: 0.0 # 角度旋转建议关掉产线上玻璃位置固定不需要旋转增强 fliplr: 0.0 # 左右翻转看情况气泡/划痕翻转后物理含义不变可以用来增广这里的关键认知是数据增强不是开得越多越好而是要让增强后的数据仍然符合目标场景的物理分布。产线上的玻璃角度固定、光照相对稳定做过度的旋转和颜色扰动等于强迫模型去学习与现实不符的特征。5. 玻璃缺陷项目常见的五个坑与排障记录5.1 训练初期 loss 突然变成 NaN现象训练到第 3 到 8 轮时loss 突然从正常值掉到 NaN后续所有轮次都是 NaN。原因绝大多数情况是标签里有非法值——某个 txt 文件里出现负数坐标或者类别 id 超过了数据集配置里的 class number。另一个常见原因是学习率太高尤其在使用大模型加小 batch 时优化器更新步长过大直接导致梯度爆炸。解决先跑一遍 check_labels.py 检查所有标签重点看坐标是否在 0 到 1 范围内。然后确认配置文件里的 nc类别数量是否与标签里的最大类号匹配。最后把学习率降到lr00.005再跑一次。这三个动作按顺序排查能解决 95% 以上的 NaN 问题。5.2 模型把背景反光当成缺陷现象训练完成后推理检测框大量落在玻璃边缘的高光区域而真正的细小划痕反而没有框。原因训练数据里包含大量反光区域但标注者没有把这些反光标注为背景类模型在监督信号里看到的就是“这些反光区域没有缺陷但也等同于没有任何学习信号”它只能自己摸索哪些区域是前景、哪些是背景。玻璃反光造成的假轮廓和划痕在视觉上高度相似模型极易混淆。解决有两个层级的手段。数据层面在标注时把所有明显的反光区域裁剪成背景样本加入训练集作为负样本。源码包里的 check_labels.py 也建议配合一个 deduplicate 操作——同一块玻璃的多角度拍摄图要确保反光位置不完全一样否则模型会把反光位置当特征来学。模型层面如果数据清洗后依旧混淆考虑提高输入分辨率让模型看清反光与真实划痕的纹理差异。5.3 小缺陷漏检严重mAP 看着还行的原因现象验证集 mAP50 有 0.85但在测试集上小颗粒杂质和短划痕的检出率不到一半。原因mAP 是一个被大目标主导的指标。玻璃缺陷里气泡通常面积大且易检划痕短而细小模型只要把气泡和长划痕检好mAP 就能被拉起来小缺陷的贡献占比很低。评估时只看总体 mAP等于被平均数骗了。解决按类别单独看 AP。源码包里的 utils/metrics.py 支持输出每个类别的 AP 和召回率这是这包最值得用的工具之一。如果某个小缺陷类别的 AP 明显低于其他类别优先考虑提高 imgsz 到 1280并针对性补充该类缺陷的样本数量。5.4 推理速度达标但延迟抖动明显现象单帧推理平均 15ms看起来满足产线 60 帧的节拍要求但实际运行时偶尔出现单帧 80ms 的峰值延迟。原因GPU 推理延迟抖动通常来自输入尺寸不一致。调用推理脚本时没有固定 imgszYOLOv8 会根据输入图像自动做 letterbox不同尺寸图像的计算量不同导致单帧耗时波动。另外v RAM 不足时系统会动态分配内存也会造成偶发延迟。解决推理阶段强制固定 imgsz并且把图像预处理缩放、letterbox从推理循环中挪到数据读取阶段预先计算好每张图的缩放参数。更进一步的做法是导出 TensorRT 引擎用固定尺寸的 engine 文件跑推理能显著降低延迟抖动。源码包里的 export_onnx.py 可以先把模型转为 ONNX再用 ONNX 转 TensorRT这两步在部署阶段是关键。5.5 ultralytics 库版本升级导致代码 API 不兼容现象保存的模型权重可以加载但训练参数脚本突然报“AttributeError: Trainer object has no attribute xxx”。原因ultralytics 是一个迭代很快的库不同版本之间 API 变动频繁。源码包开发时的某个函数或参数在当前安装的最新版里可能已经改名或删除了。解决在 requirements.txt 里锁定大版本比如ultralytics8.0,9.0。如果已经升级到不兼容的版本两个退路一是按报错信息找到新的 API 名称二是直接使用pip install ultralytics8.x.x回退到与源码匹配的版本。我的习惯是源码包锁定的 ultralytics 版本绝不轻易升级除非我能完整回归一遍训练和推理流程。6. 验证指标与部署技巧用 mAP 之外的第二套标准验货mAP 是给论文和 benchmark 看的产线检测真正该看的是每类缺陷的召回率和误检率。玻璃缺陷检测里不同缺陷的后果完全不一样一个漏检的气泡可能导致整块玻璃报废而一个误检的杂质只需要人工复核几秒钟。这两类错误的价值完全不同只看 mAP 会把它们混在一起。我的习惯是用源码包里的 metrics.py 输出每个类别的混淆矩阵。重点关注两类数据一是小缺陷类别的召回率如果低于 0.9优先去补数据和调分辨率二是相邻类别之间的互相误判——划痕被识别成裂纹、气泡被识别成杂质这类 confusion 往往指向标注边界定义不清晰需要回到标注规范去修标签而不是继续调参。训练完成后导出 ONNX 模型做推理验证是我每次部署前必须走的一步# 导出 ONNX开启动态输入尺寸以便后续用 TensorRT 优化 yolo export modelbest.pt formatonnx dynamicTrue opset12导出后写一个最小的推理脚本import onnxruntime as ort import cv2 import numpy as np session ort.InferenceSession(best.onnx, providers[CUDAExecutionProvider]) img cv2.imread(test_glass.png) img_resized cv2.resize(img, (640, 640)) # 确保与训练时的输入尺寸一致 input_tensor np.transpose(img_resized, (2, 0, 1)).astype(np.float32) / 255.0 input_tensor np.expand_dims(input_tensor, axis0) outputs session.run(None, {session.get_inputs()[0].name: input_tensor}) print(f检测到 {outputs[0].shape[1]} 个目标候选框)这段代码里的关键参数是providers[CUDAExecutionProvider]——如果不显式指定ONNX Runtime 默认走 CPU推理速度可能慢 50 倍以上。astype(np.float32)也值得注意PyTorch 训练时默认精度是 float32ONNX 输入也必须对齐否则数值误差会在输出端扩大。部署阶段我还有一个习惯在产线环境里跑至少 2000 张不重复的真实图像统计每千块的误检率和漏检率。这些数字比 mAP 更能反映模型是否真的能上线。那次我帮某产线做玻璃盖板检测mAP 到了 0.92结果在夜班开灯的一瞬间误检率突然飙升到 15%——因为产线的灯光频段和白天不一样模型的颜色分布被扰动。从那以后我每次做玻璃缺陷项目都会强制走一遍“不同光照条件下的小样本验证”收集各个时段的现场图像混进验证集里测试确认模型在光照扰动下依然稳定。这个习惯帮我提前发现过至少五次潜在的部署事故。如果你也准备用这套源码跑自己的玻璃缺陷数据建议从 yolov8n 加 imgsz960 开始先跑通全流程再逐步加模型、加分辨率。别急着一步到位先让数据、标签、训练链路都稳稳转起来再做精度优化。希望帮到你。本文还有配套的精品资源点击获取