当前位置：首页 > news >正文

番茄叶子实例分割数据集实战：从zip解压到yolov8训练全流程

news 2026/8/27 22:18:33

简介：实例分割是计算机视觉中极具挑战性的任务，它不仅需要检测目标位置，还需精确到像素级轮廓。在农业智能化场景下，对番茄叶片进行实例分割可实现作物表型分析、病虫害监测等应用，其核心在于高质量数据集与高效训练框架的配合。而YOLO系列作为目标检测与分割的主流工具，对数据格式和目录结构有严格要求。针对一个包含原始图像与标注文件的番茄叶片数据集，从解压、目录梳理、格式校验到COCO与YOLO标注互相转换，再到数据质量体检和yolov8训练参数调优，每一步都直接决定最终分割效果。本文即围绕这一完整链路，分享zip损坏修复、中文乱码处理、归一化坐标检查、mAP指标解读等实战经验，帮助计算机视觉开发者少走弯路，快速构建可靠的农业视觉模型。拿到“番茄叶子实例分割数据集_20251117_005928.zip”这个包，我的第一反应不是急着解压看图片，而是先把它当作一个“黑盒”来对待：文件名里带着时间戳，说明是一次批量导出或采集任务的结果；类别是番茄叶子，标注任务是实例分割，这意味着它大概率包含两类核心文件——原始图像和对应的掩码标注。

但真正落到实操层面，很多人会在这一步被卡住：要么解压报错，要么解压完之后发现目录结构和预想完全不一样，要么标注格式和训练框架不匹配。这篇文章我会把从“拆开这个zip”到“用yolov8把它真正训练起来”的完整链路走一遍，包括zip损坏排查、标注格式判断与转换、数据质量体检、训练参数选型，以及在验证阶段容易踩的坑。适合刚拿到类似数据集，准备做作物表型分析、病虫害检测或自建分割数据集的同学参考。

1. 拿到zip后的第一件事：目录解构与数据体检

1.1 别急着双击解压，先用命令看一眼文件树

很多人第一步就是双击解压，然后对着“解压失败”的弹窗发呆。我的习惯是先用命令行工具列一下压缩包内容，确认里面到底是什么结构，再决定怎么解压。这个习惯救过我很多次，因为zip包在传输过程中可能被截断、被重复压缩，甚至可能是自解压格式，只是换了扩展名。

在Windows上用PowerShell的话，可以这样：

tar -tf 番茄叶子实例分割数据集_20251117_005928.zip

在Linux或macOS上直接用：

unzip -l 番茄叶子实例分割数据集_20251117_005928.zip

-l是list的意思，只列出内容不实际解压。通过这个命令能迅速看到包内是否有明显的目录层级，比如images/、labels/、annotations/，还是所有文件都平铺在一个根目录下。这对后续路径配置影响很大，yolov8的data.yaml里需要明确设置训练集和验证集的路径，如果图像和标签散落一地，先梳理目录反而是最重要的一步。

如果这个命令本身都报错，那就进入第2章的排查流程了。

1.2 图像和标签的组织方式决定了后续所有操作

一个典型的实例分割数据集，文件组织上通常有两种流派：

图像文件夹 + 标注文件夹：images/下放jpg/png，labels/下放与图像同名的txt文件（yolo格式），或者annotations/下放一个大的json文件（coco格式）
单一根目录 + 多个子集：train/、val/、test/下分别有图像和标注

对于番茄叶子这类偏作物表型的数据集，常见做法是每个子集目录里直接平铺图片和对应标注，标注可能是json、xml或txt，取决于采集时使用的标注工具。

我个人建议拿到包之后立刻做一次结构化整理，统一成下面这种形式：

datasets/ TomatoLeaf/ images/ train/ val/ labels/ train/ val/

为什么要统一？因为yolov8训练时默认就是images/train和labels/train对应的目录，虽然可以通过data.yaml里的路径参数改，但越接近默认结构，后面越省心。而且整理目录的过程也相当于一次人工数据巡检，能发现文件名不匹配、样本重复、图片损坏等问题。

1.3 五分钟数据体检脚本

别急着训练，先写个脚本把数据集的底摸清楚。我通常会检查这几个维度：图像总数、类别数量、类别分布、图像分辨率范围、标注格式、标注是否越界。

下面这个脚本可以直接复制使用，它会扫一遍目录下的图片和标签，输出关键统计信息：

