改进YOLOv8枣子图像分割系统：数据集闭环与结构调优

简介这是一套面向计算机视觉研究者和开发者的枣子图像分割解决方案核心是基于改进YOLOv8的两套模型——yolov8-seg-RepHGNetV2和yolov8-seg-AFPN-P345适用于需在复杂背景中精确识别与分割枣子图像的实际落地场景同时也可为其他小目标或农产品图像分割任务提供迁移参考。压缩包为zip格式共27个文件包含4个Python脚本训练、预测、验证及UI界面、19张标注示例图片、2份Word说明文档、1份TXT指南和1份Markdown文档整体仅4.66MB结构紧凑便于快速浏览。目前该资源已有279人学习浏览。作为核心价值系统集成了50多种创新改进点——RepHGNetV2通过重复高阶群组网络强化特征提取AFPN-P345借助注意力特征金字塔网络提升多尺度识别精度并支持一键训练脚本大幅降低复现门槛。附赠资源文档涵盖数据集说明、网络拓扑细节及参数配置配合环境部署说明使初、中级开发者也能较快完成从环境搭建到模型训练的完整流程。1. 基于改进YOLOv8的枣子图像分割系统不是调参游戏是把数据集做成闭环做农业视觉的同学应该都有同感目标检测框框住的是“枣子在哪”可你要的是“枣子有多大、有没有被叶子挡住、能不能算出产量”——这时候就得靠图像分割。这套基于改进YOLOv8的枣子图像分割系统本质上是把实例分割任务落到了果园场景用YOLOv8-seg作为基线换来换去地替换骨干网络和特征融合结构源码包里预置了RepHGNetV2、AFPN-P345等50多种创新改进点还绑了一份已经标注好的枣子数据集。对想用YOLOv8训练自己数据集的从业者来说它的价值不是“换个模型涨点”而是一个完整可复现的落地样板从数据标注、结构改动、训练配置到推理验证每一步都有现成脚本。这篇就按我实际跑这类项目的顺序拆开讲哪些能直接抄哪些得按你的场景重调我会把参数和坑都标明白。2. 数据是第一根骨头枣子数据集的标注、转换与装载2.1 labelme标注结果怎么变成YOLOv8-seg能吃的txt转换脚本YOLOv8-seg训练时标签不是labelme的JSON也不是COCO的JSON而是跟每张图片同名的txt文件。每一行表示一个实例格式是class_id x1 y1 x2 y2 x3 y3 ...注意多边形坐标直接给出绝对像素值不是归一化坐标类别号从0开始。我第一次转的时候没注意归一化后mAP直接崩到0.2以下。转换脚本核心逻辑如下import json import os import cv2 import numpy as np def labelme_to_yolov8_seg(labelme_json_path, output_txt_path, class_map): labelme JSON - YOLOv8-seg txt class_map: {zao: 0, zao_occluded: 1} with open(labelme_json_path, r, encodingutf-8) as f: data json.load(f) img cv2.imread(data[imagePath]) h, w img.shape[:2] lines [] for shape in data[shapes]: label shape[label] if label not in class_map: continue # 标注里可能有临时加的废标签直接跳过 points shape[points] # shape: [[x1,y1], [x2,y2], ...] if len(points) 3: continue # 少于3个点的多边形没法构成分割掩码 class_id class_map[label] # 注意YOLOv8-seg直接要像素坐标不要再除以宽高 coords [] for px, py in points: coords.append(f{px:.2f} {py:.2f}) line f{class_id} .join(coords) lines.append(line) with open(output_txt_path, w) as f: f.write(\n.join(lines)) # 遍历整个标注目录 json_dir ./labelme_jsons txt_dir ./labels os.makedirs(txt_dir, exist_okTrue) class_map {zao: 0, zao_occluded: 1} for jf in os.listdir(json_dir): if not jf.endswith(.json): continue txt_name jf.replace(.json, .txt) labelme_to_yolov8_seg( os.path.join(json_dir, jf), os.path.join(txt_dir, txt_name), class_map ) print(转换完成)这段代码里有两个关键点。第一是坐标精度px:0.2f保留了足够的小数位实测直接用整数坐标在高分辨率图像上会丢失几个像素的边缘在分割任务里这会影响边界处的mAP尤其是枣子这种小目标。第二是跳过少于3个点的多边形labelme里手滑点出两个点的情况很常见不处理会在训练时报ValueError: not enough values to unpack。转换后务必抽样检查打开一张图和对应的txt把坐标画回图上对比多边形位置。另外这类源码包里的数据集通常已经做过一次转换了。你拿到的目录一般是images/与labels/两个文件夹labels里是上面说的txt格式。最好自己写个脚本统计一下每个txt的行数和点数防止打包过程中有截断或乱码。我用的是几行bash# 检查空标签和异常小文件 find labels/ -name *.txt -size -30c | head -20 # 统计标签数分布 for f in labels/*.txt; do echo $(wc -l $f); done | sort -n | uniq -c空标签文件在YOLOv8里不报错但会拖慢收敛标签数超过30个的文件多半是标注时把背景也圈进去了建议直接用Labelme重新标记。2.2 数据集目录结构与第一次smoke test拿到源码包后别急着改网络结构先把目录结构对齐到YOLOv8的预期。标准结构是这样的dataset/ ├── images/ │ ├── train/ # 枣子园实地照片 │ └── val/ # 与train不同时间/不同树拍的照片 ├── labels/ │ ├── train/ │ └── val/ ├── dataset.yaml # 训练入口配置 └── test/这里有个容易踩的暗坑很多公开数据集里train和val是随机划分的同一个枣子串会同时出现在两边。这会让验证mAP虚高因为模型见过这些目标的“近亲”。我一般按时间或按果树编号划分宁可训练集少20%也要保证验证集是真正没见过的树。源码包里的dataset.yaml长这样# dataset.yaml path: /path/to/dataset # 换成你自己的绝对路径 train: images/train val: images/val # 类别顺序和转换脚本里的class_map一致 names: 0: zao 1: zao_occluded改完yaml后跑一个10轮的smoke test而不是直接上完整训练。这步的目的是确认“数据能喂进去、loss能降、验证能跑”而不是追求精度。命令是python train.py --model yolov8s-seg.yaml \ --data dataset.yaml \ --epochs 10 \ --imgsz 640 \ --batch 8 \ --device 0如果10轮跑下来loss从初始值明显下降说明数据链路没问题。如果loss不降或者验证mAP一直是0先回头查标签格式不要碰网络结构。这里有个经验我在第一次跑类似分割项目时因为points顺序写反了x和y颠倒前20轮loss不降反升白白浪费了大半天。2.3 先别急着训5分钟做数据分布体检在没有看到测试集效果之前先对数据本身做体检。图像分割翻车一半以上是数据问题而不是模型问题。我会用Python脚本快速看三个分布类别数量、目标大小、目标位置偏移。import os import glob import numpy as np label_files glob.glob(labels/train/*.txt) class_counts {} sizes [] centers [] for f in label_files: with open(f) as fp: for line in fp: parts line.strip().split() cls parts[0] coords np.array(parts[1:], dtypenp.float32).reshape(-1, 2) class_counts[cls] class_counts.get(cls, 0) 1 x_min, y_min coords.min(axis0) x_max, y_max coords.max(axis0) sizes.append((x_max - x_min) * (y_max - y_min)) centers.append([(x_min x_max) / 2, (y_min y_max) / 2]) print(类别分布:, class_counts) print(目标面积p50/p90:, np.percentile(sizes, [50, 90])) centers np.array(centers) print(中心点均值:, centers.mean(axis0)) # 理想情况应在(0.5, 0.5)附近这里最值得关注的是目标面积p50/p90。枣子属于中小目标如果p50面积占整图的比值小于0.01说明大部分目标在32x32像素以下假设输入640那么在原版YOLOv8的P5特征层下这些小目标很容易被下采样丢了。如果目标是这个尺寸分布后面换AFPN-P345或加P2头就比较必要这就是结构改进的现实依据——不是为换而换是数据逼的。中心点均值如果偏到一侧比如长期偏向(0.7,0.5)那模型会对图像左侧的枣子学习不充分需要做随机翻转或者移动增强。3. 网络结构改进RepHGNetV2与AFPN-P345的改动位置与落地细节3.1 改进点选型策略50多个改进点为什么先动骨干和neck源码包号称50多种创新改进点听起来唬人实际上一半以上是注意力机制模块SE、CBAM、CA、EMA之类和激活函数替换SiLU换HardSwish、Mish。我的经验是改这些模块对分割任务收益有限不如先把骨干和特征融合搞定。因为枣子分割的难点不在“分类分不准”而在“小目标边界分割得细不细”——这属于特征表达能力的问题骨干决定了特征的上限neck决定了不同层特征怎么融合。所以第一次动手只改RepHGNetV2骨干和AFPN-P345融合结构别贪多两个改动叠加出问题了你很难定位是谁的锅。3.2 RepHGNetV2把重参数化塞进高分辨率骨干RepHGNetV2这个名字其实是两个东西缝合的RepVGG的重参数化思想和HGNetV2的高分辨率宏块设计。通俗解释RepVGG那套是“训练时用多分支推理时融合成单路3x3卷积”让模型训练能力强、推理速度快。HGNetV2的思路是保持高分辨率特征图不把下采样做得太狠整套网络停留在高分辨率阶段更久保证小目标的细节不丢。在YOLOv8里换骨干核心是改yaml。源码包里的yaml文件结构是这样的# yolov8s-seg-RepHGNetV2.yaml backbone: - [-1, 1, HGStem, [32]] # P1 高分辨率stem - [-1, 1, RepVGGBlock, [64, 3, 2]] # P2 下采样通道翻倍 - [-1, 1, HGBlock, [128, 3, 2]] # P3 从这里开始进neck - [-1, 1, HGBlock, [256, 3, 2]] # P4 - [-1, 1, RepVGGBlock, [512, 3, 2]] # P5 head: - [-1, 1, AFPN_P345, [128, 256, 512]] # 替换原PANet ...这能直接跑但有几处要按显存调HGStem的通道数32在分辨率超过1280的输入下显存占用倍增RepVGGBlock的stride2放在下采样点推理时可以重参数化成单路卷积导出ONNX时结构更干净。源码包里的models/backbone/rep_hgnetv2.py通常要注册到YOLOv8的模型工厂里。注册方式# models/__init__.py 或 models/yolo.py 里追加 from .backbone.rep_hgnetv2 import HGStem, HGBlock, RepVGGBlock def parse_model(d, ch): ... if m in {HGStem, HGBlock, RepVGGBlock}: # 按yaml里的参数实例化 m m(*args)这里避坑提醒YOLOv8的parse_model对自定义模块有一个隐性约束——模块的forward返回值必须直接是特征图不能像原来的C2f那样返回tuple。如果HGBlock里有残差结构初始化时要保证shortcut通道数匹配否则第一次forward就报shape error。我在第一次接入时就犯了这个错把HGBlock的shortcut写成了固定identity结果下采样层输入输出分辨率不一致直接崩。正確写法是当stride2时不加shortcut或者用1x1卷积做shortcut投影。3.3 AFPN-P345串行特征融合专治枣子小目标和遮挡AFPNAsymptotic Feature Pyramid Network的核心思路是传统PANet是“自顶向下自底向上”的双向融合而AFPN把不同层特征按分辨率从高到低串行融合——高分辨率特征先融入低一层再把融合结果继续往下融逐步逼近最终预测。P345表示只用P3、P4、P5三层不要P2。对枣子这种不算极小目标但容易互相遮挡的场景P3、P4两层就够了P2层计算量太大。源码里AFPN_P345的模块定义主题逻辑长这样class AFPN_P345(nn.Module): 串行融合 P3-P4-P5。 每步融合使用自适应加权fusion_weight sigmoid(conv(cat(f1, f2))) def __init__(self, c3, c4, c5, out_channels(128, 256, 512)): super().__init__() self.reduce3 Conv(c3, out_channels[0], 1) # 1x1降维 self.reduce4 Conv(c4, out_channels[1], 1) self.reduce5 Conv(c5, out_channels[2], 1) self.fuse34 nn.Sequential( Conv(out_channels[0] out_channels[1], out_channels[1], 3), nn.Sigmoid() # 输出0~1融合权重 ) self.fuse345 nn.Sequential( Conv(out_channels[1] out_channels[2], out_channels[2], 3), nn.Sigmoid() ) def forward(self, p3, p4, p5): p3 self.reduce3(p3) p4 self.reduce4(p4) p5 self.reduce5(p5) # 先上采样p3到p4尺寸加权融合 p3_up F.interpolate(p3, sizep4.shape[-2:], modebilinear, align_cornersFalse) w34 self.fuse34(torch.cat([p3_up, p4], dim1)) p4_new p4 w34 * p3_up # 残差式融合保留原始p4信息 # 再上采样融合p4_new到p5尺寸 p4_up F.interpolate(p4_new, sizep5.shape[-2:], modebilinear, align_cornersFalse) w45 self.fuse345(torch.cat([p4_up, p5], dim1)) p5_new p5 w45 * p4_up return p3, p4_new, p5_new这段代码有三个细节值得说。第一是融合权重用的是Sigmoid而不是Softmax。Softmax会把两个输入的权重互相压制Sigmoid是独立门控语义是“P3的信息对当前位置是否重要”权重可以同时接近1或0表达能力强。第二是每次融合都保留原始特征图做残差这样即使融合学到权重接近0性能也不会低于原版PANet——这也是AFPN涨点的一个结构性保证。第三是AFPN里没有再用3x3卷积做特征精炼这对分割头的mask输出有好处mask分支更容易保留空间细节。接入yaml时有一处容易翻车AFPN_P345返回的是(p3, p4_new, p5_new)但YOLOv8_head部分期望的输入是backbone的[p4, p5]因为原版PANet只用两层。你需要在yaml里显式写成[[-1, 3], 1, AFPN_P345, ...]这样在YOLOv8的parse_model里才会把前3个层输出一起喂给AFPN。如果你拿到某个版本源码只改了yaml没改parse_model训练时会报AssertionError: number of inputs does not match这时候去yolo.py里给AFPN单独加一个分支即可。4. 一键训练与调参从源码包里的train.py跑通第一次训练4.1 一键训练一键是理念不是黑匣子源码包里的“支持一键训练”不是说双击一个exe就完事而是提供了一个封装好的train.py把环境检查、数据校验、模型加载、训练、日志保存全串到一个入口里。这种设计对从业者很友好尤其是刚接触YOLOv8训练自己的数据集的同学不用一行行敲ultralytics的命令。入口脚本长这样python train.py \ --model yolov8s-seg-RepHGNetV2.yaml \ --data dataset.yaml \ --epochs 300 \ --batch 16 \ --imgsz 640 \ --device 0 \ --project runs/zao_seg \ --name exp01脚本内部做的事按顺序是检查dataset.yaml里的路径是否存在、检查labels文件夹是否有空标签、自动下载COCO预训练权重如果没有、实例化模型、开始训练。你要知道的是这些封装脚本的默认值往往不适合你的数据比如源码默认imgsz640但如果你做的是无人机俯拍枣树一个画面里可能只有20个枣子每个都很小640完全够如果是近景拍摄、单帧50个枣子640就偏低了建议提到960甚至1280。实践里我一般会先跑一个20轮的快速实验主要验证封装脚本有没有隐藏bug比如路径写死、类别数写死这类问题。我之前用过类似源码包里面dataset.yaml写死了path: /home/user/dataset改脚本不换路径训练直接报File not found——这类问题很折腾人但别急着骂作者自己建个软链接或改配置就行。4.2 训练配置里最值得调的8个参数训练分割模型参数比网络结构更容易被忽略。我不建议跑一趟300轮的点名表扬实验建议先关注下面这8个参数参数建议值范围作用与踩坑说明lr00.0010.01初始学习率。分割任务比检测更容易发散超过0.01经常前10轮loss就NaNlrf0.010.1最终学习率系数。lrf0.01表示训练结束时的lr是初始的1%momentum0.90.94SGD/AdamW动量。batch较大时可取0.94稳定性更好weight_decay0.00010.0005权重衰减。分割任务建议0.0003附近太大的话过拟合不会缓解反而bbox回归变差box7.515边框损失权重。枣子重叠多时调到12-15不然预测框会偏大cls0.52.0分类损失权重。枣子和枣子被遮挡是两种类别时这里至少设1.2不然模型对遮挡样本不敏感dfl1.54.5分布焦点损失权重。对分割其实影响边界质量建议保持默认hsv_h / hsv_s / hsv_v0.01 / 0.5 / 0.4颜色增强。枣子在光照变化大的环境不要把hsv_s设到0.8以上否则红褐色会变成灰色模型学到的是异常色彩这里重点说cls。我最早跑枣子分割时只分一个类模型在遮挡严重时会把两个枣子合并成一个掩码怎么调结构都没用。后来重新标注把“被叶子遮挡的枣子”单独作为一类cls提到1.5问题明显改善。与其疯狂改网络结构不如先看看你的类别定义能不能让模型更好学——这是一个分水岭认知改进YOLOv8的“改进”不只在结构也在任务定义和数据设计。4.3 用TensorBoard和results.csv看训练是不是翻车了训练过程中除了盯着终端输出的loss数字我建议直接把results.csv拖出来画loss曲线。源码包里的train.py会在runs/zao_seg/exp01/下生成这个文件里面包含每轮的train/box_loss、train/seg_loss、train/cls_loss、metrics/mAP50(B)等列。我用来判断是否正常的标准前10轮box_loss和seg_loss必须同步下降如果seg_loss上升而box_loss下降多半是mask分支的head输出分辨率不对第50轮之后mAP50(B)应该超过0.5不到的话不是网络问题先回头查标签质量和类别定义val/cls_loss曲线如果先降后升这是过拟合信号调大weight_decay到0.0005或者把epochs降一半跑早停可视化损失曲线用一句话命令tensorboard --logdir runs/zao_seg打开浏览器看SCALARS页面。这里有个容易忽略的点train/seg_loss不是平滑曲线单看一轮没意义至少要放大到10轮窗口看趋势。这份源码包里最容易被低估的是results.csv里的metrics/mask_mAP50-95(M)列因为很多人只盯mAP50(B)对分割任务来说mAP50-95(M)才是真实困难度如果它很低说明mask边缘粗糙这就要回到AFPN的融合权重去看是不是低分辨率特征占主导了。5. 训练与数据动不动翻车5条真实踩坑记录与排查路径5.1 loss曲线全部NaN前几轮mAP直接0这个现象在刚集成Custom backbone后非常常见。训练到第10轮左右终端打印的box_loss值突然变成nan之后每一轮都nanmAP是0。原因基本是三个学习率太大、标签里有非法坐标、yaml里网络输出通道数不匹配。我遇到最多的是第三种——换RepHGNetV2后backbone的P5输出通道数写了[512]但head侧AFPN的输入通道还是[128,256,512]实际P3输出是128P4是256P5是512通道对不上但PyTorch不报错初始化的bn层在训练时统计到异常值就nan了。排查路径是先把lr0降到0.0001跑5轮如果不再nan就是lr问题再跑标签校验脚本把超出图像边界的坐标clip掉最后再回头检查yaml里所有通道数字是否与模块实际输出一致。这条血泪经验就是所有自定义结构都要写一个fake input的单模块输出测试几行代码就能避免半天nan排查import torch from models.backbone.rep_hgnetv2 import HGBlock m HGBlock(128, 256, stride2) x torch.randn(1, 128, 80, 80) y m(x) assert y.shape (1, 256, 40, 40), y.shape # 预期下采样一次 print(模块输出shape正确通道和分辨率匹配)5.2 尺寸参差不齐的数据集喂进去训练越训越崩枣子果园实拍数据里长宽比从1:1到2:1的都有。YOLOv8默认rectFalse会强制resize到正方形640x640枣子本身细长拉伸后多边形坐标严重变形。这个问题的直接现象是训练能跑完但val阶段mask预测总是偏胖或偏瘦。解决方式有两种一是训练时开启rectTrue让同一个batch内的图保持原始宽高比只做零填充二是如果为了保持rectFalse的简单逻辑就把imgsz提高到960让拉伸比例从1.5倍降到1.05倍以内。训练时加一句python train.py ... --rectrect模式会打乱batch内的图像顺序体现在代码上就是dataloader不再按图像排列索引而是按aspect ratio聚类。如果你用了自己写的tiling脚本需要注意rectTrue时batch尺寸会随数据集变化Loss曲线会比正常噪声大不是bug不用慌。真正要防的是验证集不能用rect因为验证mAP是按原始尺寸计算的你希望它反映真实性能。5.3 验证mAP很高但实际图像上一个枣子都分不出来这是最玄学的一种翻车一张实拍图上枣子明明很多模型要么漏检要么mask糊成一片。原因大概率是训练时augmentation设置过强。YOLOv8默认开了mosaic、mixup、copy-paste这对大目标检测效果好但枣子这种小目标mosaic会把目标缩得更小边缘信息被mixup污染模型学到的是“模糊的枣子形状”。经验是分割任务把mosaic在最后30轮关闭只保留轻微翻转--mosaic 0.5 --mixup 0就是让模型在最后阶段从“真实分布”里微调一遍。如果关掉增强后验证集mAP下降但实拍效果好很多那说明你的验证集本身和训练集分布太接近了模型过拟合到了augmentation风格上。这个问题是分割任务特有的因为mask比bbox对像素分布更敏感。另有一层原因你如果加了hsv_h强度过高模型学习到的颜色特征被扭曲跑到真实环境里就失效。这时候去看训练集的增强后图像别信眼直接存图看from ultralytics.data.augment import visualize_augment visualize_augment(dataset.yaml, output_dirdebug_aug/) # 保存增强结果5.4 CPU环境ubuntu20.04训练慢到怀疑人生很多人拿到源码包第一步就是在老笔记本上python train.pyCPU训练YOLOv8-seg是什么体验以s级模型为例imgsz640, batch4在纯CPU上大概每秒1.5步300轮要跑三天三夜。这不是环境坏了是算力不够。在两个选择里权衡一是云端GPU另一个是把imgsz降到480、batch降到2、epochs降到100先把流程跑通再用GPU上全量。在ubuntu20.04下搭CPU环境其实无坑只要注意torch版本和numpy的兼容用pip装即可。但如果你准备认真做建议直接租卡。模型训练是黑匣子你用CPU看不到实验结果就没有迭代动力这钱省不了。5.5 换backbone后模型下载不了预训练权重每次改动骨干网络YOLOv8的自动下载逻辑只认默认权重名。你改成了yolov8s-seg-RepHGNetV2.yaml它会尝试找yolov8s-seg-RepHGNetV2.pt下载必然404。源码包作者一般会在weights/目录放一份适配过的预训练权重但如果你自己进一步改了结构这份权重同样不可用。处理办法是分两阶段训练先不改neck只换backbone加载原始yolov8s-seg.pt冻结head前30轮只训backbone再把AFPN接上加载上一步的last.pt继续训练。这个过程用官方YOLOv8语义分割训练命令# 阶段1backbone适配冻结head yolo segment train \ --model yolov8s-seg-RepHGNetV2.yaml \ --data dataset.yaml \ --pretrained yolov8s-seg.pt \ --freeze 10 \ --epochs 50 # 阶段2全网络微调 yolo segment train \ --model yolov8s-seg-AFPN-P345.yaml \ --data dataset.yaml \ --pretrained runs/segment/train/weights/last.pt \ --epochs 250这里--freeze 10表示冻结前10层对不同yaml结构层索引会漂移我一般先用python -c打印每层名称再定freeze数。这条路径虽然多花两小时但比直接下载不到权重干等着强太多。6. 验证结果与再往前一步画mask、导出、迭代训练结束后源码包的predict.py已经封装好了推理脚本直接指定模型权重和图片目录即可。但我一般不用它的输出自己写验证脚本原因是要同时看两样东西预测的mask和真实标注的mask对比。单独存一个目录方便后期给标注人员反馈。python predict.py \ --weights runs/zao_seg/exp01/weights/best.pt \ --source test/ \ --imgsz 640 \ --conf 0.35 \ --iou 0.45 \ --save-txt \ --save-mask这里conf是置信度阈值iou是NMS阈值。枣子分割场景与其他目标不同conf设0.35比设0.5合适——枣子目标小、置信度普遍偏低设置高了漏检严重。iou设0.45不要动太狠枣子重叠部分多过高的NMS阈值会保留大量重复mask后续统计产量时会把同一个枣子算两次。验证的下一步不是直接看mAP而是挑五张典型图近景单果、远景多果、遮挡严重、逆光、夜晚补光各一张用cv2.addWeighted把mask和原图按0.5叠加分别打印每张图的分割目标和mAP。这里有一个我一直在用的硬性指标mask和枣子实际轮廓的IoU用标注原图验证比单看mAP50-95具体得多。如果mask明显比枣子大一圈说明分割边界处理得太“胖”优先检查是不是dfl权重太低和mask分辨率被下采样到原始尺寸的1/4导致的——import cv2 import numpy as np # 已有mask预测结果 pred_mask.png 与原图 image.jpg img cv2.imread(test/image.jpg) mask cv2.imread(pred_mask.png, cv2.IMREAD_GRAYSCALE) overlay img.copy() overlay[mask 127] (0, 0, 255) blend cv2.addWeighted(img, 0.5, overlay, 0.5, 0) cv2.imwrite(debug_overlay.jpg, blend)这套验证逻辑跑完后下一步通常是导出ONNX做边缘部署。用onnx导出时重参数化的RepHGNetV2会自动折叠成单路卷积结构清爽很多。注意导出时设置--opset 12RK3588、Jetson这类平台都吃这个版本。导出命令是yolo export modelbest.pt formatonnx opset12 imgsz640 dynamicTrue如果你要部署到RK3588这类NPU设备还需要把ONNX转成RKNN格式那个坑更多NMS算子经常不被支持需要在板端自己写后处理。我一般建议先验证onnx的mAP和PyTorch原模型差异小于0.01再谈板端移植。导出后一定要跑一遍同一批验证图片对比mask可视化因为dynamicTrue会导致输入尺寸变化时输出mask的shape映射出错这是落地时最容易翻车的一环。最后分享一条我的习惯这类源码包的改进点我拿到手不会全叠加先把RepHGNetV2和AFPN-P345单独各跑一版分别记录mAP、参数量、推理延迟再决定是否合到一起。50多个改进点不是让你一次全上的有些组合是负优化你得亲手验证哪几个真正适合你的数据。训练分割模型最怕的是看着TensorBoard曲线上涨就以为万事大吉实际模型放到果园里一测全是漏检。每轮实验把可视化结果存出来在真实图像上多翻几遍这比mAP数字更能帮你判断跟这个项目“对不对路”。希望帮到你。本文还有配套的精品资源点击获取