尧图网站建设 
我是做CV落地项目的老手了这类“检测分割界面”的完整系统项目这几年在毕设、课程设计和实际工程里需求量非常大。路面坑洞检测就是一个特别典型的场景病害样本形态混乱、标注成本高、现场光照复杂既要能框出来还要能分割出轮廓用来估算面积和修复用料。这套基于YOLOv8的实现把模型训练、推理和PyQt5可视化界面串成了一条完整的链路拿到之后是可以直接改数据、改界面、重新训练后投入使用的不是那种只能跑个Demo的玩具代码。这套系统适合三类人一是正在做深度学习相关毕设、需要整套完整工程代码的同学二是刚入门目标检测/分割、想搞懂数据怎么从标注格式一路变成模型输出结果的人三是路面养护相关行业、想把AI视觉落到实际巡检流程里的工程人员。这篇文章我就按拿到这套系统后从0到1的完整过程来讲技术选型为什么这么做、数据怎么处理、模型怎么训练调参、界面集成有哪些坑以及最后怎么部署优化。1. 这套系统到底做了什么检测与分割一起解决而不是只画个框先把这个项目的核心讲清楚。路面坑洞检测传统的做法是拿YOLO系列做纯目标检测输出一个矩形框把坑洞框住。但这套系统用的是YOLOv8的seg系列模型也就是实例分割版本输出框之外还会输出每个坑洞的像素级轮廓掩码。这一步的差别在实际工程里非常大光有个框你不知道坑洞具体边界在哪也就没法估算面积、没法指导修复用料的量更没法精确测量病害的扩展范围。再说为什么选YOLOv8而不是更早的YOLOv5或者新的YOLOv9、v10。选型逻辑其实很务实v5的分割能力要靠自己魔改v9/v10虽然新但社区资料和部署生态还没完全跟上而v8是ultralytics官方把检测、分割、分类、姿态四合一之后形成的最稳定版本。特别是seg系列直接用官方YOLO类加载权重就能完成训练和推理底层的数据处理、增强策略、评价指标全部封装好了对于要快速落地一个系统来说这是性价比最高的选择。界面部分用PyQt5而不是Web前端同样是考虑落地效率。PyQt5和ultralytics推理代码跑在同一个Python进程里不需要额外起后端服务一套代码解决模型加载、推理、结果显示。Qt的QThread机制也能很好地把模型推理放到子线程避免界面主线程被推理耗时卡死。再配合Qt Designer拖拽式设计界面整套系统的开发工作量会小很多。整套系统跑起来的效果是这样的打开界面后可以加载一张图片、一段视频或者直接调摄像头点击检测按钮后模型会对当前帧做推理坑洞位置画上框坑洞轮廓用半透明色块覆盖界面上显示类别、置信度和单次推理耗时。底下还可以拖动置信度阈值滑块调节检测的严格程度。2. 系统架构与数据流向输入图片到界面显示结果之间的完整链路这个系统的代码结构并不复杂三个模块各管一摊模型推理模块负责加载权重和跑网络界面模块负责交互和绘制数据与训练模块负责标注转换和训练脚本。理解数据怎么流通的后面改代码才不会一头雾水。数据流最关键的一段是模型输入输出。图片输入到YOLOv8-seg之前会被自动做letterbox变换也就是等比缩放并填充灰边到640×640。推理完成后网络输出三部分内容目标框信息、类别概率、以及一组mask系数。检测头给出的粗粒度信息负责定位框分割头结合prototype masks和mask系数解码出最终的实例掩码。也就是说YOLOv8的seg模型不是直接输出一个完整的大分辨率mask而是先学了一组基础的掩码模板再用每个目标的系数去线性组合出最终轮廓这样能显著降低计算量。PyQt5界面的交互逻辑核心是“界面与推理分离”。我用QThread封装了一个DetectThread界面主线程只管接收按钮点击事件、更新状态栏、刷新显示标签真正执行模型推理的在子线程里推理完成后通过pyqtSignal把结果传回主线程。这有一个很实际的原因中低端显卡推理一帧可能要上百毫秒如果直接放在主线程里跑界面会变成“未响应”状态体验非常差。_result_ready这个信号传回的是一个叠加绘制好的图像数组和对应的mask数组列表主线程拿到后直接setPixmap显示绘制工作也放在子线程做完了。这样的好处是主线程除了显示和事件响应外几乎不干重活也不会因为频繁刷新而卡顿。摄像头模式还要注意一点不要把每一帧都丢进模型推理尤其是显卡性能一般的时候实际做法是每隔一帧或两帧检测一次中间的帧直接复用上一次结果这样能明显提升流畅度视觉上也不会有太大延迟感。3. 坑洞数据集怎么准备采集、标注和YOLOv8分割格式转换很多同学拿到一套源码最头疼的不是模型训练而是自己的数据喂不进去。这里把路面坑洞数据集从零到能训练的完整流程讲清楚。3.1 样本采集要注意的多样性问题坑洞样本多不等于样本好。我见过不少人拿手机拍了几百张同一个路段的坑洞去训练结果验证集mAP高得离谱一换场景就崩。坑洞的数据多样性主要体现在几个维度上路面材质沥青和水泥的纹理差异很大、光照条件顺光、逆光、阴影遮挡、阴雨天、坑洞形态边缘清晰的块状坑、边缘碎裂的松散坑、还没有完全成型的裂缝前兆以及拍摄角度。网上能下载到一些公开的pothole数据集但普遍存在场景单一、分辨率偏低的问题我的建议是公开数据作为预训练补充自己采集一批现场照片做微调两者结合效果最好。如果自己做数据集起步阶段300到500张精标图片是合理量级太少模型容易过拟合太多标注成本就上去了。3.2 标注工具选labelme重点说转YOLO分割格式标注工具首选labelme它对多边形标注的支持最好。每张图片标注完成后会生成一个同名json文件里面记录每个多边形的label和点坐标。YOLOv8分割训练需要的是txt格式每一行代表一个目标第一个数字是类别id后面是按顺序排列的点坐标对且坐标必须是归一化到0~1的小数。这里给一段我实际在用的转换脚本逻辑很清晰import json import os from glob import glob class_map {pothole: 0} # 按自己的类别调整 def convert_labelme_json(json_path, out_txt_path): with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] lines [] for shape in data[shapes]: label shape[label] points shape[points] # [[x, y], [x, y], ...] if label not in class_map: continue cls_id class_map[label] norm_points [(x / img_w, y / img_h) for x, y in points] line str(cls_id) .join( f{px:.6f} {py:.6f} for px, py in norm_points ) lines.append(line) with open(out_txt_path, w, encodingutf-8) as f: f.write(\n.join(lines)) # 批量转换 for json_file in glob(labels_json/*.json): txt_file os.path.join(labels_txt, os.path.basename(json_file).replace(.json, .txt)) convert_labelme_json(json_file, txt_file)转换完成后图片放在images/train和images/val里txt和图片同名放在labels/train和labels/val里这样就符合ultralytics默认的目录结构了。3.3 数据增强经验路面阴影是最需要处理的干扰项坑洞检测和常规物体检测有个显著区别坑洞和路面背景的对比度经常非常低加上路边树木、电线杆的影子很容易形成和坑洞形状相似的暗色区域。因此训练集里一定要包含足够多的带阴影样本同时在训练增强里加大亮度、对比度调整的力度。ultralytics默认的马赛克增强和随机透视对这类任务很有帮助可以保持默认。如果自己的数据量偏少还可以加一定程度的旋转和翻转增强但要注意坑洞没有明显的方向性旋转角度可以放宽。划分数据集时有一条容易被忽略但很重要的规则同一个场景连续拍摄的多帧图片必须全部放进同一个集合train或val不能一部分在训练集一部分在验证集。否则相当于验证集和训练集有重复内容评出来的指标虚高我见过不少人因为这个在答辩时被问住了。4. YOLOv8-seg训练配置不同显存下的模型选择与参数取舍训练这块是大多数人的卡点。我先讲模型选型再讲训练参数最后说训练过程常见的判断方法。4.1 模型体量怎么选不是模型越大效果越好YOLOv8-seg系列有n、s、m、l、x五个档位。绝大多数人手里的显卡是GTX 1660Ti这类6G显存的卡甚至是只用CPU跑这种条件下老实选n或s就对了。我整理了一个参考对照表方便按自己硬件条件对号入座模型参数量显存需求(训练)推理耗时(GTX1660Ti)适用场景yolov8n-seg约3.4M4G可跑约30-40ms快速验证、嵌入式、低配显卡yolov8s-seg约11.8M6G勉强约60-90ms大多数落地项目首选yolov8m-seg约27.3M8G约120-160ms数据量大、精度优先yolov8l-seg约46.3M12G200ms以上离线分析不建议实时实际跑下来坑洞这种单类任务n和s的精度差距没有想象中那么大但推理速度差距是肉眼可见的。如果是6G显存我建议直接上sbatch设8左右可以跑得动如果想留一点显存余量给其他程序就选n。4.2 数据集配置与训练命令训练前先准备data.yaml内容不多但路径写错是高频报错点。我建议一律用绝对路径避免在不同机器上挪动项目时因为相对路径问题抓狂path: D:/PotholeProject/datasets/pothole train: images/train val: images/val nc: 1 names: [pothole]训练命令一行搞定yolo segment train dataD:/PotholeProject/datasets/pothole/data.yaml \ modelyolov8s-seg.yaml \ epochs200 \ imgsz640 \ batch8 \ device0 \ patience30这里几个参数值得展开说。epochs设200是一个比较中庸的选择坑洞分割任务通常到80到150轮之间就基本收敛了设大一点配合早停机制更稳妥。patience是早停的耐心值连续30轮验证集指标没有提升就自动停止防止过拟合的同时节省时间。imgsz保持640除非你想检测非常小的坑洞可以适当提到800但显存消耗会明显上涨。batch要结合显存和模型一起看显存不够优先减少batch而不是图片尺寸因为batch减半对精度影响很小而图片尺寸一旦降到512以下小坑洞的分割质量会明显下降。4.3 显存不足和过拟合的两条实战经验如果你在训练时报CUDA out of memory第一步不是换更大的卡而是检查batch、imgsz和工作进程数workers。很多情况是workers开太大导致CPU转GPU数据时显存峰值飙升把这个值从默认的8降到2或4问题就能缓解。第二个经验是关于freeze参数的当自己的数据集只有几百张时直接从随机初始化开始训练效果很差正确做法是下载yolov8s-seg.pt预训练权重然后可以用freeze10冻结前10层的主干网络相当于只微调后面部分能明显降低过拟合风险收敛也更快。如果数据集已经上千张就不建议freeze了会限制模型在特定数据上的适应能力。训练过程中ultralytics会在保存目录下生成results.csv里面记录了每一轮的train loss、val loss、mAP等指标。训练结束后模型文件有best.pt和last.pt两个best.pt是验证集指标最好的那个实际推理时直接加载它。5. 训练结果怎么看mAP、损失曲线、PR曲线和误检分析训练完不是简单看loss降没降就收工还要做系统的评估和分析这部分决定了模型能不能真正拿去用。5.1 评估指标要区分box和mask两套YOLOv8-seg的验证结果会同时输出目标框和掩码的指标。我训练的一组典型参考值是这样指标数值box mAP500.874box mAP50-950.529mask mAP500.823mask mAP50-950.491推理耗时68ms你会发现mask的mAP天然比box低几个点因为像素级预测的难度比框回归高得多。mAP50和mAP50-95差距大也是正常的mAP50-95是跨IoU阈值的综合表现坑洞这类边缘不规则的物体mAP50-95普遍高不了。这里更值得关注的是mask mAP50这个指标它代表分割结果在实际使用中的可用程度路面坑洞分割只要能到0.75以上基本就能用来估算了。5.2 用损失曲线判断训练是否到位拿到results.csv后我最常画的是三张图训练集和验证集的box loss曲线、mask loss曲线、以及mAP曲线。有一个经验值得分享如果val的box loss曲线先降后升而训练loss还在降说明过拟合了这时候应该减少训练轮数或者加大数据增强如果val的mask loss还在缓慢下降但训练已经结束可以加大epochs继续跑。画图用一个简单的脚本就能搞定import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/segment/train/results.csv) df.columns [c.strip() for c in df.columns] plt.plot(df[epoch], df[train/box_loss], labeltrain box loss) plt.plot(df[epoch], df[val/box_loss], labelval box loss) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.grid(True) plt.show()5.3 混淆矩阵与PR曲线定位两类典型问题混淆矩阵里最值得看的是把“什么”误检成了坑洞。我在实际项目里遇到最多的就是井盖被识别成坑洞还有路面深色阴影和油渍。这时候单纯调参数没用要把这些误检样本收集起来和坑洞样本一起重新精标加进训练集里做hard example训练。PR曲线则用来选择置信度阈值曲线靠近右上角说明模型整体可靠曲线上有一个明显的拐点拐点之后置信度再往上调精确率提升很少但召回率会快速下降。实际界面里那个置信度滑块默认值0.25到0.3是比较合理的区间具体数值可以参考PR曲线再定。6. PyQt5界面集成的关键细节线程、OpenGL无显示和分辨率适配模型训好了最后一步是把模型包装成一套像样的界面系统。这一章是踩坑最集中的地方我把遇到的几个高频问题逐一讲透。6.1 模型加载和推理不要阻塞主线程很多初版界面代码会把模型加载写在窗口类初始化里模型文件几百MB的时候窗口启动会卡住好几秒非常影响体验。正确做法是用QThread在后台加载模型加载完成后再通过信号通知界面激活“开始检测”按钮。推理也是同样思路我封装了一个DetectThread核心逻辑大致是from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO import numpy as np class DetectThread(QThread): result_ready pyqtSignal(np.ndarray) def __init__(self, model_path, conf0.25, parentNone): super().__init__(parent) self.model YOLO(model_path) self.conf conf self.frame None def set_frame(self, frame): self.frame frame def run(self): if self.frame is None: return res self.model.predict( self.frame, confself.conf, iou0.5, verboseFalse ) if len(res) 0: return plotted res[0].plot() # 绘制检测框和mask self.result_ready.emit(plotted)res[0].plot()是最省事的绘制方式检测框、类别名、置信度和mask都会画好。如果你想自定义mask的透明度和颜色可以单独取res[0].masks.data转成numpy数组手动叠加到原图上灵活度更高。6.2 OpenGL导致PyQt5界面无显示最坑的问题之一这个问题的表现是程序运行后界面一片黑或者根本没窗口弹出控制台报Opengl相关的错误。原因在于Qt5的某些控件渲染依赖OpenGL而常见的触发场景是虚拟机、远程桌面、集成显卡驱动不全、或者显卡驱动版本过老。解决办法最有效的是让Qt强制走软件渲染在import PyQt5之前先设置环境变量import os os.environ.setdefault(QT_OPENGL, software) os.environ.setdefault(QT_QUICK_BACKEND, software)Linux系统还可以在启动脚本里加export QT_OPENGLsoftware。软件渲染对纯2D界面几乎没有影响只是在视频流放大缩小时稍微损耗一点性能换来的是界面稳定显示这个取舍完全值得。6.3 不同分辨率下的界面错乱问题高分屏和不同缩放比例的Windows系统会让PyQt5界面出现控件重叠、字体模糊、显示不全的问题。标准做法是在程序入口处加上Qt的AA_EnableHighDpiScaling属性并且布局时用布局管理器而不是绝对坐标。我用的是QVBoxLayout配合QHBoxLayout将“打开图片”“打开视频”“摄像头模式”“置信度滑块”放在顶部工具栏区域中间是显示图像的大QLabel底部放状态栏。这样窗口无论拉伸还是缩放控件都能跟着合理变化。6.4 摄像头与视频抽帧别让界面变成幻灯片摄像头实时检测时如果每一帧都跑到模型里推理界面帧率会被拖到个位数看起来像幻灯片。我的处理方式是摄像头线程只负责采集最新帧推理线程有结果就刷新显示控制间隔在100毫秒左右相当于10FPS的检测效果。这个频率对路面巡检场景来说完全够用而且肉眼看起来是连续流畅的。7. 从Python原型到实际部署性能优化和边缘设备移植路线最后聊一下这套系统从“实验室能跑”到“现场能稳定工作”的进阶路线这部分也是很多工程项目真正关心的地方。7.1 先解决推理速度瓶颈Python下的ultralytics推理即使模型已经加载到显存每帧还有不少时间浪费在图像预处理、NMS和mask解码上。如果要在工业环境做到更快的处理速度第一步是导出成TensorRT engine。流程不复杂先是pt导出onnx再做TensorRT转换可以用FP16精度。我实测过同一个yolov8n-seg模型在GTX1660Ti上FP16的TensorRT推理比原生PyTorch快大约1.5到2倍从30多毫秒降到20毫秒上下。如果是RK3588这类带NPU的边缘开发板路线就是pt转onnx再转rknn量化后延迟能压到更理想的范围但要注意某些算子在NPU上的兼容性问题。7.2 分割结果的后处理mask平滑和面积估算拿到模型输出之后工程上往往还要做一步后处理。坑洞分割的mask边缘经常有毛刺和孔洞可以用cv2.morphologyEx做闭运算填充小孔再用findContours提取轮廓过滤掉面积过小的噪点区域。如果要估算坑洞面积需要先知道像素坐标系和实际物理坐标系的换算比例最简单的方法是在现场用标定板或已知尺寸的参照物标定然后对mask像素做积分。这部分在当前系统中预留了计算接口接上现场标定参数就能出面积报告。7.3 项目二次开发的几个方向这套系统后续可扩展的方向我很推荐两个一是把单帧检测升级成视频时序追踪这样能对同一坑洞做多帧的尺寸变化分析评估病害发展速度二是增加数据回传机制现场检测到的坑洞图自动保存并定期补充到训练集里继续微调模型越用越准。这些在目前代码结构上都不需要大改在推理线程里加存储逻辑在训练脚本里追加增量数据即可。我个人在实际操作中最深的体会是路面坑洞检测项目的瓶颈从头到尾都不是模型结构而是数据质量。坑洞长得不像通用物体那样有清晰确定的边界阴影、井盖、油渍都在挑战模型的判断力。把精力花在收集更多样化的现场数据、仔细检查和修正标注边界、针对误检样本做迭代训练上远比反复调整网络结构或训练参数更有效。这套系统提供的完整训练链路正好把这些环节全部打通了拿到手之后按自己的场景补充数据重新训练就能产出一个真正能用的病害检测工具。 YOLOv8+PyQt5：路面坑洞检测与分割系统实战
我是做CV落地项目的老手了这类“检测分割界面”的完整系统项目这几年在毕设、课程设计和实际工程里需求量非常大。路面坑洞检测就是一个特别典型的场景病害样本形态混乱、标注成本高、现场光照复杂既要能框出来还要能分割出轮廓用来估算面积和修复用料。这套基于YOLOv8的实现把模型训练、推理和PyQt5可视化界面串成了一条完整的链路拿到之后是可以直接改数据、改界面、重新训练后投入使用的不是那种只能跑个Demo的玩具代码。这套系统适合三类人一是正在做深度学习相关毕设、需要整套完整工程代码的同学二是刚入门目标检测/分割、想搞懂数据怎么从标注格式一路变成模型输出结果的人三是路面养护相关行业、想把AI视觉落到实际巡检流程里的工程人员。这篇文章我就按拿到这套系统后从0到1的完整过程来讲技术选型为什么这么做、数据怎么处理、模型怎么训练调参、界面集成有哪些坑以及最后怎么部署优化。1. 这套系统到底做了什么检测与分割一起解决而不是只画个框先把这个项目的核心讲清楚。路面坑洞检测传统的做法是拿YOLO系列做纯目标检测输出一个矩形框把坑洞框住。但这套系统用的是YOLOv8的seg系列模型也就是实例分割版本输出框之外还会输出每个坑洞的像素级轮廓掩码。这一步的差别在实际工程里非常大光有个框你不知道坑洞具体边界在哪也就没法估算面积、没法指导修复用料的量更没法精确测量病害的扩展范围。再说为什么选YOLOv8而不是更早的YOLOv5或者新的YOLOv9、v10。选型逻辑其实很务实v5的分割能力要靠自己魔改v9/v10虽然新但社区资料和部署生态还没完全跟上而v8是ultralytics官方把检测、分割、分类、姿态四合一之后形成的最稳定版本。特别是seg系列直接用官方YOLO类加载权重就能完成训练和推理底层的数据处理、增强策略、评价指标全部封装好了对于要快速落地一个系统来说这是性价比最高的选择。界面部分用PyQt5而不是Web前端同样是考虑落地效率。PyQt5和ultralytics推理代码跑在同一个Python进程里不需要额外起后端服务一套代码解决模型加载、推理、结果显示。Qt的QThread机制也能很好地把模型推理放到子线程避免界面主线程被推理耗时卡死。再配合Qt Designer拖拽式设计界面整套系统的开发工作量会小很多。整套系统跑起来的效果是这样的打开界面后可以加载一张图片、一段视频或者直接调摄像头点击检测按钮后模型会对当前帧做推理坑洞位置画上框坑洞轮廓用半透明色块覆盖界面上显示类别、置信度和单次推理耗时。底下还可以拖动置信度阈值滑块调节检测的严格程度。2. 系统架构与数据流向输入图片到界面显示结果之间的完整链路这个系统的代码结构并不复杂三个模块各管一摊模型推理模块负责加载权重和跑网络界面模块负责交互和绘制数据与训练模块负责标注转换和训练脚本。理解数据怎么流通的后面改代码才不会一头雾水。数据流最关键的一段是模型输入输出。图片输入到YOLOv8-seg之前会被自动做letterbox变换也就是等比缩放并填充灰边到640×640。推理完成后网络输出三部分内容目标框信息、类别概率、以及一组mask系数。检测头给出的粗粒度信息负责定位框分割头结合prototype masks和mask系数解码出最终的实例掩码。也就是说YOLOv8的seg模型不是直接输出一个完整的大分辨率mask而是先学了一组基础的掩码模板再用每个目标的系数去线性组合出最终轮廓这样能显著降低计算量。PyQt5界面的交互逻辑核心是“界面与推理分离”。我用QThread封装了一个DetectThread界面主线程只管接收按钮点击事件、更新状态栏、刷新显示标签真正执行模型推理的在子线程里推理完成后通过pyqtSignal把结果传回主线程。这有一个很实际的原因中低端显卡推理一帧可能要上百毫秒如果直接放在主线程里跑界面会变成“未响应”状态体验非常差。_result_ready这个信号传回的是一个叠加绘制好的图像数组和对应的mask数组列表主线程拿到后直接setPixmap显示绘制工作也放在子线程做完了。这样的好处是主线程除了显示和事件响应外几乎不干重活也不会因为频繁刷新而卡顿。摄像头模式还要注意一点不要把每一帧都丢进模型推理尤其是显卡性能一般的时候实际做法是每隔一帧或两帧检测一次中间的帧直接复用上一次结果这样能明显提升流畅度视觉上也不会有太大延迟感。3. 坑洞数据集怎么准备采集、标注和YOLOv8分割格式转换很多同学拿到一套源码最头疼的不是模型训练而是自己的数据喂不进去。这里把路面坑洞数据集从零到能训练的完整流程讲清楚。3.1 样本采集要注意的多样性问题坑洞样本多不等于样本好。我见过不少人拿手机拍了几百张同一个路段的坑洞去训练结果验证集mAP高得离谱一换场景就崩。坑洞的数据多样性主要体现在几个维度上路面材质沥青和水泥的纹理差异很大、光照条件顺光、逆光、阴影遮挡、阴雨天、坑洞形态边缘清晰的块状坑、边缘碎裂的松散坑、还没有完全成型的裂缝前兆以及拍摄角度。网上能下载到一些公开的pothole数据集但普遍存在场景单一、分辨率偏低的问题我的建议是公开数据作为预训练补充自己采集一批现场照片做微调两者结合效果最好。如果自己做数据集起步阶段300到500张精标图片是合理量级太少模型容易过拟合太多标注成本就上去了。3.2 标注工具选labelme重点说转YOLO分割格式标注工具首选labelme它对多边形标注的支持最好。每张图片标注完成后会生成一个同名json文件里面记录每个多边形的label和点坐标。YOLOv8分割训练需要的是txt格式每一行代表一个目标第一个数字是类别id后面是按顺序排列的点坐标对且坐标必须是归一化到0~1的小数。这里给一段我实际在用的转换脚本逻辑很清晰import json import os from glob import glob class_map {pothole: 0} # 按自己的类别调整 def convert_labelme_json(json_path, out_txt_path): with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] lines [] for shape in data[shapes]: label shape[label] points shape[points] # [[x, y], [x, y], ...] if label not in class_map: continue cls_id class_map[label] norm_points [(x / img_w, y / img_h) for x, y in points] line str(cls_id) .join( f{px:.6f} {py:.6f} for px, py in norm_points ) lines.append(line) with open(out_txt_path, w, encodingutf-8) as f: f.write(\n.join(lines)) # 批量转换 for json_file in glob(labels_json/*.json): txt_file os.path.join(labels_txt, os.path.basename(json_file).replace(.json, .txt)) convert_labelme_json(json_file, txt_file)转换完成后图片放在images/train和images/val里txt和图片同名放在labels/train和labels/val里这样就符合ultralytics默认的目录结构了。3.3 数据增强经验路面阴影是最需要处理的干扰项坑洞检测和常规物体检测有个显著区别坑洞和路面背景的对比度经常非常低加上路边树木、电线杆的影子很容易形成和坑洞形状相似的暗色区域。因此训练集里一定要包含足够多的带阴影样本同时在训练增强里加大亮度、对比度调整的力度。ultralytics默认的马赛克增强和随机透视对这类任务很有帮助可以保持默认。如果自己的数据量偏少还可以加一定程度的旋转和翻转增强但要注意坑洞没有明显的方向性旋转角度可以放宽。划分数据集时有一条容易被忽略但很重要的规则同一个场景连续拍摄的多帧图片必须全部放进同一个集合train或val不能一部分在训练集一部分在验证集。否则相当于验证集和训练集有重复内容评出来的指标虚高我见过不少人因为这个在答辩时被问住了。4. YOLOv8-seg训练配置不同显存下的模型选择与参数取舍训练这块是大多数人的卡点。我先讲模型选型再讲训练参数最后说训练过程常见的判断方法。4.1 模型体量怎么选不是模型越大效果越好YOLOv8-seg系列有n、s、m、l、x五个档位。绝大多数人手里的显卡是GTX 1660Ti这类6G显存的卡甚至是只用CPU跑这种条件下老实选n或s就对了。我整理了一个参考对照表方便按自己硬件条件对号入座模型参数量显存需求(训练)推理耗时(GTX1660Ti)适用场景yolov8n-seg约3.4M4G可跑约30-40ms快速验证、嵌入式、低配显卡yolov8s-seg约11.8M6G勉强约60-90ms大多数落地项目首选yolov8m-seg约27.3M8G约120-160ms数据量大、精度优先yolov8l-seg约46.3M12G200ms以上离线分析不建议实时实际跑下来坑洞这种单类任务n和s的精度差距没有想象中那么大但推理速度差距是肉眼可见的。如果是6G显存我建议直接上sbatch设8左右可以跑得动如果想留一点显存余量给其他程序就选n。4.2 数据集配置与训练命令训练前先准备data.yaml内容不多但路径写错是高频报错点。我建议一律用绝对路径避免在不同机器上挪动项目时因为相对路径问题抓狂path: D:/PotholeProject/datasets/pothole train: images/train val: images/val nc: 1 names: [pothole]训练命令一行搞定yolo segment train dataD:/PotholeProject/datasets/pothole/data.yaml \ modelyolov8s-seg.yaml \ epochs200 \ imgsz640 \ batch8 \ device0 \ patience30这里几个参数值得展开说。epochs设200是一个比较中庸的选择坑洞分割任务通常到80到150轮之间就基本收敛了设大一点配合早停机制更稳妥。patience是早停的耐心值连续30轮验证集指标没有提升就自动停止防止过拟合的同时节省时间。imgsz保持640除非你想检测非常小的坑洞可以适当提到800但显存消耗会明显上涨。batch要结合显存和模型一起看显存不够优先减少batch而不是图片尺寸因为batch减半对精度影响很小而图片尺寸一旦降到512以下小坑洞的分割质量会明显下降。4.3 显存不足和过拟合的两条实战经验如果你在训练时报CUDA out of memory第一步不是换更大的卡而是检查batch、imgsz和工作进程数workers。很多情况是workers开太大导致CPU转GPU数据时显存峰值飙升把这个值从默认的8降到2或4问题就能缓解。第二个经验是关于freeze参数的当自己的数据集只有几百张时直接从随机初始化开始训练效果很差正确做法是下载yolov8s-seg.pt预训练权重然后可以用freeze10冻结前10层的主干网络相当于只微调后面部分能明显降低过拟合风险收敛也更快。如果数据集已经上千张就不建议freeze了会限制模型在特定数据上的适应能力。训练过程中ultralytics会在保存目录下生成results.csv里面记录了每一轮的train loss、val loss、mAP等指标。训练结束后模型文件有best.pt和last.pt两个best.pt是验证集指标最好的那个实际推理时直接加载它。5. 训练结果怎么看mAP、损失曲线、PR曲线和误检分析训练完不是简单看loss降没降就收工还要做系统的评估和分析这部分决定了模型能不能真正拿去用。5.1 评估指标要区分box和mask两套YOLOv8-seg的验证结果会同时输出目标框和掩码的指标。我训练的一组典型参考值是这样指标数值box mAP500.874box mAP50-950.529mask mAP500.823mask mAP50-950.491推理耗时68ms你会发现mask的mAP天然比box低几个点因为像素级预测的难度比框回归高得多。mAP50和mAP50-95差距大也是正常的mAP50-95是跨IoU阈值的综合表现坑洞这类边缘不规则的物体mAP50-95普遍高不了。这里更值得关注的是mask mAP50这个指标它代表分割结果在实际使用中的可用程度路面坑洞分割只要能到0.75以上基本就能用来估算了。5.2 用损失曲线判断训练是否到位拿到results.csv后我最常画的是三张图训练集和验证集的box loss曲线、mask loss曲线、以及mAP曲线。有一个经验值得分享如果val的box loss曲线先降后升而训练loss还在降说明过拟合了这时候应该减少训练轮数或者加大数据增强如果val的mask loss还在缓慢下降但训练已经结束可以加大epochs继续跑。画图用一个简单的脚本就能搞定import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/segment/train/results.csv) df.columns [c.strip() for c in df.columns] plt.plot(df[epoch], df[train/box_loss], labeltrain box loss) plt.plot(df[epoch], df[val/box_loss], labelval box loss) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.grid(True) plt.show()5.3 混淆矩阵与PR曲线定位两类典型问题混淆矩阵里最值得看的是把“什么”误检成了坑洞。我在实际项目里遇到最多的就是井盖被识别成坑洞还有路面深色阴影和油渍。这时候单纯调参数没用要把这些误检样本收集起来和坑洞样本一起重新精标加进训练集里做hard example训练。PR曲线则用来选择置信度阈值曲线靠近右上角说明模型整体可靠曲线上有一个明显的拐点拐点之后置信度再往上调精确率提升很少但召回率会快速下降。实际界面里那个置信度滑块默认值0.25到0.3是比较合理的区间具体数值可以参考PR曲线再定。6. PyQt5界面集成的关键细节线程、OpenGL无显示和分辨率适配模型训好了最后一步是把模型包装成一套像样的界面系统。这一章是踩坑最集中的地方我把遇到的几个高频问题逐一讲透。6.1 模型加载和推理不要阻塞主线程很多初版界面代码会把模型加载写在窗口类初始化里模型文件几百MB的时候窗口启动会卡住好几秒非常影响体验。正确做法是用QThread在后台加载模型加载完成后再通过信号通知界面激活“开始检测”按钮。推理也是同样思路我封装了一个DetectThread核心逻辑大致是from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO import numpy as np class DetectThread(QThread): result_ready pyqtSignal(np.ndarray) def __init__(self, model_path, conf0.25, parentNone): super().__init__(parent) self.model YOLO(model_path) self.conf conf self.frame None def set_frame(self, frame): self.frame frame def run(self): if self.frame is None: return res self.model.predict( self.frame, confself.conf, iou0.5, verboseFalse ) if len(res) 0: return plotted res[0].plot() # 绘制检测框和mask self.result_ready.emit(plotted)res[0].plot()是最省事的绘制方式检测框、类别名、置信度和mask都会画好。如果你想自定义mask的透明度和颜色可以单独取res[0].masks.data转成numpy数组手动叠加到原图上灵活度更高。6.2 OpenGL导致PyQt5界面无显示最坑的问题之一这个问题的表现是程序运行后界面一片黑或者根本没窗口弹出控制台报Opengl相关的错误。原因在于Qt5的某些控件渲染依赖OpenGL而常见的触发场景是虚拟机、远程桌面、集成显卡驱动不全、或者显卡驱动版本过老。解决办法最有效的是让Qt强制走软件渲染在import PyQt5之前先设置环境变量import os os.environ.setdefault(QT_OPENGL, software) os.environ.setdefault(QT_QUICK_BACKEND, software)Linux系统还可以在启动脚本里加export QT_OPENGLsoftware。软件渲染对纯2D界面几乎没有影响只是在视频流放大缩小时稍微损耗一点性能换来的是界面稳定显示这个取舍完全值得。6.3 不同分辨率下的界面错乱问题高分屏和不同缩放比例的Windows系统会让PyQt5界面出现控件重叠、字体模糊、显示不全的问题。标准做法是在程序入口处加上Qt的AA_EnableHighDpiScaling属性并且布局时用布局管理器而不是绝对坐标。我用的是QVBoxLayout配合QHBoxLayout将“打开图片”“打开视频”“摄像头模式”“置信度滑块”放在顶部工具栏区域中间是显示图像的大QLabel底部放状态栏。这样窗口无论拉伸还是缩放控件都能跟着合理变化。6.4 摄像头与视频抽帧别让界面变成幻灯片摄像头实时检测时如果每一帧都跑到模型里推理界面帧率会被拖到个位数看起来像幻灯片。我的处理方式是摄像头线程只负责采集最新帧推理线程有结果就刷新显示控制间隔在100毫秒左右相当于10FPS的检测效果。这个频率对路面巡检场景来说完全够用而且肉眼看起来是连续流畅的。7. 从Python原型到实际部署性能优化和边缘设备移植路线最后聊一下这套系统从“实验室能跑”到“现场能稳定工作”的进阶路线这部分也是很多工程项目真正关心的地方。7.1 先解决推理速度瓶颈Python下的ultralytics推理即使模型已经加载到显存每帧还有不少时间浪费在图像预处理、NMS和mask解码上。如果要在工业环境做到更快的处理速度第一步是导出成TensorRT engine。流程不复杂先是pt导出onnx再做TensorRT转换可以用FP16精度。我实测过同一个yolov8n-seg模型在GTX1660Ti上FP16的TensorRT推理比原生PyTorch快大约1.5到2倍从30多毫秒降到20毫秒上下。如果是RK3588这类带NPU的边缘开发板路线就是pt转onnx再转rknn量化后延迟能压到更理想的范围但要注意某些算子在NPU上的兼容性问题。7.2 分割结果的后处理mask平滑和面积估算拿到模型输出之后工程上往往还要做一步后处理。坑洞分割的mask边缘经常有毛刺和孔洞可以用cv2.morphologyEx做闭运算填充小孔再用findContours提取轮廓过滤掉面积过小的噪点区域。如果要估算坑洞面积需要先知道像素坐标系和实际物理坐标系的换算比例最简单的方法是在现场用标定板或已知尺寸的参照物标定然后对mask像素做积分。这部分在当前系统中预留了计算接口接上现场标定参数就能出面积报告。7.3 项目二次开发的几个方向这套系统后续可扩展的方向我很推荐两个一是把单帧检测升级成视频时序追踪这样能对同一坑洞做多帧的尺寸变化分析评估病害发展速度二是增加数据回传机制现场检测到的坑洞图自动保存并定期补充到训练集里继续微调模型越用越准。这些在目前代码结构上都不需要大改在推理线程里加存储逻辑在训练脚本里追加增量数据即可。我个人在实际操作中最深的体会是路面坑洞检测项目的瓶颈从头到尾都不是模型结构而是数据质量。坑洞长得不像通用物体那样有清晰确定的边界阴影、井盖、油渍都在挑战模型的判断力。把精力花在收集更多样化的现场数据、仔细检查和修正标注边界、针对误检样本做迭代训练上远比反复调整网络结构或训练参数更有效。这套系统提供的完整训练链路正好把这些环节全部打通了拿到手之后按自己的场景补充数据重新训练就能产出一个真正能用的病害检测工具。