import os from collections import Counter from PIL import Image images_dir = 'TomatoLeaf/images/train' labels_dir = 'TomatoLeaf/labels/train' img_exts = {'.jpg', '.jpeg', '.png', '.bmp'} img_files = [f for f in os.listdir(images_dir) if os.path.splitext(f)[1].lower() in img_exts] label_files = [f for f in os.listdir(labels_dir) if f.endswith('.txt')] print(f'图像数量: {len(img_files)}') print(f'标签数量: {len(label_files)}') # 检查文件名是否匹配 img_names = {os.path.splitext(f)[0] for f in img_files} label_names = {os.path.splitext(f)[0] for f in label_files} print(f'有图像无标签: {len(img_names - label_names)}') print(f'有标签无图像: {len(label_names - img_names)}') # 统计类别分布和标签行数 class_counter = Counter() seg_point_count = [] bad_labels = [] for lbl in label_files: with open(os.path.join(labels_dir, lbl), 'r') as f: lines = [line.strip() for line in f if line.strip()] if not lines: bad_labels.append((lbl, '空标签')) continue for line in lines: parts = line.split() try: class_id = int(parts[0]) class_counter[class_id] += 1 seg_points = (len(parts) - 1) // 2 seg_point_count.append(seg_points) except ValueError: bad_labels.append((lbl, f'非法行: {line}')) print(f'类别分布: {dict(class_counter)}') print(f'分割点数范围: {min(seg_point_count) if seg_point_count else 0} ~ {max(seg_point_count) if seg_point_count else 0}') print(f'问题标签样本: {bad_labels[:5] if bad_labels else "无"}')

这个脚本跑完，你就能快速判断数据集是否符合预期。比如类别分布如果极度不均衡，某个类别出现了几千次而另一个类别只有几十次，那训练时就要考虑类别权重或过采样。如果分割点数量普遍很少（比如只有4-6个点），说明标注非常粗糙，可能无法精确表达叶片边缘，后期需要人工修正或使用更精细的标注数据。

2. zip解压连环坑：从file is not a zip file到could not find eocd

2.1 报错背后的zip文件结构和魔数逻辑

zip文件不是一个简单的文本文件，它有明确的二进制结构。每个zip文件开头必须有PK\x03\x04这样的魔数（对应十六进制50 4B 03 04），文件结尾则必须有EOCD（End of Central Directory）记录，这个记录存在于文件最后几十个字节，用来告诉解压程序“整个压缩包有多少个条目、中央目录偏移量在哪里、能否完整读取”。

当你看到file is not a zip file或invalid zip archive: could not find eocd时，本质上就是文件头或文件尾不符合zip规范。最常见的情况有三种：

文件下载不完整：传输中断或复制时被截断，文件末尾的EOCD缺失
文件头被破坏：有人把zip文件伪装成别的格式上传，或者文件开头被写了其他内容
压缩包被二次处理：比如用过时的网盘客户端转存，或者中间有人用文本文档方式编辑过

我测试过一个真实案例：一个从网络下载的zip在解压时提示could not find eocd，用file命令查看，结果显示data而不是Zip archive data，说明文件头魔数都没了。后来检查文件大小，发现实际只下载了原始文件的三分之一，是断点续传没有生效导致的。

2.2 按报错症状分级排查

这里整理一个排查表，对照症状直接找方案：

报错信息	可能原因	处理方式
`file is not a zip file`	文件头损坏或根本不是zip	用`file`命令确认格式，尝试7z打开
`invalid zip archive: could not find eocd`	文件被截断或损坏	重新下载/拷贝，使用`zip -FF`尝试修复
`error opening zip file or jar manifest missing`	文件损坏或路径配置错误	检查文件完整性，确认不是伪zip
解压后中文文件名变成“锟斤拷”	编码问题，GBK被错误解码为UTF-8	用7z或Python按指定编码解压
`failed to copy spatial iop zip`	特定软件内的资源包导入失败	确认zip包本身完整，检查是否对应软件版本

如果你是用Windows资源管理器解压失败，建议立刻换成命令行工具重新尝试。Windows自带的解压逻辑对损坏zip的容错性很差，7-Zip的容错和恢复能力要强得多，而且能明确告诉你损坏发生在哪个文件。

2.3 用7z和zip -FF修复损坏包

对于已经损坏的zip，有几个实测可用的恢复思路：

