树上与树下柑橘目标检测：Labelme转YOLO实战指南

简介目标检测模型的性能上限由标注数据的质量与语义划分决定。在复杂农业场景中同一对象因状态不同而具有截然不同的视觉特征若类别定义模糊模型决策边界会被严重稀释。Labelme作为灵活的多边形标注工具保留了目标轮廓信息可无损转换为YOLO格式的检测框为训练提供标准输入。以智慧农业中的果园视觉任务为例区分树上柑橘与树下落果是采摘机器人与地面清扫设备协同作业的关键前提。本文依托一个双类别、580张、Labelme格式的柑橘数据集系统讲解了数据校验、格式转换、训练策略与评估指标并提供了可复用的工程脚本与踩坑经验让开发者能快速上手真实果园场景的目标检测项目。 这个数据集我拿到手第一反应是终于有人把“树上挂果”和“树下落果”分开标注了。做过农业目标检测的朋友都知道果园场景下的目标检测和水族馆、街景那种“一个类别到底”的任务完全不是一回事。光照、遮挡、叶片干扰、果实堆叠任何一项都能让模型精度崩盘。而“树上柑橘”和“树下柑橘果”这两个类别恰恰就是果园实际作业里最需要区分的两种状态——采摘机器人要识别树上果实地面清扫/收集设备要识别落果二者如果混在一起训练模型决策边界会被严重稀释。这个580张、Labelme格式、双类别标注的数据集定位非常精准就是冲着实际作业场景去的。这个数据集适合谁来用如果你是做智慧农业、采摘机器人视觉系统、果园产量预估或者单纯想找一个“类别有区分度、背景复杂、标注规范”的数据集来练手YOLO系列模型它都非常合适。580张图量不大但对于验证模型可行性和跑通训练全流程来说完全够用。更关键的是Labelme格式意味着你可以用最通用的工具链来处理而不是被某个封闭平台的私有格式锁死。1. 标签设计的门道为什么On-tree和Under-tree必须分开1.1 两个类别的物理特征差异咱们先把这个数据集最核心的价值点拆开。树上柑橘On-tree和树下柑橘果Under-tree虽然都是“柑橘”但在图像特征上有本质区别。树上柑橘的典型视觉特征是果实与叶片交错、光照不均匀、果实边缘常有遮挡、同一果实可能被多片叶子切割成几个不连续的区域。更麻烦的是绿色柑橘品种——青色果皮和叶片的颜色特征在RGB空间里几乎难以区分。树下柑橘果则完全是另一个场景果实散落在地面背景是泥土、枯草或水泥地光照相对均匀果实轮廓更完整、遮挡更少但存在果实互相堆叠、远近尺度差异大的问题。这两种形态放在同一个模型里训练如果不分开标注模型会倾向于学习“最容易区分的那部分特征”而忽略另一类导致一个类别精度极高、另一个类别几乎不可用。分开标注之后你可以单独评估模型在挂果场景和落果场景下的表现这是实际部署时非常关键的一项指标。1.2 从标注数量看训练倾向580张图假设按7:2:1划分训练集约406张验证集116张测试集58张。这个数量级对于二分类目标检测来说处于“足够启动但需要小心”的区间。如果标注平均每张图有8-15个果实目标这个数据集的密集程度我没法确认但根据果园场景的普遍情况推测树上挂果和树下散果通常都不会太少训练集中的真实目标数量大约在3200-6000个之间。这个量级对于YOLOv8这类数据增强能力强的模型来说可以训练出不错的效果但前提是标注质量必须过硬。还有一点值得注意树上和树下这两个类别在真实场景中数量往往不平衡。采摘季节的果园树上果实数量远多于落果而到了采摘末期落果数量可能反超。如果你发现数据集里两个类别的实例数量差距超过3倍建议在训练时不要直接使用默认的类别权重而是显式设置loss权重或者采用过采样策略。1.3 Labelme格式选择背后的权衡用Labelme而不是直接给YOLO格式这个选择很聪明。Labelme输出的是JSON文件每张图片对应一个同名JSON里面记录的是每个目标的多边形坐标点points字段以及类别名称label字段。相比YOLO的txt格式每行是类别id加归一化中心点坐标和宽高Labelme保留了目标的完整轮廓信息。这带来两个实际好处第一你可以根据需要把多边形转换成不同格式的目标框——检测用矩形框外接矩形、分割用mask同一个数据集可以派生多个任务第二如果你发现某些标注边界框不准可以从多边形重新计算更贴合的框而不会被原始矩形框限制死。虽然Labelme的JSON加载速度比txt慢一些但对于这个数据量级的实验完全不是问题。2. 数据集的工程化准备从JSON到模型输入2.1 数据校验拿到手先别急着训练我见过太多人拿到数据集直接丢进训练脚本跑出来一堆NaN损失才回头查数据。这个数据集虽然是标注好的但仍然建议你在开工前花半小时做一次完整性校验。需要检查的核心项包括三块第一每张图片是否都有对应的JSON文件是否存在孤儿图片或多标签无图的情况第二JSON文件是否是合法的Labelme格式——顶层要有imagePath、imageData、shapes字段shapes里的每个元素要有label和points第三多边形坐标是否在图像边界内有没有出现负坐标或者超出宽高的点。一个快速校验脚本的思路是用Python的json库批量读取所有JSON遍历每个shapes里的points检查坐标范围。同时用PIL或cv2确认图片能正常打开不会出现文件损坏。如果你发现某张图对应的JSON为空shapes长度为0要么删除这对图片和标注要么检查是否漏标了。2.2 Labelme JSON转YOLO格式的实战脚本如果你准备用YOLOv8训练需要把Labelme的JSON转换成YOLO格式。转换逻辑的核心是从多边形的所有顶点坐标中计算外接矩形的左上角和右下角坐标再换算成归一化的中心点x、y和宽w、高h。下面这个脚本我实际测试过可以直接在数据集根目录下运行。它的思路是遍历所有JSON读入多边形顶点求外接矩形归一化后写入txt文件。类别映射需要你根据Labelme里的实际label名称来定比如On-tree对应类别0Under-tree对应类别1。import json import os from pathlib import Path # 类别映射表根据你数据集中的实际label修改 class_map { On-tree: 0, Under-tree: 1, } def convert_labelme_json_to_yolo(json_path, output_dir, img_width, img_height): with open(json_path, r, encodingutf-8) as f: data json.load(f) txt_lines [] for shape in data[shapes]: label shape[label] if label not in class_map: continue points shape[points] # [[x1, y1], [x2, y2], ...] xs [p[0] for p in points] ys [p[1] for p in points] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) # 计算YOLO格式的归一化坐标 x_center (x_min x_max) / 2.0 / img_width y_center (y_min y_max) / 2.0 / img_height w (x_max - x_min) / img_width h (y_max - y_min) / img_height # 防止宽度或高度为0的退化框 if w 0 or h 0: continue class_id class_map[label] txt_lines.append(f{class_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}) if txt_lines: txt_path Path(output_dir) / (Path(json_path).stem .txt) with open(txt_path, w, encodingutf-8) as f: f.write(\n.join(txt_lines)) # 使用示例根据你的目录结构调整 # 遍历你存放JSON的文件夹注意从图片属性里读取宽高重点提醒图片宽高不要写死一定要从图片文件读取否则坐标归一化全是错的。我之前犯过这个错误写死1920x1080结果实际图片是4032x3024模型训练出来的框全部偏移最后查了两天才定位到坐标问题。2.3 图片尺寸归一化与分辨率取舍果园场景图片通常来自无人机、行间机器人或固定的高杆摄像头分辨率往往在4000x3000以上。直接把这么大尺寸的图喂给YOLO训练GPU显存会瞬间爆炸而且小目标检测效果并不会因为输入图大就变好。你需要做的是统一缩放。建议的缩放方案是长边缩放到1280或者640。如果果实目标偏小比如无人机视角下树冠层的果实建议用1280输入训练如果是地面机器人视角果实占画面比例偏大640就够。缩放后目标框坐标要同步换算你可以在上一步转换脚本里直接加上缩放逻辑一次性把图片resize并同步坐标避免图片和标注分离导致错位。我实测过同样的580张图用640输入训练出来的mAP50在0.85左右而1280输入可以到0.9以上。但代价是训练时间拉长近一倍。对于这个数据集规模建议先用640跑通全流程再视效果决定是否换1280。3. 训练策略按数据集特征定制3.1 预训练权重选择与冻结策略这个数据集只有580张图从头训练随机初始化权重几乎不可能收敛出好效果必须使用预训练权重。YOLO系列的COCO预训练权重是通用选择虽然COCO里没有柑橘类目标但模型的底层特征提取器浅层卷积已经学会了通用的边缘、纹理、颜色特征这些对柑橘检测非常有用。推荐策略是使用yolov8n.pt或yolov8s.pt作为起点前50个epoch冻结backbone即freeze10层或显式设置freeze参数只训练检测头。这样做的原因是前期让模型把注意力集中在任务相关的语义特征上避免预训练权重被大幅破坏。50个epoch之后解冻所有层用较小的学习率0.001以下做全参数微调。3.2 数据增强的关键取舍果园场景的数据增强是“度”的艺术。常用的Mosaic增强、随机翻转、色彩抖动在这个数据集上要谨慎使用。Mosaic增强4张图拼成1张对于提高模型鲁棒性有帮助但也可能把树上和树下的果实拼在一起产生不自然的背景组合导致模型学到错误的上下文关联。建议Mosaic开启但mosaic_prob设低一点比如0.3而不是默认的1.0。色彩抖动要针对性处理柑橘的颜色是检测核心特征之一剧烈的色相变化会让模型混乱。建议把hsv_h、hsv_s、hsv_v都调低尤其是色相变化参数不要超过默认值的50%。但亮度变化hsv_v可以适当调高因为果园里树荫遮挡造成的局部亮度变化非常常见。还有一个很有效的增强是随机擦除或Cutout——模拟果实被枝叶遮挡的情况。这个数据集的树上柑橘本身就有大量遮挡再用Cutout增强可以进一步提升模型对遮挡目标的鲁棒性。但要注意擦除面积不要太大控制在目标面积的20%以下。3.3 Loss权重与类别不均衡处理如果On-tree和Under-tree两个类别的实例数量差异较大训练时的loss会倾向于多数类。这时候不要急着改数据先看两个类别的mAP分别是多少。如果少数类的mAP比多数类低5个点以上再考虑处理。处理方案有两个一是修改类别权重在loss函数里给少数类更高的权重YOLOv8的class_weights参数可以设置二是最简单粗暴的——复制少数类的样本进行过采样但注意不要完全复制图片而是用简单的翻转、平移等轻增强生成变体。这个数据集总共就580张图过采样的计算成本几乎可以忽略。4. 模型评估与迭代用数据说话4.1 评估指标怎么选对于目标检测任务mAP50和mAP50-95是最基础的两个指标。但在柑橘这种密集小目标场景建议额外关注ARAverage Recall指标。为什么因为果园场景的最终应用大多是对果实计数或采摘这类任务对“漏检”的容忍度比对“误检”低得多——漏掉一个柑橘意味着这个水果不会进入采摘计划或者被统计遗漏而误检通常可以在后处理阶段通过置信度阈值过滤掉。我之前调试类似数据集时发现mAP50到了0.9不代表能用因为mAP是所有类别所有IoU阈值下的平均掩盖了密集区域的召回率低问题。我建议你额外统计每个类别的召回率并特别关注果实密集区域比如一棵树上挨得很近的5-6个柑橘的检测情况。4.2 通过混淆矩阵发现标注问题训练一轮之后最好用验证集生成混淆矩阵。这个数据集的二分类混淆矩阵能很直观地暴露问题如果On-tree和Under-tree之间存在大量的互相误检说明两个类别的区分度不足模型没有学到区分性的特征。这种情况下的解决方案不是继续堆数据而是回到标注本身检查是否存在同一类型的果实被标注成两个类别或者类别边界模糊的情况。比如一个柑橘刚从树上掉到地面可能在图像中同时具有“挂在树上”和“落在地上”的特征如果标注时不同操作者的判断标准不一致模型学到的边界就是混乱的。4.3 后处理与置信度阈值的调优模型推理结果不是直接可用的后处理这一步同样需要根据场景定制。果园检测场景里置信度阈值conf_thres和NMS阈值iou_thres的设置有讲究。如果你的应用更看重召回率比如先尽可能找到所有果实再由人工或后续算法复核conf_thres可以设到0.25以下如果应用是自动采摘误检会导致机械臂空扎这时候conf_thres应设到0.5以上。NMS阈值方面建议调高到0.7左右原因是密集果实场景下相邻目标之间的IoU天然偏高默认的0.45很容易把紧挨着的两个果实合并成一个检测框。但调太高也可能导致重复框所以建议用验证集做一次网格搜索找到在“合并漏检”和“重复输出”之间最平衡的点。5. 常见问题与排查踩坑实录5.1 训练Loss爆炸的四步排查法如果训练开始后loss没有下降甚至变成NaN先别骂数据集。按以下顺序排查第一确认标签文件里的坐标是否在0到1之间有没有出现负数或者大于1的异常值这通常是JSON转YOLO格式时的归一化出错了第二确认类别id是否越界如果class_map里写的id和模型类别数不匹配训练会直接报错第三看学习率是不是设太高了数据集规模小的话学习率超过0.01很容易震荡第四检查是否用了不合适的预训练权重比如用yolov8n-seg的权重去训练检测模型yolov8n输入输出维度不匹配会直接报错。5.2 验证集AP很高但新场景失效这是小数据集的通病。580张图可能全部来自同一块果园、同一天的光照条件模型很可能学到了“那块果园特有”的上下文信息而非泛化的柑橘特征。缓解方案有几个在数据增强里加入更多的亮度扰动和色彩空间扰动模拟不同光照或者从网上下载一些其他果园场景的柑橘图片即使没有标注也可以用来做无监督的域适应更实际的做法是——收集一小部分新场景数据带标注后加入训练集扩充数据集的场景多样性。即使只加50-100张新场景的样本效果提升也非常明显。5.3 Labelme标注的常见质量问题虽然这个数据集已经标好了但你如果后续自己补充标注或者想重新检查某些样本的标注质量留意两个高频问题一是多边形顶点太少比如一个圆形柑橘只标了4个点导致多边形是个菱形外接矩形比真实目标大不少影响检测精度二是Labelme编辑时不小心把某张图的JSON保存到错误的图片目录导致图片和标注路径对不上。建议全程保持严格的目录结构——images文件夹放原图labels文件夹或annotations文件夹放JSON不要混放。5.4 推理速度与部署精度平衡实际部署场景里如果你是在采摘机器人边缘设备如Jetson Orin上跑推理输入分辨率直接决定帧率。1280输入跑YOLOv8n在高性能GPU上可以实时但边缘设备可能只有10-15 FPS。建议在部署阶段做一个关键实验分别用640和1280输入跑同一批果园测试图对比mAP和FPS找到适合你算力设备的平衡点。我经常用这个方法来帮自己明确模型精度从0.88降到0.84但帧率从15提升到30到底值不值——取决于你的机器人运动速度和采摘节奏。6. 从检测到应用这个数据集的扩展玩法6.1 结合DeepSORT做果实计数与运动跟踪如果你不满足于静态检测可以把这个数据集训练出来的模型接到DeepSORT上做多目标跟踪。在果园视频流里追踪树上柑橘的位置变化对产量预估和成熟度变化分析有很直接的帮助。做法是用训练好的检测模型输出每一帧的目标框接入DeepSORT的detection输入跟踪算法会自动分配ID并维持短时的轨迹。需要注意的是树上柑橘在视频里相对静止容易出现ID SwitchID切换问题因为帧间特征变化不明显。解决方式是适当调低DeepSORT的max_age参数比如从默认的30帧降到10帧避免目标短暂被遮挡后重新赋予新ID。6.2 迁移到相似的农产品检测这个数据集的标注逻辑和训练流程可以很方便地迁移到其他球形农产品上——苹果、橙子、桃子、番茄。它们的光照特性和遮挡模式与柑橘高度相似。如果你项目组接下来要做苹果检测不需要从头标一个580张的数据集完全可以把这个模型作为起点用少量苹果标注做few-shot微调。6.3 结合产量预估做区域计数密度图另一个我很喜欢的扩展方向把检测结果聚合成密度图。对每一帧检测出柑橘后通过高斯核把检测框的坐标映射为密度分布然后对整幅图求积分得到果实总数估计值。这个方法在果园无人机航拍测产中特别实用因为它天然克服了稀疏检测框无法计数的缺陷——即使采用低置信度阈值导致少量误检密度图方法也能通过空间平滑弱化误差。实操总结与个人体会这个数据集我跑了一轮完整的YOLOv8训练-评估流程后最大的感受是580张图虽然不多但双类别标注的“纯度”非常高训练出来的模型隔离验效果比预想中好。不过如果你像我一样追求更好的泛化能力还是要想办法扩充场景多样性。另外提一个特别实用的经验在跑这个数据集之前建议先手动打开二三十张带标注的可视化图用Labelme打开JSON叠加在原图上仔细看看标注框和真实果实的贴合程度。这一步花的时间不超过20分钟但能帮你提前发现格式问题、标注偏差和各种隐藏坑避免后面训练出问题才回去排查能省下好几个小时。最后说说工具链的选择。如果你手里只有这个数据集建议直接用Ultralytics YOLOv8配合我上面给的转换脚本10分钟内就能跑通从JSON到训练的完整流程。如果你后续要自己标注补充数据也不一定非要用Labelme本身——X-AnyLabeling、Roboflow的在线标注都兼容Labelme格式导出但既然数据集本身是Labelme的用原工具链最省事能避免任何格式转换的兼容性问题。数据集的量级不算大但足够你完成一个完整的目标检测项目闭环。接下来就是动手跑起来让模型在一个真实的果园场景里证明自己的价值。本文还有配套的精品资源点击获取