做农业视觉有一段时间的朋友，应该都有这种体会：果实的成熟度判断，远比想象中复杂。尤其是柑橘，颜色跨度大，果面又被树叶挡得严严实实，目标检测框一框下去，框里既有果皮也有叶子，成熟度判断完全不靠谱。所以我和团队在做某个采摘机器人的识别模块时，干脆放弃了纯检测方案，改走像素级分割路线。整个项目最终沉淀下一套可以直接复用的数据资产：3089张柑橘图像的成熟度分割数据集，LabelMe格式标注，3个成熟度类别。这篇文章就围绕这套数据集，从方案选型、类别设计、标注规范、格式处理到训练验证，完整复盘一次，给做智慧农业视觉的朋友一些可参考的实操经验。
这套数据集比较适合三类人：一是做采摘机器人识别算法的研发人员，需要带像素级标注的数据来做预训练或算法验证；二是做果园巡检、产量预估产品的工程师，想训练一个成熟度分布统计模型；三是刚接触分割任务的学生或开发者，需要一份干净的实例分割数据来做基准测试。3089张的体量不算大，但在标注成本上已经是一笔不小的投入，用好了，足够支撑一个稳定的分割基线。
1. 项目整体思路与方案取舍
1.1 为什么成熟度问题必须用分割而不是检测框
先聊方案选型。市面上很多农业视觉产品还停留在目标检测阶段，用YOLO这类模型给果实画一个矩形框。矩形框最大的问题在于，实际果园里的果实不是孤零零挂着的。叶子会盖住一部分果面，枝条会横穿果体，两个相邻果实经常挤在一起。这时候框出来的是"果实加遮挡物"的混合区域，成熟度特征被严重污染。比如一个青果被黄叶挡住，检测框内的平均颜色可能已经偏黄，成熟度判断自然就出错了。
分割完全绕开了这个问题。它对覆盖区域逐像素做判断，输出的是一张和果实轮廓高度吻合的掩码图，果面真实的颜色、纹理、光泽都来自果实可见部分，不会被背景干扰。在成熟度识别场景里，这几乎是刚需，因为柑橘成熟度的核心信号就是果皮颜色分布和光泽状态。你要看的是果皮本身，而不是果实周围那一块。所以项目定下的第一条原则就是：直接做分割，不做框。
这背后还有一个实际业务考量。采摘机器人不仅要识别果实熟不熟，还要估计可采摘面积有多大。有了像素级掩码，就能算出果面可见面积比例，从而推断有没有足够的抓取空间。如果只是目标检测框，这部分几何信息完全丢失，后端机械臂的路径规划就很难做精细。采摘是分秒必争的活，几何信息的价值在这个环节体现得特别明显。
1.2 数据规模和标注格式的选择逻辑
3089张图像的规模看起来不大，但结合分割标注的成本来算，这个体量是经过认真权衡的。实测下来，一张果树密集、果实重叠严重的图像，标注一个多边形实例大概需要25到40秒，多实例单张累加后要一分钟以上。算上边缘细化和后期审核，单张图的平均耗时通常超过90秒。如果按1.5分钟一张、两人并行工作来估算，3089张意味着接近80小时的纯标注劳动量，这还不包括返工和审核。所以没有盲目追求上万张，而是把精力花在保证每一张的标注精度上。
格式选择落在LabelMe上，原因也很直接。LabelMe的标注本质是一串多边形点坐标，可以非常精细地贴合果皮轮廓，这是很多结构化标注格式替代不了的。相比之下，VOC格式在实例边界的表达上比较粗糙，COCO格式更偏重机器可读性，人工编辑时不够直观。LabelMe天然适合"先从果皮边缘框起、再携带类别信息"的工作流。而且LabelMe往COCO或者其它格式转换，只需要一次性写一个脚本，成本几乎可以忽略。对绝大多数农业视觉团队来说，这已经是一个足够顺手的选择。
这里插一个细节：LabelMe的JSON文件里有一个imageData字段，既可以存图像的base64编码，也可以设为null。为了便于代码读取和文件管理，我们选择把图像文件单独存放，JSON里只保留imagePath和宽高信息，避免每张图在标注文件里重复躺一份大体积编码。这样做还有一个好处，图像存在网络存储或者本地方便路径同步，JSON文件很小，拉取和备份都很快。
1.3 三个成熟度类别怎么定出来的
类别体系是这类数据集的核心。最开始评审过两个极端方案：一个是"二值化"，只分未熟和成熟；另一个是"精细化分级"，按商业收购标准分成五六档。两个方案最后都否掉了。档位太少，模型对过渡期的果实完全没有感知能力，可黄绿相间的过渡果实恰恰是果园里最常见的状态；档位太多，标注员之间的一致性很难保证，标注质量的方差会超过模型本身的误差。
最终定成未成熟、半成熟、成熟三个档位，判断依据集中在果皮颜色占比和光泽度上。未成熟类以深绿色果皮为主，果面光泽度低，偶尔带浅绿色斑块；半成熟类是黄绿夹杂或者整体转为黄色、浅橙色，果面开始出现反光；成熟类则是橙红到橙黄色占据绝大部分果面，光泽明显。这个划分不是拍脑袋，参考了果业常用的果实色泽分级逻辑，同时简化到让不同标注员能快速达成共识的程度。实测下来，标注组内一致率能稳定在95%左右，这个结果远好于当初多档位方案的小范围测试。
2. 类别定义与标注规范
2.1 三个成熟度档位的速查规则
为了让标注规则足够机械和可执行，我们专门做了一张速查表，挂在标注界面旁边。遇到拿不准的样本，先查表再落笔，而不是凭个人经验去猜。这里把核心内容整理出来：
| 类别 | 典型外观 | 判断要点 | 常见易混情况 |
|---|---|---|---|
| immature（未成熟） | 以深绿、绿色为主，果面无明显反光 | 绿色面积超过80%；表皮较粗糙 | 被阳光直射到局部发黄的老青果 |
| semi-mature（半成熟） | 黄绿相间、整体黄色或浅橙色 | 绿色面积在20%到80%之间；果面光泽有过渡 | 青果晒出黄斑、成熟果局部返青 |
| mature（成熟） | 橙红、橙黄色为主，光泽明显 | 绿色面积低于20%；果皮颜色均匀 | 浅橙色的晚熟果容易和半熟类混淆 |
这张表的核心价值，是把主观视觉判断转换成可量化的面积比例。标注员不需要像农艺专家一样凭感觉判断，只要在画多边形之前，先肉眼估算一下果皮绿色面积占比就够了。规则越机械，标注一致性越好，后续模型训练就越省心。真实处理中经常遇到"黄绿边界到底算哪一类"的争议，最后我们的裁决原则是：绿色面积卡在50%左右的归半熟，明显超过80%的归未熟，明显低于20%的归成熟。
2.2 图像采集环境与多样性设计
数据集的落地能力，图像多样性比数量更关键。采集阶段刻意覆盖了多种果园环境：晴天直射光、阴天散射光、早晨逆光、傍晚低照度；树冠外围果和树冠内层果；采摘前期的黄果和留树保鲜期的深橙果。之所以反复强调光照场景，是因为成熟度的核心特征是颜色，而颜色信息在不同色温下会剧烈变化。如果训练集里全是晴天正午的顺光照片，模型一到阴天或者逆光环境就会明显失准。
同时，我们按果实个体而不是图像来划分数据。同一个小枝条上连续拍的几张照片里，很可能包含同一颗果实。如果这些相似图像被动地同时落进训练集和测试集，模型相当于提前看到了答案，测试指标会虚高。我们建立了一个粗粒度的果实去重流程：先按果园区域和时间批次做人工筛选，再用特征匹配跑一遍疑似重复检测，尽量保证同一个果实在不同数据子集里最多出现一次。
采集时还专门记录了一些元信息，比如拍摄日期、天气、果园编号、树龄。这些信息在训练阶段可能用不上，但在分析模型错误时非常有用。比如某段时间测试结果突然变差，翻元信息一看，可能是新增了一批不同品种的柑橘图像，果皮纹理差异导致模型泛化能力下降。没有这些记录，排查会非常被动。
2.3 LabelMe标注操作的几个关键细节
标注流程本身不复杂，但有几个细节很容易被忽略。
第一，画多边形时，每个果实至少点8到12个控制点。拐弯处密集一点，直边处稀疏一点，让曲线尽可能接近真实果皮轮廓。如果控制点太少，边缘会变成一条粗糙的折线，后续生成的掩码会丢失真实的弧形边界信息。第二，遮挡要诚实标注。果实被树枝横向穿过时，只沿着可见果面的边界画，不要试图"脑补"完整果实轮廓。分割掩码追求的是可见区域准确，而不是果实物理意义上的完整形状。这直接影响机械臂的抓取判断，宁可边界保守，也不能把枝叶区域混进果实掩码。
第三是标签命名的一致性。全程必须使用统一的英文小写命名，比如immature、semi_mature、mature，坚决不允许出现"未熟1"、"green2"这种变体。标注期间偶尔会出现同一类别被不同标注员写成不同字符串的情况，我们每周汇总一次label统计，发现异常别名立刻批量替换。第四，每人每天标注量控制在80张以内，并在团队里安排一位审核人做随机抽查。抽查重点不是看多边形画得好不好看，而是看类别是否错分、遮挡边界有没有被明显扩大。单个图像不合格会被退回，同一批次退回率超过15%就整批重标。
3. LabelMe标注文件格式解析与自动化处理
3.1 标注文件的关键字段结构
LabelMe的标注文件是JSON，每个图像对应一个JSON文件。一个典型的标注结构是这样的：
{ "version": "5.0.1", "flags": {}, "shapes": [ { "label": "mature", "points": [ [283.4, 194.2], [301.8, 182.6], [353.5, 177.1], [382.9, 198.7], [351.2, 238.3], [300.6, 239.5] ], "group_id": null, "shape_type": "polygon", "flags": {} }, { "label": "immature", "points": [ [512.7, 421.5], [529.4, 405.8], [560.3, 422.1], [551.0, 455.3], [523.8, 458.0] ], "group_id": null, "shape_type": "polygon", "flags": {} } ], "imagePath": "IMG_1023.jpg", "imageData": null, "imageHeight": 1080, "imageWidth": 1920 }几个关键字段一定要搞清楚。shapes是一个列表，里面每个对象代表图中的一个实例多边形。label是类别名，points是多边形坐标点序列，顺序就是鼠标点下去的顺序，构成一条闭合边界。shape_type固定为polygon。imagePath指向对应的图像文件，imageData我们统一设为null，避免JSON文件体积失控。imageHeight和imageWidth是从图像元数据直接读出来的，后续做掩码映射时要用。
理解这个结构很重要，因为后面做格式转换、统计覆盖面积、生成训练掩码，全都是围绕这份JSON展开的。团队新人在标注时偶尔会把一组点画两遍，造成重复轮廓点，训练时fillPoly会产生一个锯齿状掩码，肉眼又不容易发现。所以在后面的自动化脚本里，我加了一道顶点数量校验和去重逻辑，宁可多花一点处理时间，也不让脏数据进训练管道。
3.2 JSON到掩码的转换脚本
把LabelMe的JSON转成训练用的掩码，是标准模型训练流程的第一步。这里分享一个可以直接修改使用的Python脚本：
import json import numpy as np import cv2 def labelme_to_mask(json_path, height, width, label2idx): with open(json_path, "r", encoding="utf-8") as f: data = json.load(f) mask = np.zeros((height, width), dtype=np.uint8) for shape in data["shapes"]: if shape["shape_type"] != "polygon": continue label = shape["label"] if label not in label2idx: continue pts = np.array(shape["points"], dtype=np.int32) pts = np.unique(pts, axis=0) if len(pts) < 3: continue cv2.fillPoly(mask, [pts], label2idx[label]) return mask label2idx = { "immature": 1, "semi_mature": 2, "mature": 3, } mask = labelme_to_mask("IMG_1023.json", 1080, 1920, label2idx) np.save("IMG_1023_mask.npy", mask)fillPoly走的是多边形填充逻辑，会把多边形内部所有像素都改成对应的类别索引值。注意传入的points必须是二维数组，形状是(N, 2)。这里有个容易踩的坑：LabelMe导出的坐标是浮点数，直接传给fillPoly在某些版本环境下会报类型错误，所以代码里加了dtype=np.int32的转换。另外，cv2.fillPoly对特别细长或者自交的多边形偶尔会出现填充不完整，遇到这种情况，先回原始标注确认是不是控制点顺序有误。
如果你用的分割框架是Mask R-CNN，那通常需要转成COCO格式。转换思路是生成一个包含images、annotations、categories三块内容的大JSON。每个annotation要包含image_id、category_id、bbox和segmentation坐标，其中segmentation多边形坐标要压平成一维列表。写一个一百多行的遍历函数，把shapes里的坐标和类别重新组织成COCO规范结构，这个转换就完成了。转换脚本建议单独保存，后续如果增加图像或修改类别，重新跑一遍并不会花多少时间。
3.3 标注质量自动检查脚本
除了格式转换，强烈建议做一轮自动质量检查，在训练开始前把低级问题全部扫掉。我们当时写的检查脚本主要覆盖：多边形顶点数是否小于3、坐标是否超出图像宽高范围、同一张图内是否存在完全重合的多边形、label是否都在预定义类别列表里。检查结果会输出成一个报表，标注员拿着报表逐张去修，比肉眼翻图高效太多。
这里要特别提醒一个LabelMe的老问题：图像在标注前后如果被旋转或者翻转，JSON里的坐标不会跟着变。你以前用看图软件顺手旋转了方向，但后面训练用的还是原图，掩码就会错位。最稳妥的办法是标注完成之后不轻易旋转原图，必须旋转时重新导出标注。我们在这个问题上踩过大坑，排查了很久才发现是源图在批量压缩环节被旋转了方向，最后重新对齐图像和坐标才解决。
4. 基于数据集的分割模型训练实录
4.1 数据划分与增强策略
数据集到手，第一件事不是直接扔给模型，而是做合理的划分。我们采用果实级去重后的图像级划分，训练集占75%，验证集占10%，测试集占15%。划分时记录每张图像对应的采集时间和果园区域，避免同一天同一棵树附近的图像全部集中在某一个子集里。否则测试结果会虚高，部署到新果园时立刻现原形。
数据增强策略需要仔细设计，因为颜色是成熟度的核心特征，增强不能乱来。常规的随机裁剪、水平翻转、小角度旋转都用上了，这些操作不会改变果皮颜色信息。颜色增强使用了HSV空间的轻微扰动，重点是把饱和度S和亮度V的控制范围调小。原因很简单，成熟度判断非常依赖色彩的细微差异，S和V扰动过大，会把青果颜色硬生生"晒成"黄果，等于教模型学错误的知识。
与此同时，不建议使用随机擦除或者Cutout这类遮挡式增强。分割任务中果实重叠本身已经是不小的难度来源，再随机遮挡，模型会对被遮挡果实区域产生错误的学习信号，最后推理出的掩码容易出现空洞。如果你一定要试，建议做一次消融实验，在测试集上对比IoU，眼见为实。我们团队实测的结果是，遮挡类增强带来的收益微乎其微，反而让成熟类别的召回率掉了1到2个点。
4.2 模型选型与训练参数配置
模型选型上，我优先考虑了U-Net系列和DeepLabV3+两条路线。U-Net结构简单、参数少，在中小规模数据集上表现稳定，训练时间友好，适合快速验证；DeepLabV3+的ASPP模块在感知多尺度信息上更强，适合果实大小差异明显的真实果园场景。最终采用的是DeepLabV3+搭配轻量骨干网络，在精度和推理速度之间取了一个平衡。如果做采摘机器人，还要考虑嵌入式平台部署，输入图像分辨率控制在512到768之间比较合适，太高会拖慢推理帧率。
训练参数的经验值整理如下：
| 参数 | 设置值 | 说明 |
|---|---|---|
| 输入尺寸 | 512x512 | 兼顾细节和显存占用 |
| 批大小 | 8 | 单卡24G显存环境 |
| 优化器 | AdamW | 初始学习率4e-4 |
| 学习率策略 | 余弦退火 | 共训练80个epoch |
| 损失函数 | DiceLoss + 0.5倍CE | 缓解类别不均衡 |
| 骨干网络 | ResNet50 | 与输入分辨率匹配 |
| 数据增强 | 翻转加旋转加HSV微调 | 避免颜色失真 |
| 评估频率 | 每2个epoch | 关注验证集mIoU |
类别不均衡是这个数据集绕不开的问题。真实果园里未成熟果和成熟果比例往往不均衡，半成熟果数量相对偏少。单纯用交叉熵损失，模型很容易为了整体准确率牺牲少数类。Dice损失加交叉熵的组合，在两类之间起到了平衡作用，Dice损失天然对前景和背景比例敏感，能同时拉一把少数类。训练后的合理基线大概是这样：成熟类IoU在0.86左右，半成熟类IoU在0.78左右，未成熟类IoU在0.88左右，整体mIoU能稳定在0.84以上。如果你的复现效果达不到这个水平，优先检查标注质量和数据划分方式，模型结构反而不是首要怀疑对象。
4.3 采摘场景下的推理与粘连处理
训练完模型只是第一步，真实采摘应用里还有一个容易被忽略的问题：相邻果实的粘连分割。分割模型输出的是一个个独立的连通域，如果两个果实贴合太紧甚至互相遮挡，输出的掩码就可能熔成一个连通域，机械臂根本不知道抓哪一个。我们的处理方式是在推理阶段加一道后处理，对掩码做连通域分析，面积过大的连通域再结合果实的径向对称性做二次切分。这个后处理在测试集上能把粘连案例的正确率提升大概5个百分点，对实际抓取帮助非常大。
还有一种经验是置信度阈值设计。成熟度的边界不是一条硬线，尤其是半成熟和成熟之间的过渡非常连续。建议模型输出时不要只取最大值类别，而是保留每个类别的置信度分数。采摘决策环节，如果mature类置信度低于0.7，就让机械臂跳过这颗果实，宁可放弃一个可摘果，也不要冒险摘半熟果。这个策略在真实果园里验证过，误摘率可以压得很低，实际投入产出比很不错。
5. 实战中的常见问题与排查技巧
5.1 标注不一致怎么处理
标注团队协作时间长了，同一个果实被不同标注员画出差异很大的多边形，是肯定会遇到的问题。有的标得圆润，有的标得方方正正，还有的把枝叶遮挡区域直接扩进了果实掩码。要解决这个问题，光靠口头强调不够，需要建立一套多轮评审机制。第一轮做软件层的自动校验，检查多边形顶点数、面积大小、坐标越界这些硬指标；第二轮人工抽查，初期抽检比例30%，等到一致率稳定后降到10%。
如果发现某个类别错分率特别高，也不要急着全数据集返工。先把错分样本按原因归类，比如逆光导致颜色偏暗、果皮返青导致看起来像未熟等等，再针对性地给标注团队补一次培训，把典型错误样例放进评审手册。我们统计过，三轮修正之后，类别错分率从最初的8%降到了2%左右。这个数字直接反映在模型指标上，半成熟类的召回率提升了将近4个百分点。
5.2 颜色边界模糊导致误判
黄绿夹杂的过渡果实，是数据集里最难处理的样本，也是模型最容易漂移的地方。训练前期发现验证集上半成熟类召回率偏低，逐个翻错误样本才发现，模型把很多边缘发黄的青果判成了半熟。原因是阳光直射下，青果表面局部会出现黄白色晒斑，从像素上看确实和半熟果的黄色非常接近。如果模型对这些局部色斑过于敏感，后果就是采摘机器人总是优先去摘青色果子。
处理办法是为这类难例专门补了一批"青果有日灼斑"的图像，并在标注规范里补充了一条：只要果面整体绿色面积超过80%，即使有晒斑也归为未成熟。模型在训练中学会了对局部色斑的容错，半熟类的误判率明显下降。这个案例暴露的深层问题，是类别规则的边界定义要足够细。边界定义越清晰，模型的决策边界才越干净。
5.3 图像重复与时间序列污染
果园巡检常常会在一段时间内对同一棵树反复拍照，时间跨度短的图像之间果实位置几乎不变，时间跨度长的图像之间果实可能已经成熟了。如果把同一颗果实的两个不同时段图像，分别放进训练集和测试集，测试结果就带上了"时间穿越"信息，指标看起来很漂亮，部署一测就全线崩溃。
排查方法就是前面提到的果实级去重。实际操作中，我们给每颗被采样的果实做了粗略的区域定位和枝条编号，拍摄时记录树号和枝号，后期划分数据子集时严格按这个信息来。如果项目前期没做记录，可以用图像检索或者特征匹配，把相似度超过阈值的图像归为一组，人工确认后只保留一组放进同一个集合。去重阶段花掉的时间，会让后续所有训练评估结果的可信度显著提升，这笔投入非常值得。
6. 项目经验与后续扩展思路
6.1 这批数据最合适的几种用法
经过多轮训练验证，我对3000多张级别分割数据集的定位有了一条清晰的经验：它最适合用来做技术选型和算法验证。比如你想对比不同分割模型在细长边界保持上的能力，或者想验证哪种损失函数对颜色渐变类目标更友好，用它都能得出相对可信的结论。它也可以作为预训练数据，先让模型学会识别柑橘果实的边界结构，再用少量业务现场数据微调，迁移效果明显好于从通用图像分类权重冷启动。
对已经有一定私有数据的团队，我建议在此基础上叠加自己的采集场景。不同果园的品种、光照、树形差异很大，任何公开数据集都没办法覆盖所有实际环境。把这份数据当作一个稳定的评测基准，每个版本迭代时先在这个基准上跑通，再放到自有数据上验证，能少走很多弯路。测试集上的阈值调整和模型对比，都必须基于同一个固定基准，才有横纵向比较的意义。
6.2 从成熟度分割到更完整的农业应用
最后分享一个我们已经开始尝试的扩展。成熟度分割的掩码能做的事情，比单纯的采摘识别要多得多。统计每个成熟度档位的可见果面积占比，结合树冠体积模型，就能估算整园的成熟可摘产量；按时序对比同一棵树的掩码变化速率，可以预测未来3到5天的集中成熟窗口；再叠加天气数据，还能为采摘调度提供更可靠的依据。这些应用本质上都在复用同一套分割输出的几何和类别信息，数据集的边际价值会被持续放大。
如果继续往前走，下一个值得尝试的方向是联合检测成熟度和果实大小。分割掩码已经携带了直径和面积的几何信息，用掩码的长轴和短轴估算果径，可以直接指导分级分拣。这是在农业场景里投入产出比最高的技术演进之一，不仅服务采摘端，也能服务采后处理端。希望这套数据集能成为你项目里的一个稳定起点，让你少走一些我们当年走过的弯路，把精力真正花在解决实际问题上面。