方法一：7-Zip强制解压

7z x 番茄叶子实例分割数据集_20251117_005928.zip -o输出目录

7z的容错机制会尝试跳过损坏的条目，把完好部分解压出来。如果zip包的中央目录还能读，这个方法通常能救回大部分文件。

方法二：zip -FF修复

zip -FF 番茄叶子实例分割数据集_20251117_005928.zip --out fixed.zip

这个方法适用于文件末尾EOCD丢失但中央目录数据还在的情况。工具会扫描文件内容，重建中央目录，输出一个新zip。修复成功后再解压fixed.zip。

方法三：Python的zipfile模块读取

import zipfile try: with zipfile.ZipFile('番茄叶子实例分割数据集_20251117_005928.zip') as zf: names = zf.namelist() print('可读取条目数量:', len(names)) except zipfile.BadZipFile as e: print('无法读取:', e)

Python的zipfile模块能提供更准确的错误信息，虽然它本身不擅长修复，但可以用来判断哪些条目是完好的。如果你想更精细地抢救文件，可以逐条尝试读取每个文件，把能读到的单独存出来。

2.4 中文文件名乱码与编码修复

解压后文件名变成“锟斤拷”或者一串乱码，这是另一个高频问题，本质是编码不匹配。Zip文件内部对文件名的编码并没有强制标准，很多中文环境创建的zip用的是GBK/GB2312，而Linux和macOS默认按UTF-8解码，解码失败就成了乱码。Windows上用某些第三方解压工具也可能出现类似问题。

解决方法是用7-Zip解压时指定编码，或者用Python脚本手动解码。

import zipfile import os src = '番茄叶子实例分割数据集_20251117_005928.zip' out = 'output' with zipfile.ZipFile(src) as zf: for info in zf.infolist(): # 重新解码文件名，GBK编码的文件名按UTF-8解码会变乱码 try: name = info.filename.encode('cp437').decode('gbk') except (UnicodeDecodeError, UnicodeEncodeError): name = info.filename target = os.path.join(out, name) os.makedirs(os.path.dirname(target), exist_ok=True) with zf.open(info) as src_file, open(target, 'wb') as dst_file: dst_file.write(src_file.read())

这里的思路是：先把文件名按cp437重新编码回原始字节，再按gbk解码成正确的中文。如果你的文件名是从UTF-8环境生成的，把gbk换成utf-8即可。

提示：我实际用这种方法修复过一批从老设备导出的数据集。遇到乱码先别急着删文件，大概率不是文件损坏，只是编码没选对。

3. 标注格式摸底：COCO vs YOLO，先看mask长什么样

3.1 实例分割标注的核心三要素

实例分割标注和检测标注最大的区别在于：除了类别和边界框，还有逐实例的轮廓或多边形信息。这让模型能区分同一类别下的不同个体——同一张图上三片番茄叶子交叠在一起，模型需要输出三个独立的掩码。

理解三个关键要素就能看懂绝大多数实例分割标注文件：

category_id：类别编号，对应类别名称表
bbox：目标的外接矩形，通常用[x, y, width, height]表示
segmentation：实例的轮廓描述，可能是多边形坐标集合，也可能是RLE（Run-Length Encoding）压缩编码

在COCO格式中，segmentation有时是一系列坐标点的扁平列表（如[x1,y1,x2,y2,...]），有时是RLE字典（{"counts": "...", "size": [h, w]}）。在YOLO分割格式中，每一行记录是class_id x1 y1 x2 y2 ... xn yn，所有坐标都归一化到0-1之间。

3.2 快速判断这个数据集是哪种格式

拿到数据集后快速判断格式，可以按顺序检查三个线索：

看文件扩展名：如果标注文件是大量txt且与图像同名，基本是YOLO格式；如果是单个json文件，基本是COCO格式；如果是xml文件，可能是VOC格式。
看文件名：YOLO的标签文件名通常与图像名完全一致，只是扩展名不同，比如leaf001.jpg对应leaf001.txt。COCO则是一个统一的annotations.json。
看文件内容：YOLO txt的第一行是数字开头的多个浮点数，比如0 0.5123 0.4231 0.5342 0.4351 ...，第一个数字是类别id，后面依次是点坐标（两两一组）。COCO json则是一大段嵌套的JSON结构。
看目录结构：如果包里有train.json、val.json，那是COCO风格无疑；如果有images/train和labels/train，那是YOLO风格。

