西红柿成熟度检测实战：YOLOv8训练与数据格式转换指南

简介这是一份面向目标检测任务的数据集资源聚焦番茄西红柿成熟度检测场景适合计算机视觉初学者及农业智能化项目开发者用于YOLO、Faster R-CNN等模型的训练与评估。数据包共收录1931个文件包含643张JPEG原图、643个Pascal VOC格式XML标注文件以及645个YOLO格式TXT标注文件标注工具为labelImg矩形框标注了fully_ripened、green、half_ripened三个类别覆盖番茄从绿果到成熟果的不同状态累计框数7781个压缩包整体约605MB。三类标签中green类框数最多5134个有助于模型学习未熟果与成熟果的外观差异。资源同时提供VOC与YOLO两种格式用户无需额外转换即可接入主流检测框架解压后目录结构清晰便于直接划分训练集与验证集。已有1035人学习下载适合用于番茄成熟度分级、果实计数、智慧农业采摘机器人等任务能有效支撑学术实验与工业项目落地。 最近在折腾农业场景的目标检测项目正好翻到一份西红柿番茄成熟度检测数据集640张图片、3个成熟度类别压缩包里同时给了VOC和YOLO两种标注格式。和那些动辄上万张的通用数据集比起来它确实不算大但恰恰因为“小”反而把目标检测里几个最要命的问题都暴露出来了——格式转换、类别定义、小目标漏检、指标解读一样不少。这篇文章写给两类人一类是刚接触YOLO、想拿现成数据集跑通目标检测流程的新手另一类是手头有自己采集的图片、正在琢磨怎么把标注整理成VOC/YOLO格式再训练的从业者。我会从数据集的目录结构拆起一路讲到训练命令、参数选择最后把我在实测中踩过的坑和调优经验一并整理出来。1. 数据集解析640张图片与3个成熟度等级1.1 3个类别其实是农业品控里最关心的三个节点首先解决一个问题成熟度为什么值得检测西红柿采摘时机直接决定了它的口感、储运损耗和货架期。未成熟果硬度高但不甜成熟果风味好却容易在运输中碰伤。所以从采摘、分拣到仓储每个环节都需要快速判断果实处于哪个阶段。这份数据集把成熟度划成3类是最常见也最稳妥的粒度green未成熟整体青绿色turning转色期果面出现黄绿或红绿过渡色也就是半熟ripe成熟果面以红色为主有几个边界样例值得单独说。有的果实大概是七成熟一面红一面青这时候不同标注员很可能给出不同结果。这种“判不齐”的样本恰恰决定模型天花板。如果你打算扩展这份数据集我建议在标注规范里明确这一类怎么定比如颜色占比大于等于某个阈值就归为下一阶段否则归为当前阶段。1.2 640张图听起来少但有效样本量比想象中多先说结论640张图直接拿来训练是能出一个不错的baseline模型的前提是图片里的目标密度足够。我简单算一笔账。假设每张图平均有8个西红柿果实640张图就是约5120个实例。COCO里面有80类目标、大约110万实例算下来每类1万多一点你这5120个实例只分3类平均每类1700多个。也就是说在“每个类别的实例数”这个维度上这份小数据集并没有低到离谱。相比之下真正的风险在于“场景单一”。如果640张图都是在同一块地、同一种光照、同一个拍摄角度下采集的那训练时指标再漂亮换到真实棚拍或田间依然容易崩。建议拿到数据后先肉眼翻一遍图片统计光照、背景、距离的多样性。如果多样性一般后面第三部分的训练策略就要主动加强数据增强来补偿。2. VOC与YOLO双格式目录结构、标注逻辑与互相转换2.1 先看解压后的目录结构拿到zip解压以后结构通常是这样tomato_dataset/ ├── images/ │ ├── tomato_001.jpg │ ├── tomato_002.jpg │ └── ... ├── annotations_voc/ │ ├── tomato_001.xml │ ├── tomato_002.xml │ └── ... ├── labels_yolo/ │ ├── tomato_001.txt │ ├── tomato_002.txt │ └── ... ├── train.txt ├── val.txt └── classes.txtimages目录放原始图片annotations_voc目录放VOC格式的XML标注labels_yolo目录放YOLO格式的txt标注train.txt和val.txt是切分好的图片路径列表classes.txt记录3个类别名一行一个。补充一句有的发布者会把图片按train/val拆成两个文件夹那就是更省事的结构如果像上面这样所有图混在一个目录就需要靠train.txt和val.txt来区分训练集与验证集。无论是哪种只要训练框架能定位到图片和标注即可。2.2 两种标注格式的字段一张表看懂VOC格式源自Pascal VOC竞赛标注信息存在XML里一层层嵌套。打开tomato_001.xml核心内容大致长这样annotation filenametomato_001.jpg/filename size width640/width height480/height depth3/depth /size object nameripe/name bndbox xmin120/xmin ymin80/ymin xmax260/xmax ymax230/ymax /bndbox /object /annotationYOLO格式则是一个txt文件对应一张图每行一个目标格式是类别id加四个归一化坐标2 0.296875 0.322917 0.218750 0.312500两种格式的字段对照如下含义VOC格式YOLO格式图片尺寸size/width、size/height无需自行读取图片类别object/name字符串行首整数从0开始框左上角xbndbox/xmin无需换算框左上角ybndbox/ymin无需换算中心点x无需计算第2列(xminxmax)/2/width中心点y无需计算第3列(yminymax)/2/height框宽xmax - xmin第4列(xmax-xmin)/width框高ymax - ymin第5列(ymax-ymin)/height一句话总结VOC存的是像素绝对坐标人类看着直观YOLO存的是归一化相对坐标模型训练效率高。两者是完全等价的只是表达方式不同。2.3 双格式的真正价值省掉一次转换可能有人会问既然YOLO训练直接用txt那XML标注还有啥用我的看法是XML版本保留了更完整的对象级信息而且兼容面广。比如你要做算法对比实验老一点的检测框架可能只吃VOC格式要跑mmdetection这套工具链也更习惯于VOC风格的标注。再比如你要做标注质量审查XML里可读的字符串和坐标明显比一行数字更好检查。很多数据集发布者习惯“VOC做存储YOLO喂训练”双份都给本质就是为了兼容生态里不同的训练框架。2.4 实际转换VOC到YOLO时我的脚本长这样虽然这个数据集自带双份但你自己的数据不一定。我本地常备一个转换脚本核心代码不长import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, class_names, output_path): tree ET.parse(xml_path) root tree.getroot() width int(root.find(size/width).text) height int(root.find(size/height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_names: continue cls_id class_names.index(name) box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) x_center (xmin xmax) / 2 / width y_center (ymin ymax) / 2 / height w (xmax - xmin) / width h (ymax - ymin) / height lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}) with open(output_path, w) as f: f.write(\n.join(lines)) class_names [green, turning, ripe] voc_to_yolo(tomato_001.xml, class_names, tomato_001.txt)有几个坑我在转换时踩过一是忘了除以width和height导致训练时坐标里出现大于1的数损失飞起二是类别列表的顺序必须和后续训练配置一致否则预测结果张冠李戴三是当某张图没有任何目标时txt应该生成空文件而不是不生成否则某些框架会把它当成“没有对应标注”的图像丢弃。3. 实操用这份数据集训一个西红柿成熟度检测模型3.1 把数据规整成Ultralytics YOLO的标准目录开始训练前建议先把数据集整理成YOLO官方工具链最常见的目录布局datasets/tomato/ ├── images/ │ ├── train/ │ │ ├── tomato_001.jpg │ │ └── ... │ └── val/ │ ├── tomato_051.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── tomato_001.txt │ │ └── ... │ └── val/ │ ├── tomato_051.txt │ └── ... └── tomato.yaml如果zip自带train和val切分文件先读一下确认训练集和验证集的比例。我习惯按8:2切如果发布者已经切好就沿用没有就自己按图片名随机切。这里最关键的一条规则是images和labels目录必须严格同名一一对应且train下的图对应train下的标注。漏一张标注文件训练时那张图会被静默跳过不报错但数据量就少了一张。我见过有人图方便把全部标注复制到labels目录下结果训练日志里一张图都没用上白白跑了几小时。3.2 tomato.yaml训练前的最后一道配置YOLOv8训练读的是data配置文件tomato.yaml写起来非常简单path: ./datasets/tomato train: images/train val: images/val nc: 3 names: 0: green 1: turning 2: ripepath是数据集根目录train和val填相对path的路径nc是类别总数names是类别名列表。names的顺序不是随便写的它必须和txt标注里每行开头的整数id一一对应。如果你不想每次训练都从绝对路径找数据把path写成相对路径能避免换电脑后路径失效的问题。3.3 训练命令与参数选择含实际推理验证环境装好YOLOv8之后pip install ultralytics一条命令就能启动yolo detect train datatomato.yaml modelyolov8s.pt epochs100 batch16 imgsz640 device0说下参数选择逻辑modelyolov8s.pt加载COCO预训练权重做迁移学习。农业外观和通用物体差异大但底层特征仍有价值比从零训练快得多。epochs100对640张的小数据集来说通常足够。训练过程里盯着val loss收敛后就停。batch16中等显存8G及以上跑yolov8s比较稳。显存紧张就改成8。imgsz640和常见训练尺寸一致。需要注意的是如果原图不是正方形YOLO会自动缩放填充。训练结束后用best.pt跑一次验证yolo detect val modelruns/detect/train/weights/best.pt datatomato.yaml然后再跑一张实际图片看看预测效果yolo detect predict modelruns/detect/train/weights/best.pt source./test_tomato.jpg这一步很多人图省事略过但我建议一定做。指标只能说明整体趋势具体框得准不准、有没有把青果误判成红果亲眼看一次才放心。3.4 评价指标不能只盯mAP50训练结束后Ultralytics会在runs/detect/train目录下生成结果文件。目标检测领域最常用的评价指标有四个Precision精确率预测框里真正是目标的比例Recall召回率真实目标中被找出来的比例mAP50IoU阈值0.5时的平均精度均值mAP50-95IoU从0.5到0.95取平均对框的定位精度要求更严苛我自己的习惯是先看mAP50、再看Recall。特别是在农业场景漏检一个成熟果实意味着少采一个比多框一个未熟果的代价更高。你要是侧重采摘机器人的视觉系统可以把阈值往“高召回”方向调要是做上市分拣那误检导致分错级别更麻烦就要多关注Precision。对640张的小数据集来说mAP50能到0.85以上已经算不错的结果不用盲目追0.95这种数字。4. 训练时最容易踩的坑与调优心得4.1 我在标注和格式上踩过的坑先列几个我在实测里遇到过、身边同事也经常犯的问题。第一txt坐标写成像素值。打开txt一看里面是320 240 100 80这样的数字这就是没做归一化。训练时损失会异常大甚至直接nan。排查方法很简单写脚本扫描txt统计所有坐标值是否都落在0~1之间。第二yaml里names顺序和标注id对不上。这个问题隐蔽训练不报错但预测时类别全乱。建议训练前写个脚本读取txt标注打印每个id出现的次数再和yaml里的names核对一遍。第三XML里object存在嵌套。有些VOC标注的object外层还包着一层group或parent结构解析时如果只找root.findall(object)可能漏目标。转换前先打印一个XML全量结构心里有数再批量处理。4.2 小目标漏检和密集果实的解决思路西红柿检测真正难的不是类别区分而是“果实太密、太小、遮挡严重”这三座大山。远看一整串小番茄单颗只有二三十像素在640分辨率下非常容易漏掉。亲测有效的几个方案提高输入分辨率。同一套数据imgsz从640调到960小目标召回率能明显涨代价是显存涨一倍训练时间变长。开启SAHI切片推理。把大图切成带重叠的patch分别检测再合并结果对密集小目标效果很显著适合推理阶段使用。降低马赛克增强的权重。马赛克把四张图拼一起小目标会被进一步缩小如果本来果实就小增强后更难学。在ultralytics里可以调mosaic和mixup的概率。检查标注质量。我用LabelImg核对过一批数据发现个别标注框把两三个紧挨的果实框成了一个整体或者把枝叶也包进去这种标注会直接把模型带偏。4.3 类别不均衡怎么办如果统计完发现红果实例特别多、青果很少模型会天然偏向学多数类。我的处理方式分两步。先做统计确认不均衡程度。写个脚本遍历所有txt统计每个类别id出现的总次数。如果最少的类别实例数不到最多的三分之一就得干预。干预手段我优先选择“少样本过采样”也就是把青色果实出现较多的图片在训练时多喂几遍或者复制这类图片并做轻度仿射变换后再加入训练集。相比简单重复引入色彩抖动、随机裁剪等增强会更好因为西红柿成熟度识别本来就依赖颜色特征。另外可以把损失函数的类别权重调高比如给少数类的box loss乘一个大于1的系数让模型在优化时更关注少数类。Ultralytics里可以直接改loss相关参数虽然不如数据层面干预直观但实测能改善边界情况。最后说点个人体会。像这种640张、3类别的小型实例数据集最大的价值不是“训练出SOTA模型”而是用它把目标检测的完整链路快速跑通拿到zip、拆开目录、看懂两种标注、配yaml、训练、评估、调优。链条里每一步都会遇到真实的坑而这些坑换成大几十万张的数据集反而容易被掩盖。我的建议是不要满足于把模型跑起来顺手再扩一点从视频里抽帧补充遮挡和光照变化、用训练好的模型做半自动标注、把三种成熟度按占比细分成更多等级。这个数据集花不了多少训练时间折腾一轮下来你对目标检测的理解会扎实很多。就这样照着上面的流程跑一遍大概率能少走不少弯路。本文还有配套的精品资源点击获取