苹果果梗枝条分割数据集制作全流程：labelme标注与格式转换实战

做农业视觉项目的人十有八九都卡在数据准备这一关。果园环境不比实验室光照乱、遮挡多、枝叶交错光是搞清楚要标什么、怎么标就能耗掉大半个月。苹果果梗和枝条的识别分割是疏花疏果、仿生采摘、测产估产这些下游任务的前置基础但公开数据集少得可怜最后基本都得自己动手做。我最近刚整理完一套712张、3个类别的苹果果梗枝条分割数据集用的labelme格式从拍照采集到标注规范再到格式转换踩了一圈坑把过程完整记录下来给有同样需求的朋友做个参考。1. 项目整体设计与思路拆解1.1 为什么选择labelme格式而不是直接用COCO或YOLO格式先说结论labelme格式是所有后续转换的起点这个选择在前期可能看不出优势后期能省掉大量返工成本。labelme导出的JSON文件本质上是把每个目标的轮廓坐标点完整保存下来每个标注对象包含points数组和shape_type字段shape_type可以是polygon、rectangle、circle等。这种设计最大的好处是信息无损——你标注的每个多边形顶点都原样保留后续要转成COCO的掩码、YOLO的归一化坐标、或者Cityscapes的polygon格式都有完整的几何数据可用。我自己对比过其他标注工具的实际情况。LabelImg主要输出Pascal VOC格式的XML对目标检测友好但做不了多边形分割标注CVAT虽然功能全但部署成本高团队协作场景才值得上单人做数据集用不上这么重的东西Labelme轻量、开源、单机可用、安装简单处理几百张图的规模绰绰有余。如果你的项目需要做像素级分割labelme几乎是现阶段最合理的选择。这个数据集的3个类别——苹果、果梗、枝条——是我在标注第一轮之后重新调整过的。最初我设想过把“花萼”和“果台副梢”也作为独立类别实际操作后发现这两个部位在图像中占比太小标注一致性很难保证不同的人标同一张图边界偏差能超过10个像素这样的标签喂给模型噪声比信息还多。后来果断砍掉只保留宏观特征清晰、边界相对明确的3类标注一致性问题立刻缓解。1.2 712张图的规模和样本分配逻辑712这个数字不是我随手定的是按训练需求倒推出来。一个分割模型可用的参数量至少在百万级如果类别少、背景相对固定几百张图可以出不错的效果但苹果园场景的复杂性在于光照变化剧烈——晴天直射、阴天漫射、逆光、树荫斑驳加上不同生长时期的形态差异样本如果太少模型的泛化能力会很差。我在采集时做了明确的分层设计按时期分幼果期花后30-45天占比约30%膨大期占比约40%成熟期占比约30%。不同时期果梗和枝条的颜色、粗细、弯曲度差异很大只标一个时期会让模型在另一个时期直接失效。按光照条件分顺光、侧光、逆光、遮阴各占适当比例。逆光环境下果梗和枝条经常和天空或高光背景融为一体这是模型最容易犯错的地方。按距离和角度分近距离特写单个果实占据画面的30%以上占40%中距离一簇果实和枝条占40%远距离整枝占20%。采集用手机和微单各拍了一部分分辨率统一缩放到1920x1080再标注。原图直接标不是不行但会让JSON文件膨胀而且标注卡顿缩放后平滑度也够用模型输入尺寸一般在512到640之间交大图给模型反而是浪费。1.3 三个类别的定义边界与标注难点这是整个项目里最需要统一认知的部分。三个人同时标注时如果边界定义不清晰产出的标签质量会非常不稳定。我在项目启动前写了一份标注规范核心定义如下苹果apple果实主体轮廓包括果皮表面可见的全部区域。被遮挡的果实用rectangle标出可见部分的最大范围不对这里我要纠正自己之前看的资料——分割任务里被遮挡的部分只能标可见区域不能凭想象补齐遮挡轮廓。多边形的顶点应该紧贴果实的实际可见边缘不包含果梗连接处的凹陷区。果梗stem从果实顶端凹陷处到与枝条连接点的全部可见部分。这个定义容易和枝条产生边界争议我的处理原则是以“是否有明显增粗或分叉”作为分界。果梗通常细、直、颜色偏黄绿枝条通常粗、有节、颜色更深。如果一段结构无法从视觉上明确归属就归为“枝条”宁粗勿细——粗标签的误差比细标签对模型的误导小。枝条branch当年生新梢和多年生老枝的可见部分。这里有个实际操作中的经验不要沿着枝条边缘一点一点描那样工作量会大到崩溃。对于较长的枝条每隔一段距离取点让线段近似拟合曲线虽然多边形和真实边缘会有一点偏差但模型学习的是整体结构特征几个像素的误差影响有限。标完之后我还做了一轮交叉检查——让标注者两两交换标注文件检查对方是否误把带有花萼的果实边缘也算进果梗是否漏标了被叶片遮挡但可见的枝条段。这一轮检查大概多花了一天时间但显著提升了数据集的整体质量。2. labelme安装、配置与标注实操要点2.1 labelme安装过程与版本坑labelme目前分Python 3.x版本和Qt 5版本安装方式有细微差别。我在Ubuntu 20.04和Windows 10上各装了一次把能踩的坑基本都趟了一遍。Ubuntu下的推荐安装方式conda create -n labelme python3.8 conda activate labelme pip install labelmeWindows下的推荐安装方式conda create -n labelme python3.9 conda activate labelme pip install labelme安装完成后在终端输入labelme即可启动。如果界面异常或菜单显示不清多半是Qt插件和显示环境的问题可以尝试安装PyQt5的完整包并关闭系统的HiDPI缩放设置。有一个版本问题是很多人容易忽略的labelme 5.x版本对高版本Python的兼容性更好但导出的JSON文件里默认把图像数据也做了Base64编码存进去这会让文件体积膨胀3到5倍。如果你打算用脚本批量读取和处理可以在保存时注意勾选或不勾选相关选项——不同版本的设置位置略有不同我自己的做法是统一用labelme 5.1.1版本这样后续格式转换脚本只用维护一套解析逻辑。2.2 标注界面操作详解与效率技巧labelme的交互逻辑不复杂但效率高低之间的差别非常大。核心快捷键必须记忆CtrlN切换下一张图片CtrlP切换上一张图片CtrlJ编辑多边形顶点CtrlD复制当前标签CtrlZ撤销CtrlS保存我建议在实际标注时把常用的类别标签放到工具栏快捷栏里。每个类别的颜色也最好提前固定——苹果红色、果梗绿色、枝条蓝色颜色不重样这样在密集区域标注时光看颜色就能快速判断当前图层区域属于哪个类别视觉压力会小很多。做多个类别的分割标注时有个操作习惯影响很大每个类别完整标完一个图再切换下一个类别而不是一张图上来就苹果标一笔、果梗标一笔。原因是连续标注同一类别时视觉注意力会保持连贯标注速度可以提升30%以上而且不容易出现类别之间互相“污染”的边界偏移。标注的通用流程我建议固定为打开图片先整体浏览识别所有需要标注的目标先把画面中所有苹果标完最直观也最不会漏再标所有果梗此时可以借助苹果的凹陷位置定位最后标枝条从主枝到侧枝按拓扑顺序标注保存JSON切换下一张。我测试过效率按这个流程走一张中等复杂程度的图片从打开到保存大约需要3到5分钟遇到密集簇生的果实图可能需要7到8分钟。712张图全部标完按每天有效标注4到5小时计算大约需要10到12个工作日。2.3 多边形标注的质量控制与细节决策分割标注不像检测框多边形的顶点数、顶点位置直接影响标签质量和后续训练的mask精度。关于顶点数量我有个经验法则简单轮廓8到15个点复杂轮廓15到30个点特殊果实有畸形的不超过40个点。顶点太少轮廓会和真实边缘严重偏离顶点太多JSON文件会变得很大而且标注效率和训练效率都下降但精度提升已经微乎其微。在果实相互遮挡的密集区域我的做法是把每个果实的可见弧段完整标出但相邻果实的边界如果有重叠以先标注的那个果实为准后标的果实紧贴它但不要交叉穿透。如果两个多边形存在交叉后续转成掩码时会产生非预期的“镂空”区域模型学到的东西就是错的。另一个细节是果梗与果实连接处的处理。这个位置是分割误差最大的区域实际标的时候果梗多边形应该从果实凹陷处开始而不是从果实内部开始。如果果梗起点伸进果实轮廓内部两者边界算起来会有矛盾损失函数都不知道该让哪个类别赢。我在标注规范里明确写了果梗起点的所有顶点必须在果实轮廓外部或恰好与之相切不允许进入果实内部区域。枝条部分有一个容易犯的低级错误把背景中的地面、支撑杆、滴灌管误标成枝条。除非画面里的枝条特征极其清晰否则背景中的线性物体不要标。模型学的不是“线状即枝条”而是“枝条的颜色纹理和形态组合”错标会直接引入噪声。3. 从labelme到分割数据集格式转换与数据划分实战3.1 labelme JSON结构解析与批量转换脚本标注完成之后所有数据都躺在labelme生成的JSON文件里。先看看单个JSON的核心结构是什么样{ version: 5.1.1, flags: {}, shapes: [ { label: apple, points: [[x1, y1], [x2, y2], ...], group_id: null, shape_type: polygon, flags: {} } ], imagePath: IMG_0001.jpg, imageData: ...base64编码的图片数据..., imageHeight: 1080, imageWidth: 1920 }shapes数组就是所有标注对象的集合每个对象有一个label字段对应类别points是多边形顶点坐标。imageData是Base64编码的原始图像如果你用脚本去OCR、切图或者做其他处理可以直接从JSON里解码这张图再用imagePath里的文件名去对应实际文件即可。实际训练时大多数框架不认labelme原生的JSON格式需要转成更标准的格式。这里我做了一个批量转换脚本主要做三件事把JSON转成COCO格式、把JSON转成YOLO分割格式、把JSON转成PNG掩码VOC/语义分割常用。转换脚本用Python实现核心是解析JSON里的几何信息逐类处理import json import os import numpy as np import cv2 from tqdm import tqdm def labelme2mask(json_path, img_width, img_height, category_dict): labelme JSON转单通道掩码 with open(json_path, r, encodingutf-8) as f: data json.load(f) mask np.zeros((img_height, img_width), dtypenp.uint8) for shape in data[shapes]: label shape[label] if label not in category_dict: continue points np.array(shape[points], dtypenp.int32) cv2.fillPoly(mask, [points], category_dict[label]) return mask def labelme2yolo_seg(json_path, img_width, img_height, category_dict): labelme JSON转YOLO分割格式类别id 归一化坐标 with open(json_path, r, encodingutf-8) as f: data json.load(f) lines [] for shape in data[shapes]: label shape[label] if label not in category_dict: continue class_id category_dict[label] points shape[points] normalized [] for x, y in points: nx round(x / img_width, 6) ny round(y / img_height, 6) normalized.append(f{nx:.6f} {ny:.6f}) line f{class_id} .join(normalized) lines.append(line) return lines注意cv2.fillPoly填充时坐标值必须是np.int32类型如果直接传入float类型OpenCV会发出警告而且填充结果经常出错。归一化时保留6位小数通常足够精确再多的位数对模型训练没有实际意义反而让文件变大。3.2 COCO格式转换与类别注册细节如果你要用MMDetection、Detectron2这些框架做目标检测或实例分割需要转成COCO格式。COCO的数据组织方式和labelme差异比较大它把标注信息统一放在一个JSON文件里用images、annotations、categories三个数组组织数据。COCO中每个annotation会有一个segmentation字段可能是多边形坐标数组也可能是RLE编码。从labelme转过来时直接用多边形坐标即可def labelme2coco(json_dir, output_path, category_dict): images [] annotations [] annotation_id 1 image_id 1 for json_file in os.listdir(json_dir): if not json_file.endswith(.json): continue with open(os.path.join(json_dir, json_file), r, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] images.append({ id: image_id, file_name: data[imagePath], width: img_w, height: img_h }) for shape in data[shapes]: label shape[label] if label not in category_dict: continue points shape[points] seg_polygon [coord for point in points for coord in point] # 计算边界框 xs [p[0] for p in points] ys [p[1] for p in points] bbox [min(xs), min(ys), max(xs) - min(xs), max(ys) - min(ys)] area cv2.contourArea(np.array(points, dtypenp.float32)) annotations.append({ id: annotation_id, image_id: image_id, category_id: category_dict[label], segmentation: [seg_polygon], area: area, bbox: bbox, iscrowd: 0 }) annotation_id 1 image_id 1 categories [{id: cid, name: name} for name, cid in category_dict.items()] coco_data {images: images, annotations: annotations, categories: categories} with open(output_path, w, encodingutf-8) as f: json.dump(coco_data, f, indent2)这里有个值得注意的细节COCO格式里segmentation的多边形坐标数组必须是扁平化的一维数组顺序是[x1, y1, x2, y2, x3, y3, ...]不能是嵌套的[[x1, y1], [x2, y2]]形式。我之前在这个地方被卡了很久转出来的数据在验证可视化时全是乱线最后才发现是坐标嵌套层级的问题。还有area字段COCO里要用多边形围成的面积可以通过satos的函数计算也可以用cv2.contourArea两者在凸多边形上结果一致对凹多边形会有细微差别但对训练影响不大。3.3 数据集划分与增强策略数据划分在分割任务里尤其容易出问题。不管是目标检测还是分割一张图片里可能存在多个类别如果划分不当某些类别的样本只会出现在训练集或验证集里模型评估结果会严重失真。我的划分策略是按整图进行划分不做图片内部的随机裁块分配保证同一张图片的所有目标对象只属于一个数据子集。划分比例用接近8:1:1的划分——训练集570张、验证集71张、测试集71张。这里说的验证集和测试集作用不同验证集在训练过程中用来调参和检查过拟合测试集在训练完成后用来做最终性能评估两者不能互相替代。划分时最好做一次类别分布统计子集图片数量苹果标注数果梗标注数枝条标注数平均每图标注数训练集5708126414873.4验证集719879633.4测试集719775583.2三个子集的类别分布要尽可能接近否则验证过程会引入系统性偏差。数据增强方面分割任务和检测任务不一样不能粗暴地做随机裁剪和翻转。比如垂直翻转对果实识别来说可能让模型学到“果梗朝上”这种错误先验。我实际使用下来最安全的增强操作是轻度色彩抖动hue/saturation/value范围控制在0.2以内随机水平翻转概率0.5小角度旋转±15度以内配合掩码同步旋转随机缩放0.8到1.2倍掩码同步缩放旋转和缩放时要确保掩码和图像做相同的变换。用albumentations库实现这个很方便它的Compose可以直接接收图像和掩码参数并同步操作不会出现图掩码错位的问题。3.4 类别不平衡问题与应对方案从上面的分类统计可以看出三类标注数量并不均衡。苹果最多枝条最少这个分布符合实际场景——果实总是比枝条容易拍摄和识别但模型训练时类别不平衡会导致少数类枝条的分割精度明显偏低。我尝试过两种应对方案方案一损失函数加权。在损失函数里给枝条类别分配更高的权重例如CrossEntropyLoss(weighttorch.tensor([1.0, 1.2, 1.5]))根据类别数量反比来设置权重# 假设类别频率为 apple:812, stem:641, branch:487 weights torch.tensor([1.0, 812.0/641.0, 812.0/487.0])方案二欠采样与过采样结合。对于标注数量过少的枝条可以通过复制样本在增强参数的随机性下自动产生新样本来增加参与训练的迭代次数。实际测试下来方案一更稳定。方案二容易让小样本类别反复出现过拟合增强带来的多样性有限。如果你用的是YOLOv8或者MMDetection可以直接在训练配置里设置loss_cls和loss_seg的权重不用改任何代码。4. 数据集验证、常见错误与质量复盘4.1 可视化验证标注问题一“眼”即见数据集做完不代表可以直接扔给模型训练。我在实际项目里发现格式转换脚本即使逻辑完全正确也可能因为labelme标注时某些操作不规范而产生隐蔽问题。最有效的验证手段就是可视化。我写了一个简单的可视化脚本把原图、标注多边形、填充掩码叠加显示逐张肉眼检查def visualize(json_path, img_dir, output_dir, category_dict): with open(json_path, r, encodingutf-8) as f: data json.load(f) img_path os.path.join(img_dir, data[imagePath]) img cv2.imread(img_path) overlay img.copy() for shape in data[shapes]: label shape[label] points np.array(shape[points], dtypenp.int32) color category_colors[label] cv2.polylines(overlay, [points], isClosedTrue, colorcolor, thickness2) cv2.fillPoly(overlay, [points], color) result cv2.addWeighted(img, 0.5, overlay, 0.5, 0) cv2.imwrite(os.path.join(output_dir, os.path.basename(img_path)), result)这个脚本把原图和半透明的彩色掩码叠加输出标注不贴合边界、多边形自相交、类别颜色错误等一眼就能看出来。710多张图全看一遍大概需要一天时间但这一步绝对值得。模型对噪声标签的容忍度有限肉眼检查一小时可能抵后面调模型三小时。4.2 常见错误速查表与修复方案我在这个数据集上踩过的坑整理成表格直接对照排查症状可能原因修复方案掩码填充后出现细小缝隙多边形顶点过密且坐标浮点误差累积顶点数适当降密重采样轮廓点两个类别的掩码重叠区域标注时多边形相互交叉调整顶点确保边缘不相交枝条掩码断裂成多段枝条被叶片遮挡导致可见段分离用同一类别多段标注确保中间间隔有根据训练时类别id对应错乱转换脚本中category_dict顺序不一致统一类别映射表同一个字典文件控制全流程某些图片加载失败图片路径包含中文或特殊字符文件路径统一改为英文数字命名震机后掩码错位旋转强度过大导致插值偏差限制旋转角度在±15度以内或用最近邻插值做掩码4.3 关于标注一致性比质量更重要的事很多初学者以为分割数据集的核心工作是“画多边形”实际上花在统一标准上的时间才是决定数据集质量的胜负手。三个类别看似清楚实际标注时满眼都是模棱两可的情况——果实上的反光区域算不算果实干枯的果梗和枝条连接处怎么划分带果袋的果实要不要标我最后总结的有效做法是写一份带图例的标注规范文档。每个类别配上2到3张典型图片、1张有争议图片、1张错误示范图片标注时对照文档判断而不是凭感觉。每天标注前先标5到10张同一批图片然后做一致性对比。如果不同人对同一目标的轮廓标注IoU低于0.85需要停下来讨论边界定义而不是继续埋头标。每一轮标注完成之后随机抽10%的图片做二次复查。我实际复查中发现的最多问题是“漏标”——不是边界画不准而是某些果实完全被叶子遮住大半标注者直接跳过了。4.4 数据集使用建议与下游任务扩展这套712张3类别的数据集本身就是一个基础性资产做分类、检测、分割都可以直接复用或做少量调整后转移。以我的经验对这组数据具体使用时的建议是做语义分割建议用DeepLabV3、UNet或PSPNet这类经典语义分割网络配合ResNet50或MobileNetV3骨干输入尺寸可以设在512x512用上面说的8:1:1划分训练通常几十个epoch就能有不错的收敛结果。做实例分割Mask R-CNN或者YOLOv8-seg都可以直接吃COCO格式或YOLO格式的数据。YOLOv8-seg的输出格式要求每个目标的归一化多边形顶点用我上面给出的转换脚本可以直接生成。做目标检测把分割多边形转成边界框就是训练数据。但我建议你不要直接用min(x)、min(y)算边界框而是先对多边形做一次凸包计算cv2.convexHull尤其是枝条长而弯曲的情况下凸包更接近人类标注者的检测框习惯。数据集扩展方向这套数据收集时可以考虑加入不同果园、不同品种苹果的图像增加无人机俯拍视角增加不同生长年份的枝条特征这样模型在不同果园、不同管理模式下能保持更好的泛化能力避免“换个果园就失效”的尴尬。5. 避坑指南与独家实操心得5.1 标注阶段容易忽视的细节不要相信“标完再回头改”。标注本身已经是一件极其消磨耐心的事一旦你决定跳过某个目标说“后面再补”十有八九不会回去补。哪怕当天只整理半张图也要把能看到的所有目标标完再保存切下一张。定期备份标注结果。labelme的JSON文件是小文件但数量多、改动频繁建议每天结束前把当天标注的JSON文件和对应的图片打包上传到网盘或NAS。我见过不止一个人因为电脑硬盘故障或误删除丢失了三四天的标注成果这种损失是补不回来的。不要让标注者连续工作超过3小时。这个可能是看起来最不像技术建议的建议但操作正确率下降的曲线非常陡峭。标注第100张图时和标注第20张图时的专注力完全不是一个级别疲劳状态下容易出现多边形点数随意、漏标增加、类别颜色混淆等问题。即便你有时间限制也尽量保持每次标注的时间段在2到3小时中间强制休息。5.2 格式转换环节最容易翻车的地方转换脚本如果不是你自己写的一定要先拿3到5张图做端到端验证跑通后再批量处理。这不是谨慎过度——labelme的版本差异、JSON里字段命名差异都可能让脚本失效。验证方法很简单转出来的数据拿OpenCV或matplotlib可视化看看掩码和原图是否对齐转成COCO后用COCO官方API的coco.loadAnns和coco.showAnns验证加载是否正常转成YOLO标签后用YOLO官方的plot_labels或自己写一个可视化函数把归一化坐标还原成像素坐标叠在原图上看。转换流程只在脚本里跑通不叫通能在训练框架里加载成功才算数。5.3 训练过程中如果发现分割效果差优先怀疑数据而不是模型模型训练后mask预测差大家第一反应通常是“换更好的骨干网络”或“调更大的学习率”。但以我的经验80%的情况问题出在数据上标注边界不准确、类别分布严重倾斜、验证集和训练集图像分布不一致。建议优先回到数据侧排查可视化训练集里预测错误的样本检查是否集中分布在某个类别、某种光照、某个角度下统计mask预测错误区域的标签和类别找出系统性的标注偏差把验证集减半重新训练看性能波动是否显著——如果显著说明验证集样本太少或分布不稳。这些操作远比换模型更有效而且改动成本更低。5.4 后续扩展思路这套数据集的3类别设计在结构上很像“主干-果实”体系。你可以直接把同样的方法迁移到其他果树——柑橘果梗和枝条、葡萄果梗和卷须、番茄果柄标注逻辑几乎一致只是颜色和形态细节不同。如果要从分割升级到更高层次的农事决策比如“疏果点定位”可以在3类基础上增加果实成熟度属性标签做联合识别属性分类如果要做采摘机械臂的视觉引导可以进一步采集双目立体图像把一维的2D分割图和深度图对齐生成带深度的实例分割数据。从这个角度讲这套3类别712张的数据集不只是当前任务的副产品也是后续更复杂系统的数据底座。6. 实用脚本与资源配置清单6.1 推荐的开源工具与库做这套数据集及后续训练主要用到的工具链如下用途工具/库说明标注工具labelme 5.1.1开箱即用支持多边形标注格式转换Python json opencv-python自写脚本按需转换数据增强albumentations图像与掩码同步增强天然支持语义分割训练mmsegmentation 或 ultralytics YOLOv8mmsegmentation功能全YOLOv8-seg更轻量实例分割训练ultralytics YOLOv8-seg 或 detectron2两者都支持COCO格式可视化和验证matplotlib opencv叠加显示检查标注质量6.2 目录结构与命名规范数据集的目录结构建议统一成这种形式方便后续扩展和多人协作apple_stem_branch_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ (对应labelme的JSON文件或YOLO标签) │ ├── val/ │ └── test/ ├── masks/ │ ├── train/ │ ├── val/ │ └── test/ ├── coco_annotations/ │ ├── train.json │ ├── val.json │ └── test.json ├── scripts/ │ ├── convert_labelme2yolo.py │ ├── convert_labelme2coco.py │ └── visualize_check.py └── README.md命名上有一个细节每张图片的ID保持全局唯一采用AAA_BBB_CCC.jpg的格式AAA代表采集日期BBB代表果园编号或地块编号CCC代表当天采集序号。这样即使多批次数据合并也不会出现文件名冲突。我吃过文件名重复的亏当时两个批次里都有IMG_0001.jpg合并后互相覆盖找回花了不少精力。6.3 三个小工具建议自己写官方脚本够用了但下面三个工具建议根据自己需求写个小轮子重复图像查重工具采集时可能不小心重复拍摄同一目标用感知哈希pHash算法计算图像指纹之间的汉明距离距离小于阈值的即判定为重复图像并把重复数据从数据集中剔除。重复图像会让训练集和验证集之间存在“隐式泄漏”评估结果虚高。类别分布统计工具遍历所有标注文件统计每个类别的图像数量、标注对象数量、平均每图数量可以快速定位类别覆盖率是否均匀。边界复杂程度工具计算每个标注多边形的顶点数和周长找出异常复杂或异常简单的目标检查是否有标注质量问题。顶点数突然飙升通常意味着手滑多点了一圈或者把树叶边缘的锯齿也描进去了。这三个工具总共不超过200行代码但能把数据集的质量把控从“靠感觉”变成“可量化”。这套苹果果梗枝条分割数据集从零到一做完最深的体会是数据集的价值不取决于图片数量而取决于标注一致性、类别定义的清晰程度、以及验证流程是否完整。712张图听起来不多但如果每张图的标注都经得起像素级推敲它能带来的模型性能提升远超为了凑数盲目采到2000张图但标注粗糙的数据集。如果你也在做类似的分割数据准备工作建议从第一步就严格要求类别定义和标注规范后面所有环节都会顺利很多。