3.3 格式转换实操：COCO转YOLO分割txt

如果你的数据集是COCO格式而你想用yolov8训练，就需要做一次转换。虽然ultralytics框架提供了一些内置的转换支持，但自己写脚本转换更可控，也方便在转换过程中加入数据清洗逻辑。

下面这段代码把COCO格式的标注文件转换成YOLO分割格式：

import json import os def coco_to_yolo_seg(coco_json, output_dir): with open(coco_json, 'r') as f: data = json.load(f) # 建立图像id到文件名的映射 img_id_to_name = {img['id']: img['file_name'] for img in data['images']} img_id_to_size = {img['id']: (img['width'], img['height']) for img in data['images']} # 建立类别id到索引的映射 categories = sorted(data['categories'], key=lambda x: x['id']) cat_id_to_idx = {cat['id']: idx for idx, cat in enumerate(categories)} print('类别映射:', {cat['name']: cat_id_to_idx[cat['id']] for cat in categories}) os.makedirs(output_dir, exist_ok=True) # 把同一个图像的所有标注聚合在一起 img_annotations = {} for ann in data['annotations']: img_id = ann['image_id'] img_annotations.setdefault(img_id, []).append(ann) for img_id, anns in img_annotations.items(): file_name = img_id_to_name[img_id] width, height = img_id_to_size[img_id] yolo_lines = [] for ann in anns: # 处理分割标注 seg = ann['segmentation'] if isinstance(seg, list): # polygon格式，可能有多个多边形 for poly in seg: # 展平坐标点 points = [(poly[i] / width, poly[i+1] / height) for i in range(0, len(poly), 2)] cls_id = cat_id_to_idx[ann['category_id']] line = f"{cls_id} " + " ".join(f"{x:.6f} {y:.6f}" for x, y in points) yolo_lines.append(line) else: # RLE格式通常来自coco的压缩掩码，需要先转换为polygon # 这个转换较复杂，建议单独用pycocotools处理 print(f"警告: {file_name} 使用了RLE格式，需要额外转换") # 写文件 txt_name = os.path.splitext(file_name)[0] + '.txt' with open(os.path.join(output_dir, txt_name), 'w') as f: f.write('\n'.join(yolo_lines)) print(f'转换完成，输出到 {output_dir}') coco_to_yolo_seg('annotations/instances_train.json', 'labels/train')

几个容易出错的点：

坐标归一化：归一化时一定要除以图像的原始宽和高，不是除以同一个值。很多标注工具输出不规则尺寸，强行统一缩放会导致掩码错位。
类别索引重映射：COCO的category_id不一定是从0开始的连续整数，YOLO要求类别索引必须为0,1,2...，所以要做一次映射。
多边形的处理：一个实例如果有多个分离的轮廓（比如叶子被遮挡分成两片），COCO会存成多个polygon，此时每个polygon都要单独写成一行吗？不对，YOLO分割格式中同一个实例的多个轮廓应该放在同一行还是不同行，取决于具体实现。在ultralytics中，一个目标的所有轮廓点可以合并到同一行，类别id相同即可。但如果不同类别的多个轮廓，必须拆行。

3.4 数据质量检查：漏标、误标、重叠

在转换完成之后，强烈建议做一次可视化验证，把标签画回图像上。这一步能发现大量肉眼可见的问题：

漏标：图上明显有番茄叶子，但标签文件是空的
误标：把背景区域当成叶子，或者把病斑区域单独标成叶片
类别错标：把“病斑”类别归到了“健康叶”下
坐标归一化异常：某个坐标值大于1或小于0，说明格式转换有bug

我自己处理过一批叶片数据，发现转换后有一部分标签的归一化坐标明显超出图像边界，逐帧检查后定位到原因：标注工具输出的是绝对像素坐标，但我在做归一化时误用了缩放后的图像尺寸。修复后mAP直接提升了6个百分点，数据质量对训练的影响就是这么直接。

可视化验证脚本其实不复杂，核心就是用opencv把多边形画到原图上：

