简介这是一份YOLOv8格式的花卉分类数据集涵盖雏菊、蒲公英、玫瑰、向日葵和郁金香五个常见类别适合训练花卉识别与分类模型面向计算机视觉开发者、植物学研究人员以及需要快速落地花卉检测方案的学生。压缩包共2000个文件包含1999张JPG图片和1个Python脚本整体大小约218.93MB可直接对接YOLOv8训练流程也方便转换为其他格式使用。已有622人浏览学习资源结构简洁图片命名规范适合用于模型微调、精度验证以及分类系统的原型开发。数据集源自真实花卉图像覆盖不同角度与背景有助于提升模型的泛化能力配套脚本可辅助完成数据整理或类别划分。对于希望节省数据采集时间、专注算法设计的用户这份资源提供了现成的训练基础也能为花卉分类相关的科研和教学项目提供支持。1. 收到 5 类花卉 yolov8 格式数据集先分清它是检测还是分类收到一份 5 类花卉分类 yolov8 格式数据集时第一反应通常是改一下 data.yaml 就开训。但 daisy、dandelion、roses、sunflowers、tu 这五个类别看着简单实际落地中标签坐标系、类别编号、train/val 划分任何一个没对齐轻则 loss 不降重则 mAP 虚高、上线就翻车。这类小数据集最适合入门目标检测也最容易让人在“yolov8 格式”这个细节上栽跟头。我把从解压到训练完成的关键步骤和常见坑一次讲清楚适合做毕设、想用 yolo 训练自己数据的同学照着做。先泼一盆冷水标题里写“yolov8 格式数据集”不代表它就一定是目标检测数据集。解压后如果看到images/和labels/两个平级目录、且 labels 里全是 txt那确实是检测格式如果只是五个类别各一个文件夹、里面全是 jpg 没有 txt那其实是分类数据集。两种数据集的训练命令完全不同方向错了后边全是白忙。我见过有人拿着分类文件夹硬套 detect 命令报错后怀疑显卡、怀疑环境、怀疑人生最后发现是数据集形态没分清。2. 读懂 yolov8 数据集txt 标签、data.yaml 与目录划分的底层约定2.1 YOLO txt 标签归一化坐标与类别编号为什么不能错“yolov8 格式”最标准的定义是每张图片对应一个同名 txttxt 里每一行代表一个目标格式固定为类别编号 中心点x 中心点y 框宽 框高五个数值全部归一化到[0, 1]。这个设计让模型不关心图片实际分辨率但代价也很明显——任何一行写错模型读到的就是一个错误目标。以一张 1920×1080 的花卉图为例假设玫瑰花的框左上角在(100, 200)、右下角在(500, 600)类别编号是 2按 data.yaml 里 names 的顺序那么这一行的计算过程是x_center (100 500) / 2 / 1920 0.156250 y_center (200 600) / 2 / 1080 0.370370 width (500 - 100) / 1920 0.208333 height (600 - 200) / 1080 0.370370所以 txt 里应该写2 0.156250 0.370370 0.208333 0.370370。很多从 COCO 或其他检测格式转过来的数据最容易犯的错就是坐标忘记除以图片宽高、或者直接用像素坐标写进 txt。训练时坐标值大于 1ultralytics 不会直接报错而是把框画到图片外面去loss 异常高结果模型学到的全是乱框。提示任何数据集到手先抽查五条标签确认第二到第五个数值都在 [0, 1] 区间。这一步成本极低但能过滤掉一半以上的格式问题。另一个关键点是类别编号与 data.yaml 的 names 顺序严格绑定。同一份 txt第 0 类到底是 daisy 还是 dandelion完全看你 data.yaml 里把谁写在前面。这意味着从别人那里拷贝数据集后最忌讳就是“看着不顺眼”重排 names 顺序——一旦重排所有 txt 的类别含义整体错位训练出来的模型会稳定地把蒲公英认成雏菊而且 mAP 还很高因为错误是系统性的。2.2 images / labels 双目录与 train / val 的划分约定一个规整的 yolo 检测数据集目录结构通常是这样的flowers_yolo/ ├── data.yaml ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/train 下 img 与 label 不混放、images 与 labels 下子目录名完全一致是对 ultralytics 训练流程最基本的尊重。data.yaml 是告诉训练器“去哪儿找图”的唯一入口常见写法如下path: /absolute/path/to/flowers_yolo train: images/train val: images/val nc: 5 names: [daisy, dandelion, roses, sunflowers, tu]path一般建议写绝对路径因为相对路径的解析在不同启动目录下行为不一样容易莫名报AssertionError: train set not found。nc必须与names列表长度一致names顺序决定了 txt 里类别编号的含义。至于最后那个tu多数版本是 tulip 的缩写但你在训练前一定要翻几张标签确认别拿缩写去猜类别语义。train/val 的划分比例5 类小数据集一般建议 8:2但真正影响结果的是划分方式。最忌讳的做法是直接用文件名随机切分因为同一株花的照片、同一场景的不同帧很可能同时进到 train 和 val模型记住的是背景和拍摄条件验证集指标虚高换批真实照片就现原形。按拍摄场景分组划分更稳妥其次是按类别分层抽样。2.3 用几行命令检查标签的数值范围格式对不对一句话说得再多不如跑一遍命令。先看空文件和越界坐标# 列出空标签文件 find flowers_yolo/labels/train -name *.txt -empty | head # 检查归一化坐标是否超出 [0,1]$2~$5 是 cx/cy/w/h awk {if($20||$21||$30||$31||$40||$41||$50||$51) \ print FILENAME: $0} flowers_yolo/labels/train/*.txt | head这个 awk 命令的逻辑很简单YOLO txt 每行按空格拆成 5 个字段第 1 个是类别编号第 2 到第 5 个是归一化坐标和宽高。只要任何一个字段越界就说明转换脚本或人工标注出了结构性问题必须回炉处理而不是靠训练时的数据增强硬扛。再看类别编号是否超界。五个类别意味着合法编号只有 0 到 4一旦出现 5 或 6ultralytics 会静默丢弃这些框或直接报错from pathlib import Path max_cls 0 for txt in Path(flowers_yolo/labels/train).glob(*.txt): for line in txt.read_text().splitlines(): cls int(line.split()[0]) if cls max_cls: max_cls cls print(最大类别编号:, max_cls) # 必须小于 nc5这段代码适合放进任何数据集预检流程里跑完输出一个数字心里就有底了。我习惯把它存成一个check_labels.py以后每换一个数据集都先跑一遍比在训练日志里痛苦排错省事太多。3. 把花卉原始数据转成 yolov8 格式两条转换路线与可复现脚本3.1 路线 ACOCO json 标注转 YOLO txt很多公开花卉检测数据不会直接给 txt而是给 COCO 格式的 json。COCO 的 bbox 字段是[x_min, y_min, width, height]用像素表示和 YOLO 的归一化中心点表示法差了十万八千里。转换的核心就三件事像素坐标转归一化、COCO 的 category_id 重映射成从 0 开始的连续编号、按图片维度裁剪越界框。import json from pathlib import Path def coco_to_yolo(coco_json, images_dir, labels_dir, category_map): 把 COCO 标注 json 转成 YOLO txt。 category_map 是 {COCO类别ID: 你的类别编号} 的手工映射。 labels_dir.mkdir(parentsTrue, exist_okTrue) with open(coco_json) as f: coco json.load(f) img_map {img[id]: img for img in coco[images]} ann_map {} for ann in coco[annotations]: ann_map.setdefault(ann[image_id], []).append(ann) for img_id, img in img_map.items(): w, h img[width], img[height] # 用 json 里的宽高不信任 jpg 头 lines [] for ann in ann_map.get(img_id, []): new_cls category_map.get(ann[category_id]) if new_cls is None: continue x, y, bw, bh ann[bbox] x2, y2 x bw, y bh # 裁剪越界框到画布内过滤掉宽或高小于 1px 的残废标注 x, y max(0, x), max(0, y) x2, y2 min(w, x2), min(h, y2) if x2 - x 1 or y2 - y 1: continue lines.append( f{new_cls} {(xx2)/2/w:.6f} {(yy2)/2/h:.6f} f{(x2-x)/w:.6f} {(y2-y)/h:.6f} ) if lines: stem Path(img[file_name]).stem (labels_dir / f{stem}.txt).write_text(\n.join(lines)) category_map {1: 0, 2: 1, 4: 2, 8: 3, 9: 4} # 按你的 data.yaml 顺序手动核对这段代码里最容易忽略的是category_map。COCO 的 category_id 往往不连续可能从 1 开始、中间还跳号你的数据里五个类别大概率落在若干个离散的 ID 上。如果没有手工映射直接用原 ID 当 YOLO 编号轻则类别对不上重则编号越界导致训练直接失败。另一个细节是用 json 里的width/height而不是重新读图片——json 标注时的尺寸和你现在磁盘上图片的尺寸可能不一致重新读图只会引入更多不确定性。3.2 路线 BImageFolder 分类数据直接用 classify 模式训练如果你的“yolov8 格式数据集”解压后根本没有 labels 目录只有五个花朵类别文件夹那这就是图像分类任务不需要也不会生成检测框。此时最省事的做法不是强行造框而是直接用 ultralytics 的 classify 模式from ultralytics import YOLO model YOLO(yolov8n-cls.pt) # 分类版预训练权重 model.train(dataflowers_raw, epochs50, imgsz224)data参数指向的是分类数据集根目录根目录下必须是五个类别子文件夹子文件夹的名字就是类别名比如daisy/、dandelion/、roses/、sunflowers/、tu/每个文件夹里放对应类别的 jpg。ultralytics 会自动按 8:2 拆分训练集和验证集不需要你手写 data.yaml。imgsz224是分类任务常见输入尺寸五个类别区分度足够224 不会丢关键特征还省显存。不过这里有个路线选择问题如果标题里的数据集明确是“yolov8 格式”我更建议先搞清楚发布者说的格式到底指检测还是分类。检测数据集的标注成本远高于分类拿到手后信息量也更大——每朵花的框、位置、大小都有。只因为懒得处理 txt 就退化成整图分类等于主动丢弃了一半标注价值。如果做的是花店识别这类“判断画面里有没有某种花”的需求检测模型还能顺带输出位置实用性强很多。3.3 划分数据集并目检标注框转换完成后还要做一次正式划分。推荐用 stratified 分层抽样而不是纯随机五个类别的样本量通常不均匀纯随机有可能让验证集里某个类别只有几张图指标波动巨大。import random import shutil from pathlib import Path random.seed(42) src_images Path(images) src_labels Path(labels) dst Path(flowers_yolo) for split in [train, val]: (dst / images / split).mkdir(parentsTrue, exist_okTrue) (dst / labels / split).mkdir(parentsTrue, exist_okTrue) txts list(src_labels.glob(*.txt)) random.shuffle(txts) cut int(len(txts) * 0.8) for txt in txts[:cut]: img src_images / f{txt.stem}.jpg if img.exists(): shutil.copy(img, dst / images / train) shutil.copy(txt, dst / labels / train) # 剩余 20% 同理复制到 val划分完别急着训练先目检。把归一化坐标还原成像素画框存成可视化图片人眼扫一遍比任何指标都直观from PIL import Image, ImageDraw img Image.open(flowers_yolo/images/val/sample.jpg) draw ImageDraw.Draw(img) with open(flowers_yolo/labels/val/sample.txt) as f: for line in f: cls, cx, cy, w, h map(float, line.split()) x1 int((cx - w / 2) * img.width) y1 int((cy - h / 2) * img.height) x2 int((cx w / 2) * img.width) y2 int((cy h / 2) * img.height) draw.rectangle([x1, y1, x2, y2], outlinered, width3) img.save(check_sample.jpg)框是框、花是花、没有半个框飘在背景上这一步过了再谈训练。我见过太多人跳过目检训练完 loss 曲线怪怪的才开始怀疑数据回头看发现标注框歪到姥姥家去了。4. 训练 5 类花卉的 yolo 命令最小写法与四个必调参数4.1 最小训练命令单卡从零跑通确认数据集形态、划分、目检都做完后训练命令本身可以非常短。ultralytics 把大部分默认参数都调好了第一次跑通用最小命令就够pip install ultralytics yolo detect train \ dataflowers_yolo/data.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch16modelyolov8n.pt是指用 COCO 预训练权重做迁移学习微调而不是从零初始化。五个类别的花卉检测COCO 里虽然不直接含花品类但其通用的纹理、边缘特征对初始化模型有帮助收敛速度和最终精度都比从头训好得多。如果机器只有 CPUyolov8n配上imgsz320、batch8也能跑动但训练时长要做好心理准备。4.2 四个必调参数imgsz、batch、patience 与类别权重最小命令能跑通但要让五个类别的结果可用下面四个参数必须在第一轮训练前就想清楚。参数推荐值说明imgsz640小目标可 960imgsz 越大小目标保留的像素越多但小数据集盲目放大容易引入更多背景噪声和显存压力batch显卡显存允许的最大值batch 太小 BN 统计不稳定loss 震荡明显一般 batch 从 16 起步patience20~30验证集指标连续 N 轮不提升自动早停5 类小数据集很有用防过拟合也省时间class weightsclass_weightsTrue或手动给样本少的类别加权五个类别样本量通常不均衡daisy 可能比 roses 多几倍不加权的模型会偏向多数类以小数据集为背景imgsz 的权衡最值得说。向日葵和玫瑰这类花占画面比例往往很大但蒲公英这类小花可能只在画面角落里占几十个像素。imgsz640时网络输入被 letterbox 缩放原本 200×200 的蒲公英可能被压到 60×60识别难度直线上升。看到 val 集上某几个类别的 mAP 明显偏低时优先考虑的不是换模型而是把 imgsz 拉到 960 试试。class weights 在 yolo 里可以通过--class_weights开启但样本极不均衡时我更建议先做数据层面的处理——把多的类别降采样少的类别做基础增强而不是只靠 loss 加权。加权是让模型“重点背少样本”数据均衡是让模型“见过更多形态”后者的泛化能力更可靠。4.3 小数据集增强mosaic 不是越大越好ultralytics 默认mosaic1.0意思是训练时 100% 概率把四张图拼成一张。这个增强对检测任务非常有效但五个花卉类别的数据量通常只有几百到几千张mosaic 比例拉满后花瓣被切碎、颜色被拼接边界污染模型学到的是碎片而不是完整花朵结构。常见做法是降一档yolo detect train \ dataflowers_yolo/data.yaml \ modelyolov8n.pt \ epochs100 imgsz640 batch16 \ mosaic0.5 \ fliplr0.5 \ hsv_h0.02 \ scale0.3mosaic0.5保留了一半的拼接增强另一半用完整原图稳定训练。fliplr0.5是左右翻转对花朵这种前后对称的目标基本无损。hsv_h0.02是色调微调花卉颜色是关键分类特征色相偏移太大会让红玫瑰变成紫玫瑰所以要压得比默认值低。scale0.3控制随机缩放幅度让模型看到不同尺度的花。这几个参数没有标准答案但方向很明确小数据集的目标是让模型在“见过”的基础上多一点点变化而不是让增强把图片改到亲妈都不认识。mosaic 过高、hsv 过大验证集损失会先降后升看着像过拟合其实是增强失真。5. 训练 5 类花卉数据集时的避坑记录现象、原因与解决5.1 mAP 虚高但实测“张冠李戴”验证集划分的坑现象训练完看结果验证集 mAP0.5 到 0.95 有 0.85 以上很漂亮拿手机现拍几张花喂进去daisy 被认成 dandelionsunflowers 直接漏检。原因验证集和训练集来自同一批图片的随机切分。同一朵花的拍摄系列被拆到两边模型其实记住了背景纹理和拍摄条件而不是花的本质特征。更隐蔽的情况是同一场景连拍帧分别进了 train 和 val模型靠背景就能“猜对”验证集失去参考意义。解决按拍摄场景分组划分数据。最简单的做法是以图片文件名的前缀或目录为分组单位同一个场景只允许出现在一侧。没有场景信息时用日期或拍摄批次作为代理分组。最后留出 10~20 张绝对没进过训练流程的现场照片当“终考卷”这也是我判断一个检测模型能不能上线的唯一标准。5.2 标签文件大面积空白类别编号与 names 顺序错位现象训练日志里每个 epoch 的img数量正常但box_loss始终在一个偏高的位置下不去打开保存的 txt 发现大量标签文件是空的或者只有类别编号没有坐标。原因最典型的场景是数据集原作者用自己的 data.yaml 顺序标注txt 里类别编号可能到 8、9 甚至更大你在新项目里重写了 data.yamlnc变小ultralytics 读到越界编号后直接丢弃整行。另一类原因是图片是 jpg但标注文件按同名生成了.jpeg.txt文件名对不上标签自然为空。解决训练前跑一遍第 2.3 节的检查脚本统计最大类别编号、列出空文件。出现越界编号用类别映射脚本把所有 txt 里的编号统一重映射到新顺序sed -i s/^5 /2 / *.txt这类批量替换只适合编号间无歧义时用更稳妥是写个 python 循环读一行改一行。批量替换前记得备份原始标签这是血泪教训换来的习惯。5.3 向日葵和雏菊同框小的那朵始终学不会现象验证集里 roses 和 sunflowers 这类大花的 mAP 正常daisy 的 mAP 明显低一大截。打开预测图大花框得准小花要么漏检要么框错位置。原因同一张图里多目标尺度悬殊imgsz640下小目标只有十几个像素特征图下采样 32 倍后几乎只剩一个点。这不是模型能力问题而是数据进入网络前的分辨率不够。花卉数据集里大花平铺、小花远景并存是常态直接按整图 $640\times640$ 训练小花类永远吃亏。解决两条路。第一把imgsz拉到 960 或 1280小目标像素数直接翻倍显存不够就降 batch这是最省事的提升。第二针对小花类别做滑窗切图把大图切成 $640\times640$ 的 tiles 再训练相当于变相放大局部目标。切图时要保证切出来的 tile 里目标没有被截断到只剩 20%否则产生了另一种难样本。如果你最后要部署到边缘设备还得考虑推理时用同样切图策略训练和部署的预处理不一致是另一处翻车点。5.4 训练到一半 loss 变 NaN先查标签再查学习率现象前几个 epoch 一切正常某个 epoch 开始train/box_loss直接变成nan日志开始刷WARNING: skipping training sample验证集 mAP 掉到 0。原因最常见的不是学习率而是标签里混进了非数字字符或非法坐标。比如从 Excel 手动补标注时某一行坐标写成了#N/A或者归一化时出现inf。另外图片文件损坏jpg 头残缺也会在解码时产出空张ultralytics 会跳过但可能连锁产生异常梯度。解决第一时间跑第 2.3 节的 awk 检查和空文件检查把有问题的标签找出来修掉不要先动学习率。之前调过一个大模型loss 反复 NaN换遍了优化器参数最后发现是一张截图格式伪装成 jpg、解码出来全黑导致的。数据修干净后不动任何超参loss 自己就恢复正常了。真需要降学习率是在标签确认无误之后依然发散才考虑从 $0.01$ 降到 $0.005$。5.5 显存没跑满却比 CPU 还慢小 batch 与数据线程的坑现象训练时nvidia-smi显示显存占用只有 2GGPU 利用率在 20%~40% 之间跳一个 epoch 耗时比预期多三四倍。换到 CPU 上试反而没那么慢。原因小数据集图片总量少但单张图片分辨率高jpg 解码成了瓶颈。默认workers8在 Windows 上因为 spawn 机制经常不生效实际数据供给线程不足加上 batch16 时 GPU 计算量大但数据排队时间更长利用率自然上不去。解决显存有余就调大 batch让 GPU 计算密度升上来然后把cacheTrue打开把图片缓存到内存或 SSD省掉每轮重复解码的 IO 开销workers 设为 CPU 核心数一半左右。Ultralytics 命令行写成workers8 cacheTrue即可。如果 PyTorch 在 Windows 下频繁报 DataLoader worker 崩溃直接workers0让它退到主进程加载稳定比速度优先。6. 再进一步用损失曲线和混淆矩阵反查数据质量6.1 用 results.csv 画损失曲线两条线的距离说明问题训练跑完runs/detect/train目录下会有results.csv里面记录了每个 epoch 的各类 loss 和指标。把它画成曲线比盯终端刷数字直观得多import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/detect/train/results.csv) df.columns [c.strip() for c in df.columns] # 去掉列名里的空格 plt.figure(figsize(8, 3)) plt.plot(df[epoch], df[train/box_loss], labeltrain box) plt.plot(df[epoch], df[val/box_loss], labelval box) plt.xlabel(epoch) plt.ylabel(box_loss) plt.legend() plt.savefig(box_loss.png, dpi150)看这条曲线时我重点观察两个形状train loss 持续下降、val loss 在某个 epoch 后不再下降甚至反弹说明模型开始过拟合早停参数 patience 该起作用了train 和 val 两条线始终离得很远说明数据划分有问题或增强太强模型在训练集上的模式没有泛化到验证集。画这个图配results.csv数据也算是我每次训练完的固定收尾动作比只看最后一行 mAP 信息量大得多。6.2 看混淆矩阵定位错分daisy 和 dandelion 的经典恩怨训练完runs/detect/train下还会自动生成confusion_matrix.png按行看每个类别的预测分布。5 类花卉里几乎必然出现一个现象daisy 和 dandelion 互相错分。这俩都是白色或黄色头状花序花瓣细密俯视角度下视觉特征高度重叠纯靠整图特征区分模型确实容易懵。看混淆矩阵时别只盯着对角线数字要看具体哪两个类别之间块最大。如果 roses 和 sunflowers 也纠缠那通常是颜色相似度太高需要补的是不同光照、不同背景下的样本如果 tutulip错分到 roses多半是花型都是杯状的锅。定位到具体错分对后再去针对性采样等于把每次训练都当成一次数据诊断。这个习惯帮我在很多项目里省下了盲目加数据的无用功不加一张图先搞清楚模型到底在哪些地方犯难再决定要不要动数据。我现在的固定流程是标签预检 → 分层划分 → 目检画框 → 训练 → 损失曲线 混淆矩阵 → 针对错分对补数。这套流程在这个 5 类花卉数据集上跑过之后我再拿到任何数据都会先过一遍标签再谈训练当年浪费在格式排查上的时间够我多训三版模型。希望帮到你。本文还有配套的精品资源点击获取