简介Deep-Leafsnap-master.zip 是一份基于 Python 与深度学习的植物叶片识别系统源码包面向具备一定 Python 基础、希望入门或进阶图像分类与迁移学习的开发者。项目利用 CNN 模型分析叶片图像特征涵盖数据读取、模型构建、训练与测试等流程适合用于植物学相关科研、教学演示和爱好者实践。压缩包共 13 个文件以 9 个 Python 脚本为核心覆盖数据集加载、ResNet/DenseNet/VGG 等网络结构定义、训练工具与测试模块另有 CSV 标签数据、requirements 依赖清单、说明文档及配置文件便于快速搭建可复现环境。包体仅 327KB结构紧凑已有 364 人学习浏览。通过运行该项目可以掌握 Keras/TensorFlow 实现植物叶片识别的完整链路并了解 OpenCV、PIL 的图像预处理技巧以及 Scikit-learn 在数据评估中的应用还可用自己的叶片数据替换训练集进行迁移学习是一份适合动手实践的深度学习入门范例。1. Deep-Leafsnap 到底能干什么一个不做训练也能复现的植物叶片识别项目做图像识别的同行应该都有过这种经历模型精度刷不上去老板说换个数据集试试结果光是数据标注就耗掉两周。Deep-Leafsnap 这个项目我第一次跑通时最大的感受是——终于有个不用自己从头训练 CNN拿来就能跑出结果的完整方案了。它基于 Caffe 框架和 GoogLeNet 模型针对 186 种植物叶片做分类识别整个代码包从数据加载、模型预测到结果展示是闭环的不需要你额外配数据库、也不需要自己准备训练集。对这个项目感兴趣的人群大概分三类做毕业设计要交植物识别系统的学生想快速体验深度学习推理全流程的入门开发者以及想拿现有模型做迁移学习、但不想碰复杂工程配置的算法工程师。不管你是哪一类这个 zip 解压之后能跑通的概率都不低因为它依赖的 Python 代码路径短、依赖少唯一的门槛反而是环境版本之间的兼容问题。下面我从工程结构和代码逻辑说起把整个识别链路掰开讲清楚。2. 工程结构拆解先把黑匣子的骨架看清楚2.1 解压之后的目录到底在组织什么Deep-Leafsnap-master.zip 解压之后你会看到一组典型的 Caffe 工程文件。我第一次打开时最困惑的是它没有 src 和 models 那样的大目录分类而是把所有推理要用的东西散在根目录和几个子目录里。这里我建议你先别急着跑代码花五分钟把每个文件的功能对上号后面调试会省很多时间。最常见的做法是先把文件按四类归组第一类是模型定义文件包括 deploy.prototxt 和对应的 caffemodel 权重文件这两者是推理的核心第二类是输入预处理相关比如均值文件 mean.binaryproto它负责把图片像素值做归一化第三类是 Python 脚本包括加载模型、读取图片、执行预测的主脚本第四类是辅助资源比如类别标签文件 labels.txt 和示例测试图片。Deep-Leafsnap-master/ ├── deploy.prototxt # GoogLeNet 网络结构定义推理模式 ├── leafsnap.caffemodel # 预训练权重186类叶片分类 ├── mean.binaryproto # 训练集的图像均值做减均值预处理 ├── labels.txt # 类别索引到植物名称的映射 ├── classify.py # 主推理脚本 └── images/ # 存放待测试的叶片图片提示如果你拿到的压缩包没有 labels.txt别慌类别名通常直接写在 predict 输出里只是映射方式不同。deploy.prototxt 和训练用的 train_val.prototxt 最大的差别在于deploy 版本去掉了 Loss 层和 Accuracy 层保留了从数据输入到 Softmax 输出的完整前向通路。想做二次开发的话改的是 deploy.prototxt 的输入尺寸或者输出维度而不是去动 weights 文件。2.2 推理链路中每个文件存在的理由很多新手有个误解觉得有了 caffemodel 就够了其他文件都是多余的。实际跑一次就知道缺哪一个都跑不出正确结果。caffemodel 里存的是卷积层、池化层、全连接层的权重数值但网络层与层之间怎么连接、每层用什么参数这些结构信息是在 prototxt 里定义的。Caffe 推理时必须把结构文件和权重文件同时加载二者缺一不可。mean.binaryproto 则对应训练时的数据增强策略。GoogLeNet 在 ImageNet 上训练时输入图片会先缩放到 256×256然后中心裁剪到 224×224再减去整个训练集的 RGB 三通道均值。如果你跳过减均值的步骤输入分布和训练时的分布不一致Softmax 输出的概率会明显偏低且分类置信度混乱。labels.txt 的作用是把 Softmax 输出的 186 维向量里的最大索引映射成具体的植物名称。比如索引 57 对应的是某个科的某个种没有这个映射文件你拿到的只是一堆浮点数。整个推理链路的数据流是原始图片 → resize → 减均值 → 网络前向计算 → Softmax → 取最大值索引 → 查 labels → 输出植物名称和置信度。下面这张表格把每个环节的输入输出对应起来。环节输入处理输出预处理JPEG 图片任意尺寸OpenCV 读取并缩放224×224×3 的 float 数组减均值224×224×3 数组减去 mean.binaryproto 中的均值归一化后的 blob前向计算blobGoogLeNet 多层级联卷积186 维概率向量结果映射186 维向量取 argmax植物名称与置信度3. 核心代码逻辑把 Python 推理脚本一行行看明白3.1 模型加载和预处理为什么这么写Deep-Leafsnap 的推理脚本核心很短通常几十行就能跑完。但如果直接复制到自己的项目里大概率会遇到图片读入格式不对、blob 形状不匹配、输出维度解析错误这三个问题。先看模型加载部分。import caffe import numpy as np # 设置网络结构文件和权重文件路径 net caffe.Net(deploy.prototxt, leafsnap.caffemodel, caffe.TEST) # 指定使用 CPU 还是 GPU 推理 caffe.set_mode_cpu()这里的关键点在于 caffe.Net 的第二个参数传的是 caffemodel 路径第三个参数 caffe.TEST 表示加载推理模式。如果你在训练模式加载 deploy 网络会有层缺失报错。caffe.set_mode_cpu() 在没有 NVIDIA 显卡的机器上是必须的否则会直接抛出 CaffeError。接下来是图片读取和预处理。Caffe 的 Python 接口不直接接受 PIL 图像要用 OpenCV 转成 BGR 顺序的 ndarray。import cv2 # 读取图片OpenCV 默认输出 BGR 格式 img cv2.imread(images/sample_leaf.jpg) img cv2.resize(img, (256, 256)) # 中心裁剪到 224x224 crop img[16:240, 16:240] # 转换为 float 并调整维度顺序为 (1, 3, 224, 224) crop crop.astype(np.float32) crop crop.transpose((2, 0, 1)) crop crop[np.newaxis, :, :, :]注意GoogLeNet 训练时用的是中心裁剪策略而不是直接 resize 到 224×224。直接 resize 会把叶片边缘拉变形识别精度会掉。代码里的 16 这个数字来自 (256-224)/2。如果你改成了其他缩放尺寸裁剪起点也要相应调整。transpose 的作用是把 HWC 格式转成 CHW因为 Caffe 的 blob 维度顺序是 (batch, channel, height, width)。3.2 减均值和前向推理的完整姿势均值文件 mean.binaryproto 在 Python 中需要用 caffe.io.blobproto_to_array 解析成数组才能做减法。这也是一部分人脸图片识别不出结果的常见原因——均值格式用错了。# 加载 mean.binaryproto 并解析成数组 blob caffe.proto.caffe_pb2.BlobProto() with open(mean.binaryproto, rb) as f: blob.ParseFromString(f.read()) mean_array caffe.io.blobproto_to_array(blob) # 输出形状是 (1, 3, 256, 256)需要 squeeze 去掉 batch 维 mean mean_array.squeeze() # 减均值crop 的形状是 (1, 3, 224, 224) # mean 的形状是 (3, 224, 224)可以广播 crop - meanmean.binaryproto 里存储的均值尺寸对应训练时的缩放尺寸也就是 256×256。所以这里不能直接用 caffe.io.resize_image 之类的操作去改均值尺寸。如果你的测试流程里图片缩放尺寸换了减均值时的形状也必须保持一致。前向推理部分更简单但有一个细节——GoogLeNet 的输出层名不是默认的 softmax而是 prob。# 把预处理后的图像数据送入网络 net.blobs[data].data[...] crop # 执行一次前向推理 output net.forward() # 取出 prob 层的输出186 维向量 prob output[prob][0] # 获取最大概率的类别索引 idx np.argmax(prob) # 从 labels.txt 读取对应的植物名称 with open(labels.txt, r, encodingutf-8) as f: labels [line.strip() for line in f.readlines()] print(识别结果:, labels[idx], 置信度:, prob[idx])prob 的 shape 是 (1, 186)取 [0] 拿到的是 186 维的向量。如果你的网络在最后一层改成了 SoftmaxWithLoss那么输出名就不是 prob需要在加载网络后先用 net.blobs.keys() 看一下可用的顶层 blob 名称。3.3 一次完整运行需要的最小参数约定把上面的逻辑拼成一个完整的 classify.py 后你会发现真正需要调的就四个参数模型结构路径、权重路径、均值路径、待测图片路径。我建议把这四个路径全部用命令行参数的形式暴露出来而不是硬编码在脚本里。这样批量测试图片时不用每次改代码。参数取值约定出错时的典型现象deploy.prototxt推理模式版本加载报错 Missing blamecaffemodel与 prototxt 匹配层名称或维度不匹配报错mean.binaryproto与训练尺寸一致减均值向量形状不匹配输入图片RGB 任意格式BGR 通道序错误导致色偏这组参数约定同时也是排查问题的索引。模型加载失败先看权重和结构是否匹配输出置信度普遍低于 0.3优先怀疑减均值或通道顺序问题个别类别总是识别错再看 labels.txt 的索引是不是从 0 开始对应。4. 从零复现这套识别流程环境配置与运行步骤4.1 Caffe 环境在 Windows 和 Linux 下的搭建差异Deep-Leafsnap 是一个 Caffe 项目但很多人习惯在 Python 的虚拟环境里跑这就有一个现实问题Caffe 的 Python 接口不能直接用 pip 安装必须自己编译或者找预编译版本。在 Linux 下相对简单源码编译时只需要在 Makefile.config 里打开 Python 层的开关然后把 caffe 目录加入 PYTHONPATH 即可。Windows 环境下则不太建议从源码编译 Caffe因为依赖项太多尤其是 cuDNN 和 OpenBLAS 的版本组合很容易出问题。常见做法是找社区预编译的 caffe 版本比如 caffe-windows 的 release 包或者直接用支持 CPU 推理的二进制包。编译时需要注意的配置项包括# Makefile.config 中关键选项 CPU_ONLY : 1 # 如果没有 NVIDIA GPU 则必须打开 PYTHON_INCLUDE : /usr/include/python3.6m WITH_PYTHON_LAYER : 1CPU_ONLY 这个开关对 Deep-Leafsnap 的影响很大。GoogLeNet 模型在 CPU 上推理一张 224×224 的图片大约需要几百毫秒到一秒左右完全在可用范围内。但如果你误开了 GPU 模式又没有显卡程序会直接崩溃报错信息是 Check failed: error cudaSuccess (2 vs. 0)。4.2 配置好环境后的运行步骤假设你的 Caffe 已经编译完成Python 接口可以正常 import caffe 了。接下来就是标准的运行流程。第一步把 Deep-Leafsnap-master 解压到一个没有中文和空格的路径下。Caffe 的 Python 接口在读取 prototxt 时对路径中的中文支持很差经常会报 file not found 或者编码错误。cd /home/user/Deep-Leafsnap-master # 设置 PYTHONPATH 指向 caffe 的 python 目录 export PYTHONPATH/path/to/caffe/python:$PYTHONPATH第二步确认 deploy.prototxt 中的输入层尺寸是 224×224。有的版本默认写的是 256导致后续图片输入维度不匹配。检查方式是用 grep 找 input_dim。grep -n input_dim deploy.prototxt # 期望看到两行 224 和两行 1第三步运行 classify.py 测试默认图片。python classify.py --image images/sample_leaf.jpg如果输出结果里出现了植物名称和置信度说明链路已通。接下来再换自己拍的图片时只需要保持叶片在画面中心、背景尽量干净即可。4.3 跑通后如何验证结果不是偶然的运气一次成功有可能只是因为这张测试图和训练集里的样本太像了。要判断整个流程是否真的可用批量测试是必须的。这里给一个简单的批量验证脚本思路把你手头已经标注好的叶片图片放到一个目录下脚本循环执行推理同时统计 Top-1 准确率。import os import numpy as np result_dir test_images correct 0 total 0 for img_name in os.listdir(result_dir): if not img_name.endswith(.jpg): continue # 真实标签从文件名中解析例如 Quercus_rubra_01.jpg true_label img_name.rsplit(_, 1)[0].replace(_, ) # 执行 3.2 中的推理流程得到 pred_label pred_label classify(img_name) total 1 if pred_label true_label: correct 1 print(Top-1 准确率:, correct / total)建议至少测试 30 张以上与训练集不同来源的图片。如果准确率维持在 60% 以上这个识别链路在你自己数据集上的可用性就比较可信了。如果某个类别的图片几乎全错大概率是该类别在训练样本中数量偏少这也侧面反映了原始数据集的分布局限。5. 避坑指南识别项目最常见的五个翻车点5.1 现象加载 caffemodel 时报错 weight shape mismatch刚拿到压缩包直接跑最常见的一个报错是类似 Check failed: blob.count() num (某数字 vs 某数字) 的信息。这种形状不匹配问题的原因几乎都是 deploy.prototxt 与 caffemodel 不是同一套模型产物。网上传播的 Deep-Leafsnap 压缩包版本很杂有的包的 prototxt 是 GoogLeNet 原始版本而 caffemodel 可能来自微调后的分支。解决方法是先检查 prototxt 里最后一个全连接层的 num_output 是不是 186。如果不是要么改成 186要么只能找配套的权重文件。改完 prototxt 后需要重新确认前面卷积层的层名称是否与权重一致。5.2 现象输出类别概率很低都在 0.1 左右有时候推理能跑完但所有类别的概率都很平均最高的也不超过 0.2。这基本可以确定是输入图像的分布和训练集不一致。第一个嫌疑是减均值步骤被跳过了或者均值数组的形状不对。第二个嫌疑是图片通道顺序弄反了。OpenCV 读进来的图像是 BGR 顺序而 Caffe 训练时的图像是 RGB 顺序。如果你只做了 resize 和减均值没有做通道转换网络看到的是颜色反转的图像。修复方式是在读图后执行img cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。这个错误非常隐蔽因为叶片图像颜色偏绿色通道反转后视觉上差别不大但神经网络的特征分布完全改变了。5.3 现象classify.py 运行到 net.forward() 时内存暴涨GoogLeNet 的推理显存占用在 GPU 上大概 400MB 左右但在 CPU 模式下有些机器会遇到内存占用异常飙升到 4GB 以上的情况。原因是 prototxt 中的 batch_size 被调大了而且 CPU 模式下 Caffe 会用非最优的内存分配策略。解决方法是把 deploy.prototxt 第一层 data 的 batch_size 设为 1。一般来说推理模式的 batch_size 固定为 1 就够了不需要为了吞吐量调大除非你确认内存完全吃得住。5.4 现象图像尺寸和裁剪导致识别结果偏移前面提到过 GoogLeNet 的标准输入是中心裁剪后的 224×224。如果你直接把一张 1920×1080 的叶片照片 resize 成 224×224叶片比例被严重压缩识别结果大概率是错的。这个问题的本质是训练数据里的图像都是叶片占画面主要区域而你的测试图可能叶片很小、背景占比大。解决方式是把测试图片先做一次简单分割或手动裁剪让叶片区域占画面 70% 以上再送入识别流程。批量测试时最稳的做法是统一用 256×256 的 resize 加中心裁剪保持与训练时的预处理完全一致。5.5 现象labels.txt 的排序和概率索引对不上最后输出阶段probability 最高的索引对应的名称和实际叶片不符这种事也不少见。原因在于 labels.txt 的行序要和训练时类别 ID 的排序一致。有些版本的标签文件是按字母序排的有的是按训练集目录顺序排的。验证方法是找一张你确定类别的图片跑一遍看输出索引和 labels 该行的内容是否对应。如果发现所有结果都错位固定位数直接用 Python 脚本调整 labels 文件的行序即可。6. 把 Deep-Leafsnap 改造成自己的分类器fine-tune 的实用技巧前面几章的内容都是在现有模型上做推理。如果你不满足于 186 类想把它改成识别自己采集的 20 类或者 50 类植物叶片那就得动 fine-tune。这一步的访问路径不复杂但有三个细节值得认真处理。首先是数据组织。Caffe 的 fine-tune 通常用 LMDB 或 LevelDB 格式的数据库作为输入。你手头的图片要先按类别放入不同目录然后写脚本统一缩放到 256×256、按 8:2 划分训练和验证集再转换成 LMDB。检查一遍数据集的类别平衡性如果有的类别只有 10 张图而有的类别有 200 张训练出来的模型几乎必然对样本多的类别过拟合。import lmdb import caffe import numpy as np import cv2 import os # 创建 LMDB 数据库 env lmdb.open(leaf_lmdb, map_size1024*1024*1024) # 遍历所有类别目录 class_names sorted(os.listdir(leaves_data)) with env.begin(writeTrue) as txn: idx 0 for cls_id, cls_name in enumerate(class_names): img_dir os.path.join(leaves_data, cls_name) for img_name in os.listdir(img_dir): img cv2.imread(os.path.join(img_dir, img_name)) img cv2.resize(img, (256, 256)) # 转换为 Caffe 的 Datum 格式 datum caffe.io.array_to_datum( img.transpose((2, 0, 1)).astype(np.uint8), cls_id) txn.put(f{idx:08d}.encode(ascii), datum.SerializeToString()) idx 1注意array_to_datum 接受的数组必须是 CHW 顺序且类型为 uint8这里直接对 OpenCV 读入的 BGR 图像做 transpose 即可不需要转 RGB因为 Caffe 训练时会把数据当作 BGR 处理。第二步是修改 train_val.prototxt 的最后两层。最后一层全连接层的 num_output 从 186 改成你的类别数fine-tuning 通常把这一层的学习率调成其他层的 10 倍让随机初始化后新增的层更快收敛。layer { name: fc8 type: InnerProduct bottom: pool5 top: fc8 param { lr_mult: 10 } param { lr_mult: 20 } inner_product_param { num_output: 20 # 改成你的类别数 } }这里 lr_mult 的第一个数字是权重学习率倍率第二个是偏置学习率倍率。新层没有预训练权重如果学习率和其他层相同训练几十轮后还是随机状态最后输出基本是常数。第三步是生成新的均值文件。很多教程直接沿用原始 mean.binaryproto但你的训练集是自己采集的均值分布完全不同。常见做法是用全部训练图片重新计算三个通道的均值。最后一步是启动 fine-tune 训练时用原始模型权重作为初始化但要指定 ignore 掉最后 fc8 层的旧权重。# 使用 caffe train 命令做 fine-tuning caffe train \ --solversolver.prototxt \ --weightsleafsnap.caffemodel \ 21 | tee train.logtrain 过程大概跑几百个迭代就会看到 loss 明显下降。这里有一个血泪经验要提fine-tune 几轮后发现验证集准确率上不去回查是不是忘了对图像做减均值。使用新生成的 mean.binaryproto 之后原始图片如果不再减均值效果会连随机初始化都不如。从那以后我每次做类似的迁移学习都会强制走一遍完整的验证流程先检查预处理链路再检查最后一层权重是否已加载最后才看训练曲线。顺序反了调试时间翻倍。这个检查习惯帮我在很多项目里省掉了无意义的反复试探希望也能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/2 9:33:09 · 阅读 1.2k Deep-Leafsnap解析：基于Caffe和GoogLeNet的植物叶片识别推理与迁移实践
简介Deep-Leafsnap-master.zip 是一份基于 Python 与深度学习的植物叶片识别系统源码包面向具备一定 Python 基础、希望入门或进阶图像分类与迁移学习的开发者。项目利用 CNN 模型分析叶片图像特征涵盖数据读取、模型构建、训练与测试等流程适合用于植物学相关科研、教学演示和爱好者实践。压缩包共 13 个文件以 9 个 Python 脚本为核心覆盖数据集加载、ResNet/DenseNet/VGG 等网络结构定义、训练工具与测试模块另有 CSV 标签数据、requirements 依赖清单、说明文档及配置文件便于快速搭建可复现环境。包体仅 327KB结构紧凑已有 364 人学习浏览。通过运行该项目可以掌握 Keras/TensorFlow 实现植物叶片识别的完整链路并了解 OpenCV、PIL 的图像预处理技巧以及 Scikit-learn 在数据评估中的应用还可用自己的叶片数据替换训练集进行迁移学习是一份适合动手实践的深度学习入门范例。1. Deep-Leafsnap 到底能干什么一个不做训练也能复现的植物叶片识别项目做图像识别的同行应该都有过这种经历模型精度刷不上去老板说换个数据集试试结果光是数据标注就耗掉两周。Deep-Leafsnap 这个项目我第一次跑通时最大的感受是——终于有个不用自己从头训练 CNN拿来就能跑出结果的完整方案了。它基于 Caffe 框架和 GoogLeNet 模型针对 186 种植物叶片做分类识别整个代码包从数据加载、模型预测到结果展示是闭环的不需要你额外配数据库、也不需要自己准备训练集。对这个项目感兴趣的人群大概分三类做毕业设计要交植物识别系统的学生想快速体验深度学习推理全流程的入门开发者以及想拿现有模型做迁移学习、但不想碰复杂工程配置的算法工程师。不管你是哪一类这个 zip 解压之后能跑通的概率都不低因为它依赖的 Python 代码路径短、依赖少唯一的门槛反而是环境版本之间的兼容问题。下面我从工程结构和代码逻辑说起把整个识别链路掰开讲清楚。2. 工程结构拆解先把黑匣子的骨架看清楚2.1 解压之后的目录到底在组织什么Deep-Leafsnap-master.zip 解压之后你会看到一组典型的 Caffe 工程文件。我第一次打开时最困惑的是它没有 src 和 models 那样的大目录分类而是把所有推理要用的东西散在根目录和几个子目录里。这里我建议你先别急着跑代码花五分钟把每个文件的功能对上号后面调试会省很多时间。最常见的做法是先把文件按四类归组第一类是模型定义文件包括 deploy.prototxt 和对应的 caffemodel 权重文件这两者是推理的核心第二类是输入预处理相关比如均值文件 mean.binaryproto它负责把图片像素值做归一化第三类是 Python 脚本包括加载模型、读取图片、执行预测的主脚本第四类是辅助资源比如类别标签文件 labels.txt 和示例测试图片。Deep-Leafsnap-master/ ├── deploy.prototxt # GoogLeNet 网络结构定义推理模式 ├── leafsnap.caffemodel # 预训练权重186类叶片分类 ├── mean.binaryproto # 训练集的图像均值做减均值预处理 ├── labels.txt # 类别索引到植物名称的映射 ├── classify.py # 主推理脚本 └── images/ # 存放待测试的叶片图片提示如果你拿到的压缩包没有 labels.txt别慌类别名通常直接写在 predict 输出里只是映射方式不同。deploy.prototxt 和训练用的 train_val.prototxt 最大的差别在于deploy 版本去掉了 Loss 层和 Accuracy 层保留了从数据输入到 Softmax 输出的完整前向通路。想做二次开发的话改的是 deploy.prototxt 的输入尺寸或者输出维度而不是去动 weights 文件。2.2 推理链路中每个文件存在的理由很多新手有个误解觉得有了 caffemodel 就够了其他文件都是多余的。实际跑一次就知道缺哪一个都跑不出正确结果。caffemodel 里存的是卷积层、池化层、全连接层的权重数值但网络层与层之间怎么连接、每层用什么参数这些结构信息是在 prototxt 里定义的。Caffe 推理时必须把结构文件和权重文件同时加载二者缺一不可。mean.binaryproto 则对应训练时的数据增强策略。GoogLeNet 在 ImageNet 上训练时输入图片会先缩放到 256×256然后中心裁剪到 224×224再减去整个训练集的 RGB 三通道均值。如果你跳过减均值的步骤输入分布和训练时的分布不一致Softmax 输出的概率会明显偏低且分类置信度混乱。labels.txt 的作用是把 Softmax 输出的 186 维向量里的最大索引映射成具体的植物名称。比如索引 57 对应的是某个科的某个种没有这个映射文件你拿到的只是一堆浮点数。整个推理链路的数据流是原始图片 → resize → 减均值 → 网络前向计算 → Softmax → 取最大值索引 → 查 labels → 输出植物名称和置信度。下面这张表格把每个环节的输入输出对应起来。环节输入处理输出预处理JPEG 图片任意尺寸OpenCV 读取并缩放224×224×3 的 float 数组减均值224×224×3 数组减去 mean.binaryproto 中的均值归一化后的 blob前向计算blobGoogLeNet 多层级联卷积186 维概率向量结果映射186 维向量取 argmax植物名称与置信度3. 核心代码逻辑把 Python 推理脚本一行行看明白3.1 模型加载和预处理为什么这么写Deep-Leafsnap 的推理脚本核心很短通常几十行就能跑完。但如果直接复制到自己的项目里大概率会遇到图片读入格式不对、blob 形状不匹配、输出维度解析错误这三个问题。先看模型加载部分。import caffe import numpy as np # 设置网络结构文件和权重文件路径 net caffe.Net(deploy.prototxt, leafsnap.caffemodel, caffe.TEST) # 指定使用 CPU 还是 GPU 推理 caffe.set_mode_cpu()这里的关键点在于 caffe.Net 的第二个参数传的是 caffemodel 路径第三个参数 caffe.TEST 表示加载推理模式。如果你在训练模式加载 deploy 网络会有层缺失报错。caffe.set_mode_cpu() 在没有 NVIDIA 显卡的机器上是必须的否则会直接抛出 CaffeError。接下来是图片读取和预处理。Caffe 的 Python 接口不直接接受 PIL 图像要用 OpenCV 转成 BGR 顺序的 ndarray。import cv2 # 读取图片OpenCV 默认输出 BGR 格式 img cv2.imread(images/sample_leaf.jpg) img cv2.resize(img, (256, 256)) # 中心裁剪到 224x224 crop img[16:240, 16:240] # 转换为 float 并调整维度顺序为 (1, 3, 224, 224) crop crop.astype(np.float32) crop crop.transpose((2, 0, 1)) crop crop[np.newaxis, :, :, :]注意GoogLeNet 训练时用的是中心裁剪策略而不是直接 resize 到 224×224。直接 resize 会把叶片边缘拉变形识别精度会掉。代码里的 16 这个数字来自 (256-224)/2。如果你改成了其他缩放尺寸裁剪起点也要相应调整。transpose 的作用是把 HWC 格式转成 CHW因为 Caffe 的 blob 维度顺序是 (batch, channel, height, width)。3.2 减均值和前向推理的完整姿势均值文件 mean.binaryproto 在 Python 中需要用 caffe.io.blobproto_to_array 解析成数组才能做减法。这也是一部分人脸图片识别不出结果的常见原因——均值格式用错了。# 加载 mean.binaryproto 并解析成数组 blob caffe.proto.caffe_pb2.BlobProto() with open(mean.binaryproto, rb) as f: blob.ParseFromString(f.read()) mean_array caffe.io.blobproto_to_array(blob) # 输出形状是 (1, 3, 256, 256)需要 squeeze 去掉 batch 维 mean mean_array.squeeze() # 减均值crop 的形状是 (1, 3, 224, 224) # mean 的形状是 (3, 224, 224)可以广播 crop - meanmean.binaryproto 里存储的均值尺寸对应训练时的缩放尺寸也就是 256×256。所以这里不能直接用 caffe.io.resize_image 之类的操作去改均值尺寸。如果你的测试流程里图片缩放尺寸换了减均值时的形状也必须保持一致。前向推理部分更简单但有一个细节——GoogLeNet 的输出层名不是默认的 softmax而是 prob。# 把预处理后的图像数据送入网络 net.blobs[data].data[...] crop # 执行一次前向推理 output net.forward() # 取出 prob 层的输出186 维向量 prob output[prob][0] # 获取最大概率的类别索引 idx np.argmax(prob) # 从 labels.txt 读取对应的植物名称 with open(labels.txt, r, encodingutf-8) as f: labels [line.strip() for line in f.readlines()] print(识别结果:, labels[idx], 置信度:, prob[idx])prob 的 shape 是 (1, 186)取 [0] 拿到的是 186 维的向量。如果你的网络在最后一层改成了 SoftmaxWithLoss那么输出名就不是 prob需要在加载网络后先用 net.blobs.keys() 看一下可用的顶层 blob 名称。3.3 一次完整运行需要的最小参数约定把上面的逻辑拼成一个完整的 classify.py 后你会发现真正需要调的就四个参数模型结构路径、权重路径、均值路径、待测图片路径。我建议把这四个路径全部用命令行参数的形式暴露出来而不是硬编码在脚本里。这样批量测试图片时不用每次改代码。参数取值约定出错时的典型现象deploy.prototxt推理模式版本加载报错 Missing blamecaffemodel与 prototxt 匹配层名称或维度不匹配报错mean.binaryproto与训练尺寸一致减均值向量形状不匹配输入图片RGB 任意格式BGR 通道序错误导致色偏这组参数约定同时也是排查问题的索引。模型加载失败先看权重和结构是否匹配输出置信度普遍低于 0.3优先怀疑减均值或通道顺序问题个别类别总是识别错再看 labels.txt 的索引是不是从 0 开始对应。4. 从零复现这套识别流程环境配置与运行步骤4.1 Caffe 环境在 Windows 和 Linux 下的搭建差异Deep-Leafsnap 是一个 Caffe 项目但很多人习惯在 Python 的虚拟环境里跑这就有一个现实问题Caffe 的 Python 接口不能直接用 pip 安装必须自己编译或者找预编译版本。在 Linux 下相对简单源码编译时只需要在 Makefile.config 里打开 Python 层的开关然后把 caffe 目录加入 PYTHONPATH 即可。Windows 环境下则不太建议从源码编译 Caffe因为依赖项太多尤其是 cuDNN 和 OpenBLAS 的版本组合很容易出问题。常见做法是找社区预编译的 caffe 版本比如 caffe-windows 的 release 包或者直接用支持 CPU 推理的二进制包。编译时需要注意的配置项包括# Makefile.config 中关键选项 CPU_ONLY : 1 # 如果没有 NVIDIA GPU 则必须打开 PYTHON_INCLUDE : /usr/include/python3.6m WITH_PYTHON_LAYER : 1CPU_ONLY 这个开关对 Deep-Leafsnap 的影响很大。GoogLeNet 模型在 CPU 上推理一张 224×224 的图片大约需要几百毫秒到一秒左右完全在可用范围内。但如果你误开了 GPU 模式又没有显卡程序会直接崩溃报错信息是 Check failed: error cudaSuccess (2 vs. 0)。4.2 配置好环境后的运行步骤假设你的 Caffe 已经编译完成Python 接口可以正常 import caffe 了。接下来就是标准的运行流程。第一步把 Deep-Leafsnap-master 解压到一个没有中文和空格的路径下。Caffe 的 Python 接口在读取 prototxt 时对路径中的中文支持很差经常会报 file not found 或者编码错误。cd /home/user/Deep-Leafsnap-master # 设置 PYTHONPATH 指向 caffe 的 python 目录 export PYTHONPATH/path/to/caffe/python:$PYTHONPATH第二步确认 deploy.prototxt 中的输入层尺寸是 224×224。有的版本默认写的是 256导致后续图片输入维度不匹配。检查方式是用 grep 找 input_dim。grep -n input_dim deploy.prototxt # 期望看到两行 224 和两行 1第三步运行 classify.py 测试默认图片。python classify.py --image images/sample_leaf.jpg如果输出结果里出现了植物名称和置信度说明链路已通。接下来再换自己拍的图片时只需要保持叶片在画面中心、背景尽量干净即可。4.3 跑通后如何验证结果不是偶然的运气一次成功有可能只是因为这张测试图和训练集里的样本太像了。要判断整个流程是否真的可用批量测试是必须的。这里给一个简单的批量验证脚本思路把你手头已经标注好的叶片图片放到一个目录下脚本循环执行推理同时统计 Top-1 准确率。import os import numpy as np result_dir test_images correct 0 total 0 for img_name in os.listdir(result_dir): if not img_name.endswith(.jpg): continue # 真实标签从文件名中解析例如 Quercus_rubra_01.jpg true_label img_name.rsplit(_, 1)[0].replace(_, ) # 执行 3.2 中的推理流程得到 pred_label pred_label classify(img_name) total 1 if pred_label true_label: correct 1 print(Top-1 准确率:, correct / total)建议至少测试 30 张以上与训练集不同来源的图片。如果准确率维持在 60% 以上这个识别链路在你自己数据集上的可用性就比较可信了。如果某个类别的图片几乎全错大概率是该类别在训练样本中数量偏少这也侧面反映了原始数据集的分布局限。5. 避坑指南识别项目最常见的五个翻车点5.1 现象加载 caffemodel 时报错 weight shape mismatch刚拿到压缩包直接跑最常见的一个报错是类似 Check failed: blob.count() num (某数字 vs 某数字) 的信息。这种形状不匹配问题的原因几乎都是 deploy.prototxt 与 caffemodel 不是同一套模型产物。网上传播的 Deep-Leafsnap 压缩包版本很杂有的包的 prototxt 是 GoogLeNet 原始版本而 caffemodel 可能来自微调后的分支。解决方法是先检查 prototxt 里最后一个全连接层的 num_output 是不是 186。如果不是要么改成 186要么只能找配套的权重文件。改完 prototxt 后需要重新确认前面卷积层的层名称是否与权重一致。5.2 现象输出类别概率很低都在 0.1 左右有时候推理能跑完但所有类别的概率都很平均最高的也不超过 0.2。这基本可以确定是输入图像的分布和训练集不一致。第一个嫌疑是减均值步骤被跳过了或者均值数组的形状不对。第二个嫌疑是图片通道顺序弄反了。OpenCV 读进来的图像是 BGR 顺序而 Caffe 训练时的图像是 RGB 顺序。如果你只做了 resize 和减均值没有做通道转换网络看到的是颜色反转的图像。修复方式是在读图后执行img cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。这个错误非常隐蔽因为叶片图像颜色偏绿色通道反转后视觉上差别不大但神经网络的特征分布完全改变了。5.3 现象classify.py 运行到 net.forward() 时内存暴涨GoogLeNet 的推理显存占用在 GPU 上大概 400MB 左右但在 CPU 模式下有些机器会遇到内存占用异常飙升到 4GB 以上的情况。原因是 prototxt 中的 batch_size 被调大了而且 CPU 模式下 Caffe 会用非最优的内存分配策略。解决方法是把 deploy.prototxt 第一层 data 的 batch_size 设为 1。一般来说推理模式的 batch_size 固定为 1 就够了不需要为了吞吐量调大除非你确认内存完全吃得住。5.4 现象图像尺寸和裁剪导致识别结果偏移前面提到过 GoogLeNet 的标准输入是中心裁剪后的 224×224。如果你直接把一张 1920×1080 的叶片照片 resize 成 224×224叶片比例被严重压缩识别结果大概率是错的。这个问题的本质是训练数据里的图像都是叶片占画面主要区域而你的测试图可能叶片很小、背景占比大。解决方式是把测试图片先做一次简单分割或手动裁剪让叶片区域占画面 70% 以上再送入识别流程。批量测试时最稳的做法是统一用 256×256 的 resize 加中心裁剪保持与训练时的预处理完全一致。5.5 现象labels.txt 的排序和概率索引对不上最后输出阶段probability 最高的索引对应的名称和实际叶片不符这种事也不少见。原因在于 labels.txt 的行序要和训练时类别 ID 的排序一致。有些版本的标签文件是按字母序排的有的是按训练集目录顺序排的。验证方法是找一张你确定类别的图片跑一遍看输出索引和 labels 该行的内容是否对应。如果发现所有结果都错位固定位数直接用 Python 脚本调整 labels 文件的行序即可。6. 把 Deep-Leafsnap 改造成自己的分类器fine-tune 的实用技巧前面几章的内容都是在现有模型上做推理。如果你不满足于 186 类想把它改成识别自己采集的 20 类或者 50 类植物叶片那就得动 fine-tune。这一步的访问路径不复杂但有三个细节值得认真处理。首先是数据组织。Caffe 的 fine-tune 通常用 LMDB 或 LevelDB 格式的数据库作为输入。你手头的图片要先按类别放入不同目录然后写脚本统一缩放到 256×256、按 8:2 划分训练和验证集再转换成 LMDB。检查一遍数据集的类别平衡性如果有的类别只有 10 张图而有的类别有 200 张训练出来的模型几乎必然对样本多的类别过拟合。import lmdb import caffe import numpy as np import cv2 import os # 创建 LMDB 数据库 env lmdb.open(leaf_lmdb, map_size1024*1024*1024) # 遍历所有类别目录 class_names sorted(os.listdir(leaves_data)) with env.begin(writeTrue) as txn: idx 0 for cls_id, cls_name in enumerate(class_names): img_dir os.path.join(leaves_data, cls_name) for img_name in os.listdir(img_dir): img cv2.imread(os.path.join(img_dir, img_name)) img cv2.resize(img, (256, 256)) # 转换为 Caffe 的 Datum 格式 datum caffe.io.array_to_datum( img.transpose((2, 0, 1)).astype(np.uint8), cls_id) txn.put(f{idx:08d}.encode(ascii), datum.SerializeToString()) idx 1注意array_to_datum 接受的数组必须是 CHW 顺序且类型为 uint8这里直接对 OpenCV 读入的 BGR 图像做 transpose 即可不需要转 RGB因为 Caffe 训练时会把数据当作 BGR 处理。第二步是修改 train_val.prototxt 的最后两层。最后一层全连接层的 num_output 从 186 改成你的类别数fine-tuning 通常把这一层的学习率调成其他层的 10 倍让随机初始化后新增的层更快收敛。layer { name: fc8 type: InnerProduct bottom: pool5 top: fc8 param { lr_mult: 10 } param { lr_mult: 20 } inner_product_param { num_output: 20 # 改成你的类别数 } }这里 lr_mult 的第一个数字是权重学习率倍率第二个是偏置学习率倍率。新层没有预训练权重如果学习率和其他层相同训练几十轮后还是随机状态最后输出基本是常数。第三步是生成新的均值文件。很多教程直接沿用原始 mean.binaryproto但你的训练集是自己采集的均值分布完全不同。常见做法是用全部训练图片重新计算三个通道的均值。最后一步是启动 fine-tune 训练时用原始模型权重作为初始化但要指定 ignore 掉最后 fc8 层的旧权重。# 使用 caffe train 命令做 fine-tuning caffe train \ --solversolver.prototxt \ --weightsleafsnap.caffemodel \ 21 | tee train.logtrain 过程大概跑几百个迭代就会看到 loss 明显下降。这里有一个血泪经验要提fine-tune 几轮后发现验证集准确率上不去回查是不是忘了对图像做减均值。使用新生成的 mean.binaryproto 之后原始图片如果不再减均值效果会连随机初始化都不如。从那以后我每次做类似的迁移学习都会强制走一遍完整的验证流程先检查预处理链路再检查最后一层权重是否已加载最后才看训练曲线。顺序反了调试时间翻倍。这个检查习惯帮我在很多项目里省掉了无意义的反复试探希望也能帮到你。本文还有配套的精品资源点击获取