import cv2 import os import random img_dir = 'images/train' label_dir = 'labels/train' out_dir = 'visual_check' os.makedirs(out_dir, exist_ok=True) img_files = os.listdir(img_dir)[:10] colors = [(0, 255, 0), (0, 0, 255), (255, 0, 0), (0, 255, 255)] for img_file in img_files: img = cv2.imread(os.path.join(img_dir, img_file)) h, w = img.shape[:2] txt_file = os.path.splitext(img_file)[0] + '.txt' txt_path = os.path.join(label_dir, txt_file) if not os.path.exists(txt_path): continue with open(txt_path, 'r') as f: for line in f: parts = line.strip().split() cls_id = int(parts[0]) points = [] for i in range(1, len(parts), 2): x = float(parts[i]) * w y = float(parts[i+1]) * h points.append((int(x), int(y))) cv2.polylines(img, [points], isClosed=True, color=colors[cls_id % 4], thickness=2) cv2.imwrite(os.path.join(out_dir, img_file), img) print('可视化完成')

4. 用yolov8训练自己的番茄叶子数据集

4.1 环境准备

yolov8训练实例分割模型，环境准备本身并不复杂，几个关键依赖要确认版本匹配。我踩过的坑是opencv-python和ultralytics版本冲突，导致训练时某个阶段莫名其妙地卡死。

建议按下面的组合安装：

pip install ultralytics==8.1.0 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install opencv-python==4.8.1.78

在开始训练之前，先用一个极小的模型和极少量数据验证整个流程能跑通。我习惯先用yolov8n-seg.pt跑20个epoch，只取80张图验证。这一步能快速暴露标签格式问题、路径配置错误、类别数量设置不对等低级错误，避免等跑了几个小时才发现根本上的错误。

4.2 data.yaml的写法

yolov8训练依赖一个yaml配置文件，内容很简单，但有几个细节很关键：

path: /data/TomatoLeaf # 项目根目录 train: images/train # 训练集图片路径，相对于path val: images/val # 验证集图片路径，相对于path # 类别名称，注意顺序必须与标签中的类别id一一对应 names: 0: healthy_leaf 1: diseased_leaf 2: old_leaf

这里最容易被忽略的是类别名称顺序。如果names的索引和标签文件里的类别id对不上，模型训练时会出现严重的错乱。比如标签文件里的类别id是1表示“病叶”，但yaml里索引1写成了“健康叶”，模型就会把病叶学成健康叶，训练过程看起来loss是在下降，实际mAP可能很差。

另外，路径这里推荐写绝对路径。虽然yolov8支持相对路径，但如果你在项目文件夹之间移动数据集，相对路径很容易失效，然后报一个莫名其妙的找不到图片错误。写绝对路径虽然不够优雅，但省事、稳定。

4.3 训练命令与参数选择

数据准备好了，训练命令是：

from ultralytics import YOLO model = YOLO('yolov8s-seg.pt') # 选择预训练权重 model.train( data='tomato_leaf.yaml', epochs=150, imgsz=640, batch=16, device=0, patience=30, project='runs/segment', name='tomato_leaf', verbose=True )

关于模型选型，.pt前面的字母代表模型规模：n是nano，s是small，m是medium，l是large。对番茄叶片这种背景相对简单但叶片边缘复杂的任务，我的经验是从yolov8s-seg起步比较稳妥。nano模型虽然训练快，但分割掩码的边缘精度通常不够，对小叶片和重叠叶片的表现偏弱；large模型效果通常最好，但对显存和训练时间要求更高。

几个重要参数：

imgsz：训练分辨率，默认640。如果你的数据集中叶片占图像比例很小，建议调大到800甚至1024
patience：早停参数，验证集mAP连续多少轮不提升就停止训练，默认100。我的习惯是设30-50，防止无限等待
batch：根据显存调整。8G显存跑yolov8s-seg，batch设8-16没问题
cache：如果数据集不大（几百张），设置cache=True可以把图片缓存到内存，训练速度提升明显

训练过程中要盯的关键指标是mAP50和mAP50-95，前者是框重叠程度50%时的平均精度，后者是50%到95%多个阈值下的平均精度，更严格。对于分割任务，还有一个mask_mAP系列指标，同样分mask_mAP50和mask_mAP50-95。如果mask_mAP50-95远低于mAP50，说明模型在高重叠阈值下的分割精度还有很大提升空间。

4.4 训练日志怎么看

训练时终端会不断输出loss和mAP信息，很多人只会看“loss降了没”，但有几个更重要的信号容易被忽略：

