信息速览
植物病理学有一句老话：田里的病害，纸上看不清。PlantVillage 把这句话做成了一个五万四千张的对照实验——它把叶片从植株上摘下来，平放在纸面上拍照，让全世界的算法都能在同一套干净条件下比出高下；然后在论文的讨论部分，把自己的成绩打了个三折：受控条件下 99.35%，换成从网上抓的真实现场照片，只剩约 31%。
本篇要交代的不是"又一个植物病害数据集"，而是这份数据为什么能成为该领域的事实标准，以及它同时在什么地方把后来者领进了沟里。它是站内第一篇农业方向的页面，所以还得顺带回答一个更前置的问题：一个连田间都还没跨过去的图像库，凭什么算 AI-ready。
一屏速览见下表。
| 字段 | 内容 |
|---|---|
| 数据集名称 | PlantVillage 数据集（PlantVillage Dataset） |
| 英文全称 | PlantVillage Dataset of diseased and healthy plant leaves |
| 别名/简称 | Plant Village；PlantVillage-Dataset；plantvillage。⚠️ 与 Mendeley 上 Geetharamani 与 Arun Pandian 发布的六万余张 / 39 类派生版不是同一发布物，检索时请核对发布者 |
| 对象 | 14 种作物、26 种病害加健康状态，合计 38 个作物-病害类 |
| 数据模态 | 静物彩色照片（单叶、离体、纸面底），另有灰度版与去背景分割版 |
| AI 任务类型 | 单标签图像分类（作物-病害联合判别）；可退化为作物识别；不适合检测与分割 |
| 图像总数 | 五万四千三百零六（官方仓库与论文口径）；镜像口径少一两张，最大派生版逾六万（详见 §2） |
| 类别数 | 38 |
| 作物数 | 14 |
| 图像规格 | 256 × 256，JPEG；原图分辨率不统一，官方处理流程统一缩放 |
| 数据大小 | 彩色子集约 2.18 GB（Kaggle 镜像显示值）；完整三版本体积官方未公布 |
| 许可证 | 官方仓库 README 与 Hugging Face 加载脚本声明 CC BY-SA 3.0；Kaggle 镜像标注 CC BY-NC-SA 4.0 |
| 访问级别 | 开放下载（无注册门槛） |
| 语言 | 目录名与文档为英文；无图像内文本 |
| 首发日期 | 2016-09-01（Frontiers in Plant Science 论文）；预印本 2015-11-25 |
| 最后更新 | 2026-02-05（上游仓库整理与 Hugging Face 链接更新，图像集本体未变） |
| 发布机构 | EPFL 数字流行病学实验室（Mohanty、Salathé）与 Penn State（Hughes） |
| 官方主页 | github.com/spMohanty/PlantVillage-Dataset |
| 下载地址 | GitHub 仓库；Hugging Face 镜像 |
| DOI | 10.3389/fpls.2016.01419（配套论文；图像集本身未单独注册 DOI） |
| AI 就绪度评分 | ⭐⭐⭐（3/5）— 目录即标签、三版本齐全、Hugging Face 侧带官方 80/20 叶片级划分；扣分项：无田间验证集、无病斑级标注、许可口径不统一、派生版在野外流通 |
| 页面状态 | published |
§1 它是什么：一份把叶子摘下来拍的病害图鉴
1.1 一句话定位
PlantVillage 是植物病理视觉研究里绕不过去的那份入门语料：14 种作物、26 种病害、38 个作物-病害类、五万四千余张 256 像素方形叶片照片，采下叶片、平放纸面、正上方拍摄，按目录归档，附带灰度版与去背景版。它在 2016 年让"用卷积网络认病害"第一次有了可复现的公共基准，也几乎同时把"这条路在纸面上走得通、在田里走不通"写进了同一篇论文的讨论部分。
判断一份数据集的地位，看它被引用时扮演什么角色最准。PlantVillage 扮演的角色始终是同一个：源域。要证明一个新网络能认出病虫害，先在这份干净数据上跑出接近满分的数字；要证明这个数字没有意义，再把它扔到田间数据集上，看它掉到多少。它自己不是终点，它是所有跨域论文都要经过的那道门槛。
1.2 为什么它不是一份普通的图像数据集
普通的图像分类数据集，规模越大越好、类别越平衡越好、标注越细越好。PlantVillage 三条都不占优：五万张在今天的标准里算小，类别极不均衡（最小类一百五十余张，最大类五千余张），标注只有一个目录级的作物-病害名。
它无可替代的地方在别处——它是唯一一份被当成"实验室条件"代名词使用、并且官方亲自量化了这个代名词代价有多大的农业图像集。论文的讨论部分写着：模型在受控条件数据上表现优异，但换到拍摄条件不同的图像上，准确率降到仅略高于 31%。这一段不是后人补的批评，是作者自己写的。
这就给了使用者一件别处没有的东西：一条可以直接引用的、来自发布方的性能落差数字。任何声称"我们的植物病害模型准确率 99%"的工作，都可以用这一条被追问一句——你的 99% 是在什么条件下得到的。
1.3 三十秒决策卡：你的处境对得上哪一行
左列写的是使用者的处境，右列是这份数据能给出的东西。对不上就往下看 §1.4。
| 你的处境 | PlantVillage 能帮你什么 |
|---|---|
| 刚接触农业图像分类，想要一份能半天跑通的语料 | 目录即标签，datasets 一行加载，官方划分现成 |
| 要训练一个能在手机上跑的超轻量病害识别模型 | 256 像素方形图天然适合小输入尺寸，类别数与常见移动端分类头匹配 |
| 要验证模型是否学到了"病斑形态"而不是"拍照条件" | 彩色、灰度、去背景三版本同源对齐，是天然的消融实验台 |
| 要写一篇跨域泛化论文，需要公认的源域 | 该领域最常用的源域，结果可比性最强 |
| 要给种植户做一个"拍照诊断"的产品原型 | 可以做原型，但必须先在任何一份田间数据上验证，否则不要给农户看 |
| 要研究背景偏倚、快捷学习这类方法论议题 | 已经有人用 8 像素角落实验把它做成了标准案例，可直接复现 |
| 要评估病害严重度、估计产量损失 | 给不了你，见下一节 |
1.4 不适合谁：明确划界比罗列优点更有用
如果你的需求是田间现场诊断，这份数据给不了你田间分布。它的全部图像都是离体单叶在纸面上拍的，没有遮挡、没有多叶重叠、没有逆光、没有土壤与杂草。拿它训练出的模型在真实手机拍摄场景下的性能，官方论文已经给出了下界量级：约 31%。要做田间诊断，请把 PlantDoc（2,598 张网络来源田间图，13 种作物）或 FieldPlant（从喀麦隆种植园实地拍摄）作为验证侧，PlantVillage 只能当预训练起点。
如果你的需求是病斑定位或面积测量，这份数据给不了你像素级标注。它有去背景版，但那只是把叶片与背景分开，不是把病斑标出来；叶片整体轮廓的掩膜也不随库发布。做检测需要另找带框的数据，做病斑分割需要自建标注。
如果你的需求是严重度分级、产量损失估计、施药决策，这份数据给不了你任何数量信息。它的标签只有"这是哪种病"，不含发病程度、病斑占比、病程阶段，也不含对应的产量数据。任何把分类结果直接换算成损失率的做法，都没有这份数据支撑。
如果你的需求是热带主粮的病害覆盖，这份数据给不了你。14 种作物里没有水稻、小麦、木薯、香蕉、咖啡，而这几种在很多发展中国家是主粮或主要经济作物。用这份数据训练出来的模型，对木薯花叶病、稻瘟病一无所知。
1.5 三个图像版本分别解决什么问题
| 版本 | 目录 | 处理方式 | 想回答的问题 | 官方论文结论 |
|---|---|---|---|---|
| 彩色版 | raw/color |
原始 RGB，统一缩放到 256×256 | 病斑颜色是否携带判别信息 | 表现最好 |
| 灰度版 | raw/grayscale |
去色 | 去掉颜色后还剩多少可判别性 | 略降，仍高于 98%（最佳配置） |
| 去背景版 | raw/segmented |
按 Lab 与 HSB 分量的明度、饱和度生成掩膜，分离叶片，顺带校正色偏 | 模型是否依赖背景 | 介于两者之间，仅比彩色低不到 1 个百分点 |
第三行是整份数据最容易被误读的一格。作者的用意是"如果去掉背景后性能不掉，说明模型没在偷看背景"。结果是性能几乎不掉——很多人由此得出"PlantVillage 没有背景偏倚"的结论。2022 年的偏倚研究把这层推论推翻了：去掉背景并不等于去掉偏倚，因为拍摄条件造成的色偏与模糊同样落在叶片本身上，见 §4。
§2 数据构成：五万四千张是怎么数出来的
2.1 规模、类别与作物三组数字
先把三组数字钉死，后面所有讨论都基于它们。
| 口径 | 图像数 | 类别数 | 作物数 | 说明 |
|---|---|---|---|---|
| 官方仓库 README 与论文 | 官方默认值 | 38 | 14 | 本文以此为准 |
| Meta-Album 整理页 | 54,305 | 38 | 14 | 比官方少一张，未说明来源 |
| 2022 年偏倚研究 | 同上 | 38 | 14 | 沿用上一行 |
上游 raw/color 目录当前计数 |
少两张 | 38 | 14 | 第三方重新打包时统计 |
| Kaggle 主流镜像 | 与上一行相同 | 38 | 14 | 目录清单合计 |
| Geetharamani 与 Arun Pandian 派生版 | 61,486 | 39 | 14 | 增补了一个"无叶背景"类并做了六种增强 |
差一到两张的原因没有官方说法。可能的解释是整理过程中剔除过损坏文件，也可能只是统计时点不同。差别不影响任何结论，但在做严格复现时必须在方法一节写明你用的是哪个数字，不要直接抄论文的 54,306 然后报一个本地 count 出来的 54,304。
2.2 作物清单：14 种，全是温带与亚热带常见作物
| 作物 | 类别数 | 病害类别 | 有无健康类 | 备注 |
|---|---|---|---|---|
| 苹果 Apple | 4 | 黑星病、黑腐病、雪松锈病 | 有 | 三类病害均在美国果园常见 |
| 蓝莓 Blueberry | 1 | — | 有 | 只有健康叶 |
| 樱桃 Cherry（含酸樱桃） | 2 | 白粉病 | 有 | 目录名带括号标注 |
| 玉米（玉蜀黍）Corn | 4 | 灰斑病、普通锈病、北方叶枯病 | 有 | 四类中有三类病害 |
| 葡萄 Grape | 4 | 黑腐病、埃斯卡病、叶枯病 | 有 | 埃斯卡病属真菌复合侵染 |
| 柑橘 Orange | 1 | 黄龙病（柑橘绿化病） | 无 | 目录名拼写为 Haunglongbing |
| 桃 Peach | 2 | 细菌性穿孔病 | 有 | 单一病害加健康 |
| 甜椒 Pepper, bell | 2 | 细菌性斑点病 | 有 | 区别于辣椒 |
| 马铃薯 Potato | 3 | 早疫病、晚疫病 | 有 | 两类病害均属重要减产病害 |
| 树莓 Raspberry | 1 | — | 有 | 只有健康叶 |
| 大豆 Soybean | 1 | — | 有 | 只有健康叶 |
| 南瓜 Squash | 1 | 白粉病 | 无 | 只有病害类 |
| 草莓 Strawberry | 2 | 叶焦病 | 有 | — |
| 番茄 Tomato | 9 | 细菌性斑点、早疫、晚疫、叶霉、斑枯、红蜘蛛、靶斑、黄化曲叶病毒、花叶病毒 | 有 | 类别最多，占全库三分之一强 |
读这张表要注意三点。一是四种作物（蓝莓、树莓、大豆、南瓜）完全没有病害类，柑橘与南瓜则完全没有健康类，这意味着"作物-健康"这种组合并非全覆盖，模型在部分作物上学不到健康参照。二是番茄一家的图像量占全库约三分之一，任何按类平均的指标都会被番茄主导。三是病害类型混杂：红蜘蛛是螨类害虫而非病原，把它当"病害"处理在分类学上不严谨，但在本数据集的标签体系里它就是一个类。
2.3 类别内部的样本分布：倾斜得比想象中厉害
| 类别 | 图像数 | 类别 | 图像数 |
|---|---|---|---|
| 番茄 黄化曲叶病毒 | 5,357 | 马铃薯 健康 | 一百五十余 |
| 柑橘 黄龙病 | 五千五百余 | 苹果 雪松锈病 | 275 |
| 大豆 健康 | 5,090 | 桃 健康 | 360 |
| 苹果 健康 | 1,645 | 树莓 健康 | 371 |
| 番茄 晚疫病 | 1,909 | 番茄 花叶病毒 | 373 |
| 葡萄 埃斯卡病 | 1,383 | 葡萄 健康 | 423 |
| 玉米 普通锈病 | 1,192 | 草莓 健康 | 456 |
最大类与最小类相差三十余倍。这个比例对损失函数设计有直接影响：不做类别加权时，模型会把大量健康叶误判为"某个病害"，而对少类病害的召回率会明显下降。反过来说，正因为样本量差异大，跨论文比较时才必须交代是否做了重采样——同一架构在不同处理下相差几个百分点是常事。
2.4 一份数据的三个版本与体积
| 版本 | 形式 | 处理 | 体积 |
|---|---|---|---|
| 彩色 | JPEG，256×256 RGB | 原样 | Kaggle 镜像显示 2.18 GB |
| 灰度 | JPEG，256×256 单通道 | 去饱和 | 约为彩色版的 1/3 |
| 去背景 | JPEG，256×256 RGB，背景置黑 | 掩膜分割 | 与彩色版同量级 |
官方没有给出完整三版本的总体积。Kaggle 页面上那个 2.18 GB 指的是 color 子目录，把它当作全库体积会低估三倍左右。按 256×256 的 JPEG 平均编码效率估算，单个版本落在 2 GB 上下是合理的，但这一条属于估算而非官方数字，规划存储时应以实际下载后的 du -sh 为准。
2.5 与同类资源的横向位置
| 资源 | 规模 | 采集条件 | 标注 | 与 PlantVillage 的关系 |
|---|---|---|---|---|
| PlantVillage | 五万四千余张 | 离体单叶、纸面底、受控光照 | 38 个作物-病害类 | 本体 |
| PlantDoc | 2,598 张 | 网络抓取的真实场景，背景杂乱 | 13 种作物、27 类 | 专为测 PlantVillage 的跨域短板而建 |
| FieldPlant | 5,170 张（8,629 个叶片标注） | 喀麦隆种植园实地拍摄 | 3 种热带作物、27 类 | 田间侧补位，含目标框 |
| 番茄病害竞赛集（2020 FGVC） | 三万余张 | 温室与田间混合 | 10 类 | 单作物深度集 |
| 乌干达木薯数据集 | 约一万五千张 | 田间手机拍摄 | 病害等级 | 热带主粮侧补位 |
一张表看下来，PlantVillage 的独特性反而清楚了：在所有这些资源里，只有它是严格控制变量、且控制了"作物-病害"全组合维度的一份。它的对手都不是它的替代品，而是它缺失的那一半。
§3 标签体系：目录即标签的代价
这一层回答的是"一张图到底被标成了什么"。这是三个层里的第一层，对应的是只想把数据跑起来的人。
3.1 命名规则与 38 个类名的构成
每一张图的标签唯一来自它所在的父目录名，格式是 作物___病害，中间三个下划线。例如 Tomato___Early_blight、Apple___Black_rot、Potato___healthy。这个设计让分类问题退化为"读目录"，成本极低，代价是标签的信息量也就只有这么多。
38 个类由 14 种作物与若干病害状态交叉得到。按病害类型粗分：真菌性病害约 17 类，细菌性病害 4 类，卵菌（霉）类 2 类，病毒性 2 类，螨类害虫 1 类，健康状态 12 类。这个 17/4/2/2/1/12 的构成在领域内被反复引用，是说明该库"真菌病害占绝对多数"的依据。
3.2 目录名里的三处不规整
| 位置 | 写法 | 问题 | 处理建议 |
|---|---|---|---|
| 柑橘黄龙病 | Orange___Haunglongbing_(Citrus_greening) |
Huanglongbing 拼成了 Haunglongbing | 建映射表时单独处理，不要做拼写模糊匹配 |
| 玉米 灰斑病 | Corn_(maize)___Cercospora_leaf_spot Gray_leaf_spot |
同一类里用空格分隔两个病名，且无下划线 | 用整串精确匹配做键，不要按下划线切分 |
| 玉米 普通锈病 | Corn_(maize)___Common_rust_ |
尾部多一个下划线 | 同上 |
这三处会让"按分隔符解析出作物名与病害名"的朴素写法出错。稳妥做法是维护一张显式的 38 行映射表，见附录 A。
3.3 标签的三个结构性局限
第一，标签是联合标签不是层级标签。Apple___Apple_scab 同时编码了作物与病害，但数据本身没有单独的作物字段；想只做作物分类，必须在解析阶段人为拆开，而拆开时又会遇到上面那三处不规整。
第二，没有严重度维度。严重的晚疫病叶与初期晚疫病叶落在同一个类里。模型学出来的是"这张叶子是不是晚疫病叶"，而不是"这张叶子病到什么程度"。
第三，没有不确定性表达。一张典型症状的叶子和一张处于病害边界的叶子，标签置信度相同。实际植保诊断里最难判的正是边界样本，这份数据把最难的部分整体跳过了。
3.4 一片叶子，不是一个样本
这是这份数据在结构上最重要、也最常被忽略的一点。
官方论文明确记录：库内许多图像来自同一片叶子的不同拍摄角度；这类对应关系在 41,112 张图上有记录（占全库约四分之三）。也就是说，五万四千张图背后对应的物理叶片数远少于五万四千。
这意味着按图像随机划分训练集与测试集时，同一片叶子的正面照可能在训练集、背面照在测试集。模型只要记住这片叶子的形状轮廓，就能在测试集上答对——它学到的不是病害判别力。
官方在论文里做了正确的事：所有划分都保证同一片叶子的所有图像落在同一侧。但这份映射关系只覆盖了约四分之三的图像，剩下四分之一无法做叶片级归组。后来 Hugging Face 侧发布的版本补上了 leaf_id 字段并按叶片分组生成固定的 80/20 划分，是目前工程上最省事的合规做法。
3.5 一个容易被忽视的事实：作物的地理代表性
14 种作物里，苹果、葡萄、樱桃、蓝莓、树莓、草莓、南瓜、甜椒、桃、玉米、大豆、马铃薯主要是北美与欧洲的种植结构，柑橘与番茄则分布更广。水稻、小麦、木薯、香蕉、咖啡、棉花、甘蔗这些在许多发展中国家占据主要种植面积或主要经济收入的作物，一份都没有。
这意味着用这份数据训练的"通用农作物病害诊断模型"，其"通用"二字的地理范围实际是有限的。把它拿到东南亚或西非的田里去，模型面对的第一批问题往往不是病害认不对，而是作物根本不认识。
§4 偏倚与 31%：这份数据最硬的边界
这一层回答的是"它可信吗、什么时候不可信"。对应的是需要判断这个模型能不能交付的人。这也是全文最需要认真读的一节。
4.1 官方自己写下的那次失败
先说一个贯穿全文的案例，它来自官方论文的讨论部分，不是后人的补充批评。
研究团队把训练好的模型拿去测两批从网络在线来源收集的真实图片：第一批 121 张，准确率 31.40%，前五命中率 52.89%；第二批 119 张，准确率 31.69%，前五命中率 65.61%。同期同在 PlantVillage 上的最好成绩是 99.35%。
这两百多张图后来成了这个领域最常被引用的一个数字来源。它之所以重要，是因为它出自发布方自己的论文，而且论文在结论里把原因写得很清楚：模型被限制在分类"单叶、正面朝上、背景均匀"的图像上。
用例拆开看，这条记录有四个信息点：一是落差幅度，从 99.35% 到 31.40%，接近七十个百分点；二是对比基准，38 类的随机猜测是 2.63%，31% 意味着远好于瞎猜但离可用差得远；三是前五命中率仍有 52.89%，说明模型抓住了一些相关内容，只是排序错了，这正好是"学到拍照条件"的典型表现；四是样本量，两百多张确实小，但方向性结论已经足够明确，后续多份独立工作给出的数字与之同量级。
4.2 8 个像素的判决：背景里到底藏了什么
2022 年的一项偏倚研究把这件事做到了极致。它从每张图的四个角与四条边的中点各取 1 个像素，共 8 个像素，构成一份只有背景的极简数据；然后用随机森林分类。合理预期是这份数据的准确率应该接近随机猜测。
结果：49.0%。38 类的随机基线是 2.6%。
作为对照，同样的操作用在手写数字集上，得到 11.7%，而手写数字集的随机基线是 10%——也就是说，同样的方法在背景真正干净的数据上确实退化到随机水平。这组对照让结论变得无法回避：PlantVillage 的纸面背景与拍摄条件里，携带了足以把准确率从 2.6% 抬到 49.0% 的类信息。
那 8 个像素占整张背景像素不到千分之一。信息浓度到这个地步，说明"这批叶子是在同一次拍摄里拍完的"这件事本身，就被编码进了光线、纸面材质与相机白平衡里。
4.3 去背景版为什么没有救回来
同一项研究继续追了一步：背景去掉之后呢？
结论是没救回来。原因是这份数据里的"偏倚"有两层：一层是背景层的，纸面颜色与光照；另一层是拍摄层的，即相机、镜头、曝光、白平衡、拍摄者习惯造成的整体成像特征。去掉背景只能消掉第一层，第二层的色偏与模糊大量保留在叶片本身。研究用模糊度作为拍摄条件的代理变量，分别在原图、前景图、背景图上建模，发现三者的可判别性都显著高于随机。
这就解释了一个看似矛盾的现象：官方论文里去背景后性能几乎不掉，于是很多人以为"没有偏倚"；真相是去背景只切掉了偏倚的一部分，而剩下那部分恰好是主因。
4.4 泄漏：比背景偏倚更隐蔽的那个坑
如果只做一件事来保证评测公正，应该是这一件：按叶片分组划分，而不是按图像随机划分。
原因很直接。同一片叶子被拍了多个角度、多张照片，这些图在视觉上高度相似。随机划分时，训练集里这片叶子的照片会让模型记住它的形状、叶脉走向、叶缘缺损的位置，测试集里同一片叶子的另一张照片就成了送分题。这时报出来的数字衡量的是"跨照片泛化"，不是"跨叶片泛化"，更不是"跨农场泛化"。
判断自己有没有踩坑，看数字的形态：如果按图像随机划分得到 99% 以上、按叶片分组划分掉到 95% 上下、跨作物换域掉到 70%、跨到田间数据掉到 30%，那么这四档数字真正说明问题的只有最后两档，前三档的差异主要来自记忆。
4.5 一份偏倚清单
| 偏倚类型 | 表现 | 影响 | 缓解办法 |
|---|---|---|---|
| 拍摄条件偏倚 | 同批相机与光照，8 像素即可判别 | 模型学到成像特征而非病斑 | 与多来源数据混训，做颜色抖动 |
| 背景偏倚 | 纸面颜色与类相关 | 去背景前尤其严重 | 使用去背景版（但见上一条） |
| 叶片分组泄漏 | 同叶多拍 | 随机划分虚高 | 用 leaf_id 分组划分 |
| 类别不平衡 | 最大类 5,507，最小类 152 | 少类召回差 | 加权损失或重采样 |
| 单叶构型 | 只有一片叶、正面朝上 | 无法处理多叶、遮挡、背面 | 做检测式预处理先裁出单叶 |
| 地理代表窄 | 缺热带主粮 | 对水稻木薯等无覆盖 | 外接田间数据 |
| 病害类型集中 | 真菌病害约 17 类 | 对细菌、病毒、虫害判别弱 | 引入对应数据集 |
4.6 交叉验证与外部验证的建议姿势
一个可用的最小协议是四层：第一层，按叶片分组在库内做 5 折，得到"跨叶片"基线；第二层，按作物留一法做 38 类的子集评估，看跨作物迁移能力；第三层，把 PlantDoc 作为目标域做零样本迁移，这一层会给出你真正关心的数字；第四层，如果条件允许，用手机在自己关注的作物上拍五十到一百张，人工标注后测一次。
只有第四层的数字可以拿给使用者看。前三层是给自己调模型用的。
§5 怎么拿到与怎么装载
这一层回答的是"工程上怎么把它搬进训练管线"。对应的是要落地的人。
5.1 四个入口的取舍
| 入口 | 形式 | 优点 | 缺点 |
|---|---|---|---|
| GitHub 仓库 | 目录即标签的原始 JPEG | 最接近原始发布物 | 仓库大、克隆慢、脚本是 Python 2 |
| Hugging Face | Parquet，三个配置 | 一行加载、带 leaf_id 与官方划分 |
依赖 datasets 库版本 |
| Kaggle 镜像 | 目录结构同 GitHub | 有现成 Notebook 生态 | 许可是 CC BY-NC-SA 4.0，与上游不一致 |
| Mendeley 派生版 | 六万余张、39 类 | 带增强版 | 不是同一发布物，类别多一个背景类 |
选 GitHib 或 Hugging Face，避开需要登录与许可存疑的镜像。Kaggle 那份虽然好用，但它把许可以更严格的非商业条款重新声明了一遍，在企业环境里引用会带来麻烦。
5.2 三个版本的加载
#-- 三个配置一一对应彩色、灰度、去背景
#-- split 用官方给的那份，已按 leaf_id 分组，不要自己再随机切
from datasets import load_dataset
for cfg in ("color", "grayscale", "segmented"):
ds = load_dataset("mohanty/PlantVillage", cfg)
print(cfg, ds["train"].num_rows, ds["test"].num_rows, ds["train"].features)
三行打印里最该看的是 num_rows。官方划分给的是训练四万三千余、测试一万余，两边加起来等于该配置的图像总数；如果某一配置的总和明显小于其他两个，说明该配置有图像缺失，需要回头核对版本。
5.3 验证叶片分组的完整性
#-- 直接验证：同一个 leaf_id 不该同时出现在 train 与 test
from datasets import load_dataset
ds = load_dataset("mohanty/PlantVillage", "color")
leaf_train = set(ds["train"]["leaf_id"])
leaf_test = set(ds["test"]["leaf_id"])
overlap = leaf_train & leaf_test
print("train 叶片数", len(leaf_train), "test 叶片数", len(leaf_test), "重叠", len(overlap))
assert not overlap, "存在跨集合的同一叶片，说明划分被改写或不尊重 leaf_id"
这段跑完如果重叠数为零，就可以放心用这份划分发论文；如果不为零，说明你用的镜像在打包时打乱了分组。
5.4 自己重做划分
#-- 需要自定义比例或折数时，只在 leaf_id 层面切，绝不在图像层面切
#-- 找不到 leaf_id 的少数图像（约占四分之一）单独归为不可分组，单独放一边
import numpy as np
from datasets import load_dataset, concatenate_datasets
ds = load_dataset("mohanty/PlantVillage", "color")
full = concatenate_datasets([ds["train"], ds["test"]])
leaves = sorted(set(full["leaf_id"]))
rng = np.random.default_rng(2026)
rng.shuffle(leaves)
cut = int(len(leaves) * 0.8)
train_leaves = set(leaves[:cut])
train = full.filter(lambda x: x["leaf_id"] in train_leaves)
test = full.filter(lambda x: x["leaf_id"] not in train_leaves)
print(len(train), len(test))
注意 default_rng(2026) 这一行：把种子写死，别人才能复现你的划分。留一法之类的交叉验证同样应在这个层面做，按折切 leaf_id 列表。
5.5 一个可运行的基线
#-- 最小可复现基线：冻结主干 + 线性头，十分钟内出结果
#-- 重点不在分数，而在于把"跨叶片"这一层基线立起来，作为后续跨域对比的锚点
import torch
from torch import nn
from torch.utils.data import DataLoader
from torchvision import models, transforms
from datasets import load_dataset
tf = transforms.Compose([
transforms.Resize((224, 224)),
transforms.ToTensor(),
transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]),
])
def collate(batch):
x = torch.stack([tf(b["image"].convert("RGB")) for b in batch])
y = torch.tensor([b["label"] for b in batch])
return x, y
ds = load_dataset("mohanty/PlantVillage", "color")
train_loader = DataLoader(ds["train"], batch_size=64, shuffle=True, collate_fn=collate)
test_loader = DataLoader(ds["test"], batch_size=128, collate_fn=collate)
net = models.resnet18(weights="IMAGENET1K_V1")
head = nn.Linear(net.fc.in_features, 38)
for p in net.parameters():
p.requires_grad = False
net.fc = head
opt = torch.optim.AdamW(head.parameters(), lr=1e-3)
loss_fn = nn.CrossEntropyLoss()
net.train()
for x, y in train_loader:
opt.zero_grad()
loss = loss_fn(net(x), y)
loss.backward()
opt.step()
net.eval()
correct = total = 0
with torch.no_grad():
for x, y in test_loader:
pred = net(x).argmax(1)
correct += (pred == y).sum().item()
total += y.numel()
print("acc", correct / total)
这段代码的预期结果会落在 95% 以上。它不说明模型好，只说明这份数据在实验室条件下确实容易。拿这个数字去和官方在受控条件下的高位成绩对比没有意义，架构不同、输入尺寸不同、划分口径也不同；它的用途是当锚点，后面每次改动都对着它看涨跌。
5.6 目录与文件命名的实际情况
PlantVillage-Dataset/
├── raw/
│ ├── color/
│ │ ├── Apple___Apple_scab/
│ │ │ ├── 0a5e4d7b-....JPG
│ │ │ └── ...
│ │ └── Tomato___Late_blight/
│ │ └── ...
│ ├── grayscale/
│ └── segmented/
├── leaf_grouping/ #-- 叶片分组元数据，映射到同一物理叶片
├── scripts/ #-- 数据生成脚本，Python 2 时代遗留
├── plant_village.py #-- Hugging Face 加载脚本
└── README.md
文件名是 UUID 加扩展名，不携带任何语义。唯一的语义在父目录名上。因此任何工程实现都必须假设"文件顺序不可依赖、文件名不含信息"，分类只读父目录。
5.7 训练配置的几条经验线
输入尺寸不要一味拉到 224。原始素材是 256 的方形图，病斑在缩小后细节损失明显，对早疫病这类小斑点的病，用 256 甚至不缩放往往比 224 好；但代价是显存与延迟上升。做移动端原型时，128 是一个常用的折中点，精度损失在新一代轻量主干上已经不大。
数据增强要克制。水平翻转、小角度旋转、亮度抖动是安全的；色调大幅偏移不安全，因为颜色是这份数据里病斑的主要判别线索，把色调抖狠了等于人为抹掉信号；随机裁剪不安全，叶缘经常是判别边界，裁掉可能改变标签含义。
批次与类别权重一并调。类别极不均衡的前提下，先加权重再调学习率，顺序反过来会浪费调参时间。
§6 与站内其他页面的关系
PlantVillage 是站内第一篇农业方向页面，因此它的互链更像是"为后来者占位"而不是"嵌入既成网络"。四组关系值得写下来。
第一组是方法论上的镜像：空气质量系统（AQS）处理的是"同一个指标在不同监测站之间如何可比"的问题，PlantVillage 处理的是"同一张叶在不同拍摄条件下如何不可比"的问题。两者都在做跨域，只是一个在空间上、一个在成像条件上。
第二组是物种与名称体系：物种出现记录库（GBIF）用学名把全世界的物种观测串起来；农作物病害标签同样是名称问题，但 PlantVillage 用的是俗名加目录名，没有接入任何学名或病害本体编码，这正是它较薄弱的一环，也是后续版本最该补的地方。
第三组是环境与宿主：城市微生物组（MetaSUB）测的是环境样本里的微生物构成，植物病原同样是微生物，但前者测序列、后者拍照片，两者在"如何从表象推断病原"这个问题上分属两端。
第四组是食物与供应链：食物成分库（USDA FoodData Central）记录作物收获之后的营养构成，PlantVillage 记录收获之前的病害状态，两者在"从田间到餐桌"的链条上首尾相接。
#-- 站内检索：按"农业 / 作物 / 叶片"等词找同类条目，用 slug 是否在架来确认
grep -iE "plant|agri|crop|leaf|farm|food|soil|pest" /tmp/online_slugs.txt
上面的检索在本站当前的在架清单里只命中少数几条（plantar 是足底压力，与植物无关），这本身就说明了覆盖缺口。农业方向真正需要补上的——作物基因组、土壤微生物、遥感农田、病虫害监测、农药登记——都还空着。
§7 质量评估：用 DAIMS 和一条域偏移标尺来量
7.0 读这一节之前要先放下的一件事
最常见的评价错位，是把 PlantVillage 当成"训练集"来打分。按训练集的标准，它的分数并不高：类别不平衡、标签粗、没有病斑级标注、没有划分文件（官方仓库层面）、没有田间覆盖。
正确的评价框架是把它当成基准与源域来打分。按这个框架，它几乎每一项都合格：规模够用、标签干净、三版本齐全、有官方定义的失败案例、有明确的适用范围。它不需要更大，它需要的是被正确地使用。
第二个常见的错位，是把"受控条件下的高准确率"当成"数据集质量高"的证据。两者没有关系。那个九成九的数字衡量的是数据集的易学程度，恰恰是它最大的短板所在。
7.1 DAIMS 24 项逐条
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 宽格式 | ✅ | 目录即标签，天然宽格式，无需透视 |
| 2 | 唯一标识 | ✅ | 文件名为 UUID，全库内不重复 |
| 3 | 特殊字符 | ⚠️ | 目录名含逗号、括号、空格、多余下划线，解析需显式映射 |
| 4 | 重复行 | ⚠️ | 同叶多拍在统计上是不同记录，但建模时属于近重复 |
| 5 | 缺失编码 | ❌ | 无缺失值机制，也没有"未知"类，未标注即不存在 |
| 6 | 标签标识 | ✅ | 38 类全覆盖，无歧义标签 |
| 7 | 罕见类分组 | ⚠️ | 最小类一百五十余张，未见官方分组建议 |
| 8 | 偏倚评估 | ⚠️ | 官方做了去背景消融，但未做拍摄条件偏倚的系统量化，后由第三方补上 |
| 9 | 数据字典 | ⚠️ | 官方无正式数据字典，字段含义需从目录结构推 |
| 10 | 信息性缺失解释 | ❌ | 无缺失值，也无可解释的信息性缺失设计 |
| 11 | 设备记录 | ❌ | 未发布相机型号、镜头、白平衡设置等采集设备元数据 |
| 12 | 共线性 | ⚠️ | 同叶多拍高度相关，构成隐式共线 |
| 13 | 编码映射 | ⚠️ | 无病害本体或编码体系映射，只有俗名 |
| 14 | 时间戳处理 | ❌ | 无图像级拍摄时间 |
| 15 | 划分建议 | ✅ | 官方论文给出叶片级分组划分原则，Hugging Face 侧已固化 |
| 16 | 泄漏讨论 | ✅ | 官方论文明确讨论同叶多拍的泄漏风险并做了处理 |
| 17 | 标签分布 | ✅ | 逐类计数可从目录得到，多个镜像已公布 |
| 18 | 测量偏倚 | ✅ | 官方与第三方均有量化，8 像素实验是标准案例 |
| 19 | 外部验证建议 | ✅ | 官方论文自带跨域测试并给出 31% 的下界 |
| 20 | 版本记录 | ⚠️ | 图像本体自 2016 年后未变，但派生版众多、版本边界模糊 |
| 21 | 预处理脚本 | ⚠️ | 官方提供脚本但为 Python 2 时代产物，路径硬编码 |
| 22 | 合规要求 | ⚠️ | 上游 CC BY-SA 3.0 与部分镜像的非商业条款不一致 |
| 23 | 多模态对齐 | ❌ | 纯图像，无文本、光谱或其他模态 |
| 24 | 去标识化 | ✅ | 不含人像与个人信息，无需去标识 |
DAIMS 评分：14.5 / 24。八项全绿是它的骨架：唯一标识、标签完备、泄漏讨论、偏倚量化、外部验证、划分建议这几项，很多规模大十倍的农业数据集都做不到。
剩下未达标的项集中在元数据层，尤其设备记录、时间戳、数据字典三项，直接导致"为什么 99% 在田里不成立"这个问题无法在数据内部被追溯——只能靠外部研究补。
对你意味着什么：如果你要做的是模型侧改进，这份数据的质量足够当源域，把力气花在跨域上；如果你要做的是数据侧改进，最值得做的一件事是补采集元数据，哪怕是事后回忆出的"这批是谁拍的、用什么拍的、哪个月"，也能让后续的偏倚校正少走很多弯路。
7.2 外部验证矩阵
| 验证方向 | 用什么数据 | 预期落差 | 说明 |
|---|---|---|---|
| 库内跨叶片 | 官方划分或自建叶片分组 | 很小 | 只衡量记忆 |
| 库内跨作物 | 按作物留一 | 中等 | 反映病害形态的作物特异性 |
| 跨域到网络田间图 | PlantDoc | 很大 | 已知落到三成量级 |
| 跨域到实地田间 | FieldPlant | 很大，含设备差异 | 还叠加了手机与相机差异 |
| 跨域到另一地区 | 自采 | 未知且通常最大 | 病害外观随气候与品系变化 |
7.3 许可口径的分歧
这是必须写清的一条。上游仓库 README 与官方 Hugging Face 加载脚本都声明 CC BY-SA 3.0。但 Kaggle 上流通最广的那份镜像标注的是 CC BY-NC-SA 4.0。两者一个是允许商用但要求同样方式共享，一个是禁止商用，冲突明显。
此外，部分第三方整理页把它的许可写成了 CC0。这个说法找不到上游依据。
实际做法：以 GitHub 仓库的声明为准，引用时写明 CC BY-SA 3.0 并给出仓库链接；如果要在企业产品里使用，先自行确认你下载的那个副本的声明，因为不同镜像的法律状态确实不同。这是这份数据在合规上最不干净的一处。
7.4 与库内其他"看起来干净"的数据集为何同病不同命
站内已有若干被反复批评"太干净"的数据集，比如标准化程度极高的影像库。它们的干净之所以没成为致命问题，是因为它们的应用现场本身也是标准化的：医院影像设备有协议、有质控、有固定的摆位。
PlantVillage 的干净之所以致命，是因为它的应用现场恰恰是最不标准化的：一个农户在田头用手机随手一拍，光线、角度、背景全都不受控。源域与目标域之间的标准化程度差异，是这个领域与医学影像领域最本质的区别，也是它必须单独成条的原因。
常见误读与避坑清单
下面每一条都对应一次真实的误解，左列是听过的说法，后面两列是能核对的依据。想省时间的话，只读关于去背景与划分的那两条也够。
| 常见说法 | 实际情况 | 证据 |
|---|---|---|
| “官方给的那个张数就是全部” | 至少还有两种差一两张的计数在流通，另有六万余张的派生版 | 官方 README 与论文一致；Meta-Album 与偏倚研究各少一张；第三方重打包再少一张 |
| “它是下地拍的照片” | 叶片是采下植株后放在纸面或塑料布上拍的，不是田间原位 | 偏倚研究对采集流程的描述；官方论文"受控条件"表述 |
| “去背景版就没有背景偏倚了” | 去背景只切掉纸面层，拍摄条件的色偏与模糊仍在叶片上 | 2022 年研究对前景与背景分别建模的结论 |
| “准确率 99% 说明模型可用” | 那个九成九是在受控条件下得到的，换到网络来源图像约 31% | 官方论文讨论部分的两组数字 |
| “有 38 类就是 38 种病害” | 38 是作物-病害联合类，病害本身 26 种，另有 12 个健康类 | 官方论文类目描述 |
| “每个作物都有健康类作对照” | 柑橘与南瓜没有健康类，蓝莓等四种作物没有病害类 | 38 类目录结构 |
| “按图像随机划分 80/20 就行” | 同叶多拍会造成泄漏，必须按叶片分组 | 官方论文对约四分之三图像做了叶片对应并据此划分 |
| “它是 CC0，随便用” | 上游声明为 CC BY-SA 3.0，要求署名并以相同方式共享 | 官方仓库 README 与 Hugging Face 加载脚本 |
| “它涵盖全球主要农作物” | 14 种里没有水稻、小麦、木薯、香蕉、咖啡 | 38 类目录结构 |
| “38 类里那些都是病害，没有虫” | 番茄红蜘蛛螨是螨类害虫，被作为一类收录 | 类名 Tomato___Spider_mites |
| “它是 Kaggle 上那个非商业数据集” | 上游为 CC BY-SA 3.0，Kaggle 镜像自行改成了非商业条款 | 两处许可声明原文 |
| “这份数据更新到最新版本了” | 图像本体自 2016 年后未变，更新的只是包装与入口 | 上游提交记录 |
十二条里，前六条关于数据本身，中间四条关于使用姿势，最后两条关于版本与合规。真正会让人做出错误决定的，是第三条与第七条：前者让人误以为偏倚已经解决，后者让人在不知情的情况下报出虚高的数字。
7.5 一个贯穿全文的对照：番茄晚疫病叶的两副面孔
把散在各节的事实收拢到一件事上，能看清这份数据的结构性问题。
类目录里的 Tomato___Late_blight 有一千九百余张图。这些图在训练与评测中有三个截然不同的身份。
第一副面孔，是在库内评测时。按官方划分测试，这一类的准确率通常在 0.95 以上。原因是同一片番茄叶被拍过多张，形状、叶脉、病斑的分布都在训练集里出现过，测试集只是同一批叶子的另一个角度。这一档数字衡量的是"跨照片记忆能力"。
第二副面孔，是在去背景实验里。有人会想，把背景去掉，模型就只剩病斑可看了，准确率该掉。事实是几乎不掉。这一档数字衡量的是两个变量的和：模型对病斑的判别力，以及被保留下来的拍摄条件信息。由于 §4.3 已证明后者占了很大一部分，这一档数字不能当作"模型看懂了病斑"的证据。
第三副面孔，是在田里。同样的模型面对手机在傍晚逆光下拍的一片病叶，准确率落到三成量级。叶面的湿度、反光、病虫并发、部分遮挡，都会把病斑的视觉特征打散。这一档数字才是部署时要面对的。
同一个类、同一个模型、三个数字。三者的差距来自一处：叶片从植株上被摘下、被平放在纸面上的那一刻。摘下来的动作同时消除了三件事——立体叶片的阴影、与周围叶片的层次关系、以及自然光的方向性。这三件事在田间诊断里恰恰是判断依据。
把这件事讲透，比记住任何单个数字都重要。它解释了为什么这份数据在论文里长盛不衰、在产品里寸步难行，也解释了为什么本篇既推荐它作为源域，又反复提醒不要拿它的准确率去说服任何人。
§8 版本、生态与它为什么还在被用
8.1 版本时间轴
| 时间 | 事件 | 影响 |
|---|---|---|
| 2015-11-25 | 预印本上线，宣布发布五万余张图像 | 首次公开，以"众包持续扩充"为口号 |
| 2016-04-12 | 预印本第二版 | 补充数据与平台描述 |
| 2016-09-01 | 正式论文发表于 Frontiers in Plant Science | 三版本、38 类、受控条件九成九与跨域三成量级一并公布，成为引用锚点 |
| 2016-08 起 | GitHub 仓库陆续整理提交 | 目录结构定型 |
| 2019-04 | Mendeley 出现六万余张、39 类的派生版 | 增补背景类与增强，与原始版分流 |
| 2020 | PlantDoc 发布 | 以田间网络图补位，成为标准的目标域 |
| 2022-06 | 偏倚量化研究预印本 | 8 像素实验，把"去背景等于去偏倚"推翻 |
| 2023 | FieldPlant 发布 | 提供真正的田间实地拍摄目标域 |
| 2026-02-05 | 上游仓库整理并接入 Hugging Face 链接 | 图像集未变，获取方式现代化 |
十年过去，图像本体几乎没动过。这是它一个尴尬又诚实的特点：作为"受控条件"的标本，它不需要更新，更新反而会破坏可比性。
8.2 生态位：源域而不是语料库
在今天的植物病害视觉研究里，PlantVillage 的位置可以用一句话概括：它是所有跨域实验的起点，不是任何实际部署的终点。
标准的实验章节写法已经固化成套路：先在 PlantVillage 上训，报一个高位数字；再迁移到 PlantDoc 或自采田间集，报一个低位数字；然后说我们的方法让低位数字提高了若干点。这个套路的合理性完全建立在 PlantVillage 数字的"虚高"是公认事实之上。如果哪天有人证明它的 99% 是真的可迁移的，这个套路就塌了。
正因如此，它的价值不在于被超越，而在于被引用。新数据集可以更大、更真，但很难替代它作为"实验室条件"这个参照点的作用。
8.3 它为什么能持续
一份十年不更新的数据集能持续被用，靠的不是维护，而是三件事同时成立。
第一，它是该领域第一份大规模公开集。先发优势在学术数据集上格外强，因为所有的后续比较都建立在它之上，替换成本极高。
第二，它的缺陷被官方自己写清楚了。31% 这个数字是作者写的，不是审稿人写的，也不是后人揭的。这反而让它变得可信：一份自己承认局限的数据，比一份只讲优点的数据更适合当基准。
第三，它成了教学入口。几乎每一份农业视觉的入门教程都以它为例，一代代学生从它开始，形成使用惯性。惯性在数据集生态里比技术优势更持久。
这三条加起来，形成了一种少见的状态：一份被广泛批评、又被广泛使用的数据。批评与使用并不矛盾，因为它们指向的是同一件事——它作为一个可复现的对照点，比作为一个可用的训练集更值钱。
8.4 近年是否有更新
图像本体没有更新。变化的只有包装：Hugging Face 侧提供了带 leaf_id 的 Parquet 版本与固定划分；上游仓库在 2026 年 2 月做了一次整理，把文档现代化并接入 Hugging Face 链接。
如果期待它变成"带田间数据的新版本"，那是不会发生的。带着田间数据的新资源不断出现（PlantDoc、FieldPlant 以及各类区域数据集），但它们都是独立的发布物，不是这份数据的续集。
§9 使用指引：三种角色的最短路径
9.1 学生与入门者
路径最短：用 Hugging Face 加载彩色配置，跑 §5.5 那段基线，得到 95% 以上的数字。然后把同一份代码换成去背景配置，看数字变化。最后加载 PlantDoc，用同一个模型零样本测一次。
第三步的数字会让你对整件事有全新的认识，也是这一步最值得花时间。不需要任何额外准备，一小时之内可以走完。
9.2 研究人员
要写跨域论文，源域就选它，但必须交代四件事：用的是哪个图像数口径、是否按叶片分组划分、用的是三个版本里的哪一个、目标域是什么以及目标域的采集条件。
这四件事不交代，审稿人一定会问。交代清楚了，即使结果平淡，方法学上也站得住。
9.3 工程与产品团队
如果目标是做一个可交付的植保应用，这份数据只能当预训练起点。可交付的最小路径是：先在 PlantVillage 上做预训练，再用自己目标作物的田间数据微调，最后在目标场景上独立测一次，并且只报最后一次的数字。
如果团队没有能力采集田间数据，那么结论应该是"现阶段不做这个应用"，而不是"用 PlantVillage 训一个模型上线"。后者导致的问题会由农户承担。
9.4 在 AI 流程中的位置
| 流程环节 | PlantVillage 的角色 | 替代或补充 |
|---|---|---|
| 预训练 | 源域，提供病害相关的基础纹理特征 | 也可用 ImageNet 或农业专用预训练权重 |
| 微调 | 用小目标域数据微调 | 需要目标域数据，本库无法替代 |
| 评测 | 只能作内部一致性检查 | 对外报数必须用田间数据 |
| 回归测试 | 可作"模型没坏"的冒烟测试 | 阈值应设为极高，因为它本来就容易 |
| 漂移监控 | 无作用 | 需生产环境真实样本 |
9.5 一个容易被遗忘的前置步骤
在把它接入任何管线之前，先跑一次类别计数。目录结构看起来规整，但不同来源的副本可能少了某一类的若干张，也可能多了增强图。跑一次计数、与附录 A 的表对一遍，五分钟的事，能避免后面所有的口径混乱。
§10 AI 使用声明
| 项目 | 内容 |
|---|---|
| 性质 | 本页面为数据集说明文献，非原始数据发布物 |
| 用途 | 帮助使用者判断这份数据是否适合自己的任务，以及如何在合规前提下使用 |
| 不建议用途 | 不可将本页任何描述作为植保诊断的临床或农艺依据；不可据本页的数字做产量预测 |
| 伦理 | 数据不含人像与个人信息；涉及农业生产的结论应向当地农技人员求证 |
| 引用 | 使用数据请引用 Mohanty、Hughes、Salathé 2016 年论文，见附录 E |
| 版本 | 截至 2026-10-29 上游图像集自 2016 年后未变，包装与托管方式有更新 |
| 状态 | 已核对官方仓库、官方论文、Hugging Face 模型卡与两份独立研究 |
附录 A 作物-病害类目全表
38 个类，按作物分组。图像数取自主流镜像的目录计数，与官方总数存在一到两张的差异，见 §2.1。
| # | 类目录名 | 作物 | 病害 | 图像数 |
|---|---|---|---|---|
| 1 | Apple___Apple_scab | 苹果 | 黑星病 | 630 |
| 2 | Apple___Black_rot | 苹果 | 黑腐病 | 621 |
| 3 | Apple___Cedar_apple_rust | 苹果 | 雪松锈病 | 275 |
| 4 | Apple___healthy | 苹果 | 健康 | 1,645 |
| 5 | Blueberry___healthy | 蓝莓 | 健康 | 1,502 |
| 6 | Cherry_(including_sour)___Powdery_mildew | 樱桃 | 白粉病 | 1,052 |
| 7 | Cherry_(including_sour)___healthy | 樱桃 | 健康 | 854 |
| 8 | Corn_(maize)___Cercospora_leaf_spot Gray_leaf_spot | 玉米 | 灰斑病 | 513 |
| 9 | Corn_(maize)__Common_rust | 玉米 | 普通锈病 | 1,192 |
| 10 | Corn_(maize)___Northern_Leaf_Blight | 玉米 | 北方叶枯病 | 985 |
| 11 | Corn_(maize)___healthy | 玉米 | 健康 | 1,162 |
| 12 | Grape___Black_rot | 葡萄 | 黑腐病 | 1,180 |
| 13 | Grape___Esca_(Black_Measles) | 葡萄 | 埃斯卡病 | 1,383 |
| 14 | Grape___Leaf_blight_(Isariopsis_Leaf_Spot) | 葡萄 | 叶枯病 | 1,076 |
| 15 | Grape___healthy | 葡萄 | 健康 | 423 |
| 16 | Orange___Haunglongbing_(Citrus_greening) | 柑橘 | 黄龙病 | 5,507 |
| 17 | Peach___Bacterial_spot | 桃 | 细菌性穿孔病 | 2,297 |
| 18 | Peach___healthy | 桃 | 健康 | 360 |
| 19 | Pepper,_bell___Bacterial_spot | 甜椒 | 细菌性斑点病 | 997 |
| 20 | Pepper,_bell___healthy | 甜椒 | 健康 | 1,478 |
| 21 | Potato___Early_blight | 马铃薯 | 早疫病 | 一千 |
| 22 | Potato___Late_blight | 马铃薯 | 晚疫病 | 一千 |
| 23 | Potato___healthy | 马铃薯 | 健康 | 152 |
| 24 | Raspberry___healthy | 树莓 | 健康 | 371 |
| 25 | Soybean___healthy | 大豆 | 健康 | 5,090 |
| 26 | Squash___Powdery_mildew | 南瓜 | 白粉病 | 1,835 |
| 27 | Strawberry___Leaf_scorch | 草莓 | 叶焦病 | 1,109 |
| 28 | Strawberry___healthy | 草莓 | 健康 | 456 |
| 29 | Tomato___Bacterial_spot | 番茄 | 细菌性斑点病 | 2,127 |
| 30 | Tomato___Early_blight | 番茄 | 早疫病 | 一千 |
| 31 | Tomato___Late_blight | 番茄 | 晚疫病 | 1,909 |
| 32 | Tomato___Leaf_Mold | 番茄 | 叶霉病 | 952 |
| 33 | Tomato___Septoria_leaf_spot | 番茄 | 斑枯病 | 1,771 |
| 34 | Tomato___Spider_mites Two-spotted_spider_mite | 番茄 | 红蜘蛛螨 | 1,676 |
| 35 | Tomato___Target_Spot | 番茄 | 靶斑病 | 1,404 |
| 36 | Tomato___Tomato_Yellow_Leaf_Curl_Virus | 番茄 | 黄化曲叶病毒 | 5,357 |
| 37 | Tomato___Tomato_mosaic_virus | 番茄 | 花叶病毒 | 373 |
| 38 | Tomato___healthy | 番茄 | 健康 | 1,591 |
表内最后一列合计约五万四千三百张，与官方口径差一张，属于镜像层面的统计差。
附录 B 目录与文件命名速查
| 项目 | 规则 | 例 |
|---|---|---|
| 顶层目录 | raw/color、raw/grayscale、raw/segmented |
raw/color |
| 类目录 | 作物___病害，三下划线 |
Tomato___Late_blight |
| 文件 | UUID + .JPG 或 .jpg |
0a5e4d7b-....JPG |
| 分组元数据 | leaf_grouping/ 下按类的映射表 |
同叶多拍归组 |
| 加载脚本 | plant_village.py |
供 Hugging Face 使用 |
| 划分比例 | 80/20，按叶片分组 | 官方推荐 |
注意扩展名大小写在不同副本里不统一，做 glob 时应同时匹配 .JPG 与 .jpg。
附录 C 术语表
| 术语 | 含义 |
|---|---|
| 作物-病害类 | 本库的标签粒度，一个类同时编码作物与病害状态 |
| 离体拍摄 | 把叶片从植株上采下后拍摄，与田间原位拍摄相对 |
| 背景偏倚 | 背景颜色与光照本身携带类别信息，模型可绕过叶片直接判类 |
| 拍摄条件偏倚 | 相机、曝光、白平衡等成像特征造成的偏倚，去除背景后仍存在 |
| 叶片分组 | 把同一物理叶片的全部图像归为一组，划分时整组进同一侧 |
| 泄漏 | 训练集与测试集含有同一实体的近重复样本，导致指标虚高 |
| 去背景版 | 用色彩分量生成掩膜把叶片与背景分离后的图像版本 |
| 跨域 | 训练与测试数据来自不同采集条件或环境 |
| 零样本迁移 | 不在目标域训练，直接评测模型在目标域的表现 |
| 快捷学习 | 模型利用与任务无关的捷径特征（如背景）达成高准确率 |
附录 D 常见问题
Q1：为什么官方说五万多张，我数出来是五万四千三百零几张？
因为不同副本在整理过程中处理过极少量文件，差异在一到两张，不影响任何结论。引用时交代用的是哪个数字即可。
Q2：去背景版能不能直接当"无偏倚"数据用？
不能。它只去掉了纸面背景，相机与光照造成的色偏、模糊仍留在叶片上。已有研究证明这类拍摄条件偏倚足以撑起四成以上的准确率。
Q3：能不能用它训练一个给农户用的 App？
可以当预训练起点，不能当最终模型。必须用目标作物的田间数据微调并在真实场景独立评测，否则上线后的表现会接近论文里那个三成量级的数字。
Q4：为什么它有 38 类，别人却说 26 种病害？
38 是作物-病害联合类，其中 26 类对应具体病害，其余 12 类是健康状态。两个数字都对，指的东西不同。
Q5：番茄红蜘蛛螨算病害吗？
严格说不算，它是螨类害虫造成的伤害。但在本库的标签体系里被作为一类收录，做分类时按标签处理，做病理学表述时应说清楚。
Q6：Mendeley 上那份六万多张的是不是同一份？
不是。那是 Geetharamani 与 Arun Pandian 在原始版基础上增补了"无叶背景"类并做六种增强后的派生版，规模与类别数都不同，引用时不要混用。
Q7：许可到底是 CC BY-SA 还是 CC BY-NC-SA？
上游仓库声明 CC BY-SA 3.0，部分镜像另行声明 CC BY-NC-SA 4.0。以你实际下载的那个副本的声明为准，若用于商业场景应先自行确认。
Q8：有没有官方划分文件？
上游仓库层面没有。Hugging Face 版本提供了按叶片分组的固定 80/20 划分，是目前最省事的合规做法。
Q9：它和 PlantDoc 是什么关系？
PlantDoc 是为测它的跨域短板而建的田间网络图数据集。两者常配对使用，一个当源域，一个当目标域。
Q10：为什么这份数据十年不更新还能用？
因为它作为"受控条件"的参照点，价值在于稳定而不在于更新。更新反而会破坏跨论文的可比性。
附录 E 许可与引用
官方声明为 CC BY-SA 3.0：允许复制、分发、改编，包括商业用途，但必须署名，且改编后的作品须以相同许可发布。这一条对派生数据集与产品有实质影响——如果你在它上面做了数据增强后重新发布，那份增强数据也需要以相同许可开放。
#-- 图像集对应的正式论文，引用这份数据时引它
@article{Mohanty_Hughes_Salathé_2016,
title = {Using deep learning for image-based plant disease detection},
volume = {7},
DOI = {10.3389/fpls.2016.01419},
journal = {Frontiers in Plant Science},
author = {Mohanty, Sharada P. and Hughes, David P. and Salathé, Marcel},
year = {2016},
month = {Sep}
}
#-- 数据集发布公告，谈论来源与初衷时引它
@misc{hughes2015plantvillage,
title = {An open access repository of images on plant health to enable the development of mobile disease diagnostics},
author = {Hughes, David P. and Salathé, Marcel},
year = {2015},
eprint = {1511.08060},
archivePrefix = {arXiv}
}
#-- 若引用本文关于偏倚量化的结论，应同时引这项研究
@misc{mehrabi2022uncovering,
title = {Uncovering bias in the PlantVillage dataset},
author = {Mehrabi, Mohammad and others},
year = {2022},
eprint = {2206.04374},
archivePrefix = {arXiv}
}
编辑说明
核验时点：2026-10-29。
核验方式：规模、类别、作物数与三个版本的描述，回溯上游仓库 README、Frontiers in Plant Science 论文正文与 Hugging Face 模型卡三处；31% 与 99.35% 两个数字取自论文摘要与讨论部分原文；8 像素实验的四组数字取自偏倚研究的方法与结果章节；许可分歧对照上游 README、Hugging Face 加载脚本与 Kaggle 镜像三处声明；逐类图像数取自 Kaggle 镜像的目录清单。
双口径并存项：图像总数官方口径为五万四千三百零六，镜像与第三方整理分别记为少两张与少一张，正文一律用官方数并注明差异；许可 CC BY-SA 3.0（上游）与 CC BY-NC-SA 4.0（部分镜像）并列，不合并表述；38 类与 26 种病害分列，明确二者不是同一量。
未覆盖内容：完整三版本总体积官方未公布，正文不给估算总数；原始分辨率分布、相机型号与拍摄时间未发布，因此无法做设备级偏倚追溯；去背景脚本的逐类效果未量化，正文不推断；官方未提供划分文件，正文所述划分以 Hugging Face 版本为准并标明来源。
体例说明：本页按 v5 体例撰写，§1–§10 连续编号，术语与常见问题集中在附录 C 与 D，事实清单与许可引用集中在附录 E。页面由千方医数集编辑部撰写，最终以数据库记录为准。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- covidx-cxr — 共享标签：图像分类 / 评测基准 / 医学影像 / 公共卫生与流行病学
- mbrset — 共享标签：图像分类 / 评测基准 / 医学影像 / 公共卫生与流行病学
- tcm-tongue — 共享标签：图像分类 / 评测基准 / 医学影像 / 公共卫生与流行病学
- oppd — 共享标签：图像分类 / 评测基准 / 公共卫生与流行病学
- chula-parasitic-egg — 共享标签：图像分类 / 医学影像 / 公共卫生与流行病学
- acevedo-blood — 共享标签：图像分类 / 评测基准 / 医学影像
- bbbc051 — 共享标签：图像分类 / 评测基准 / 医学影像
- limuc — 共享标签：图像分类 / 评测基准 / 医学影像
- tn3k — 共享标签：图像分类 / 评测基准 / 医学影像
- tmed2 — 共享标签：图像分类 / 评测基准 / 医学影像
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