训练/验证loss的差距：如果训练loss稳定下降但验证loss不降反升，说明过拟合已经开始了，此时应该早停或增加数据增强
mAP曲线的震荡：验证mAP在小范围内波动是正常的，但波动幅度超过5个点就需要警惕，可能数据分布有问题或学习率偏高
类别间mAP差异：训练结束后，yolov8会输出每个类别的mAP。如果某个类别的mAP明显低于其他类，大概率是这个类别的样本量太少、标注质量差，或者和另一个类别在外观上太相似

我跑过一批番茄叶数据，刚开始old_leaf类别的mAP只有0.35，而healthy_leaf能做到0.82。检查后发现这个类别的训练样本中，大量标注把衰老边缘的黄色区域画错了轮廓。修正标注后重新训练，mAP直接提升到0.74。这个经历告诉我：模型效果不好时，八成问题不在模型配置，而在数据。

5. 训练后的验证、可视化与模型落地

5.1 用混淆矩阵找类别混淆

训练完成之后，runs/segment/tomato_leaf/目录下会自动生成多种评估图表，其中confusion_matrix.png是最值得细看的。

混淆矩阵能直观显示哪些类别之间互相混淆。比如番茄叶片和早期病斑叶片在颜色、纹理上非常接近，模型可能系统性把健康叶误判成病叶。看到混淆矩阵里某两个类别的交叉值很高，你就知道问题可能不是模型没学好，而是类别定义本身对模型来说难以区分。解决思路有两个：一是考虑合并类别，二是增加这两个类别的标注样本，尤其是包含两种类别同时出现的场景。

另外，我还建议手动跑几组推理，把模型预测结果可视化出来，在叶缘曲线、遮挡区域这些细节上对比预测掩码和真实掩码的差异。这类定性分析能发现指标无法暴露的问题。

5.2 针对番茄叶小目标与遮挡的优化

训练完如果发现模型对小叶片、重叠叶片的检测效果不佳，有以下几个实操优化方向：

提高输入分辨率：把imgsz=640改成imgsz=800或1024。小目标在低分辨率下信息缺失严重，提高分辨率是最直接的手段，代价是显存占用和训练时间增加。
调整数据增强策略：yolov8默认开启mosaic增强，对多数任务效果都很好，但mosaic会把四张图片拼接在一起，导致每个目标尺寸变小，反而让小目标学得更吃力。我的做法是训练前期开启mosaic，训练后期关闭：

model.train( ..., mosaic=0.8, # mosaic增强的概率 close_mosaic=10, # 训练最后10个epoch关闭mosaic )

检查类别权重：如果不均衡，可以在loss中增加类别权重，或者对少数类别的图像做重复采样。
调整anchor相关参数：虽然yolov8是anchor-free架构，不直接依赖anchor配置，但输入分辨率的变化确实会影响训练效果。同类问题优先考虑的是数据和增强，而不是模型结构。

5.3 模型导出与简易部署

训练完后通常会导出成ONNX格式，方便在端侧或服务器上部署。ultralytics提供了非常方便的导出接口：

model = YOLO('runs/segment/tomato_leaf/weights/best.pt') model.export(format='onnx', opset=12, imgsz=640)

导出后得到best.onnx，可以用onnxruntime做推理：

import onnxruntime as ort import numpy as np import cv2 from ultralytics.utils import ops session = ort.InferenceSession('best.onnx') input_name = session.get_inputs()[0].name image = cv2.imread('test_leaf.jpg') image_resized = cv2.resize(image, (640, 640)) input_tensor = image_resized[:, :, ::-1].transpose(2, 0, 1).astype(np.float32) / 255.0 input_tensor = np.expand_dims(input_tensor, axis=0) outputs = session.run(None, {input_name: input_tensor}) # outputs[0] 是检测框和类别 # outputs[1] 是分割掩码系数 # 需要结合protos计算最终掩码

这里需要特别提醒：yolov8-seg的ONNX输出不是直接就能画掩码的，它输出的是掩码系数和原型掩码（protos），需要做矩阵乘法才能得到最终的二进制掩码。如果你不想手写这些逻辑，最简单的方式还是直接用ultralytics的predict方法，它内部已经把后处理做完了。

model = YOLO('runs/segment/tomato_leaf/weights/best.pt') results = model.predict('test_leaf.jpg', conf=0.3, iou=0.5, save=True, save_txt=True, save_conf=True)

save_txt=True会把每个检测实例的类别、置信度和归一化坐标写入txt文件，这对做表型统计很有用。