簡介植物萌芽檢測數據集專注植物萌發(fā)階段的視覺識別面向精準農業(yè)監(jiān)測、智能溫室管理、植物表型研究及農業(yè)科研教學等場景可支持構建萌芽期識別模型用于作物生長階段自動化監(jiān)測與生長周期預測。數據集共2000個文件涵蓋1484個txt格式邊界框標注、514張jpg原始圖像、1個yaml配置與1個docx說明文檔壓縮包整體約133.71MBtxt標注遵循中心坐標加寬高的YOLO規(guī)范yaml可直接套用訓練配置docx補充數據構建與使用建議。數據劃分包含1177張訓練圖、302張驗證圖及5張測試圖覆蓋多種視角并包含旋轉、裁剪、噪聲處理等增強版本有助于提升模型魯棒性。目前已有101人學習適合目標檢測研究者與農業(yè)AI開發(fā)者快速開展萌芽期檢測實驗亦可作為農林院校算法教學實踐數據集。1. 植物萌芽檢測數據集從標準 YOLO 標注圖到能落地的出芽識別模型溫室育苗車間里一張苗盤幾百個穴孔旺季時工人要逐個弓腰核對萌芽率一個班下來脖子和眼睛都僵得難受。植物萌芽檢測數據集解決的正是這種重復枯燥的視覺勞動它把苗期圖像整理成標準 YOLO 標注格式拿回來就能直接丟給 YOLOv12 這類目標檢測模型訓練模型輸出每個芽的坐標框與置信度后面接統(tǒng)計報表還是補苗機械臂都順理成章。適合三類人做農業(yè)自動化方案的工程團隊、要在嵌入式設備上跑植物視覺識別的開發(fā)者以及研究工業(yè)農業(yè)醫(yī)學領域目標檢測數據集落地的從業(yè)者。省下的不只是標注時間還有從零梳理訓練管線的過程。2. 先看懂數據集的目錄與標注格式訓練前的一小時自檢2.1 目錄結構長什么樣這份資源解壓之后內部目錄是按目標檢測訓練的標準習慣組織的。我拿到任何一份數據集第一步不是急著訓練而是先把目錄樹摸清楚確認 images 和 labels 是否一一對應。常見結構如下plant_sprout/ ├── images/ │ ├── train/ │ │ ├── sprout_0001.jpg │ │ ├── sprout_0002.jpg │ │ └── ... │ └── val/ │ ├── sprout_0351.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── sprout_0001.txt │ │ ├── sprout_0002.txt │ │ └── ... │ └── val/ │ └── ... └── plant_sprout.yamltrain 與 val 的比例通常接近 8:2 或 9:1這個數據集按經驗也是這種劃分。圖像多為俯拍或斜俯拍的苗盤/苗床照片分辨率跨度比較大有手機拍的也有工業(yè)相機拍的恰好能模擬現場設備參差不齊的真實狀況。每個 jpg 對應一個同名 txttxt 里存的就是這張圖上所有目標框的標注。yam 文件是給 Ultralytics 系列訓練框架用的數據集描述文件里面寫明了類別數量和類別名稱訓練時直接以dataplant_sprout.yaml的方式引用。在動手訓練之前建議先做一件事用tree或find把文件數量統(tǒng)計出來確認兩個目錄的文件數一致避免后面訓練時出現“部分圖像沒有標簽”的隱蔽問題。find images/train -name *.jpg | wc -l find labels/train -name *.txt | wc -l如果兩邊數量對不上說明存在漏標注的圖像后面訓練出的模型在沒標簽的那些圖上大概率會被當作負樣本直接干擾損失函數。我的習慣是先把這一步走完再談參數。2.2 YOLO 標注格式里的數字到底代表什么YOLO 格式的每一行是五個數字依次是類別編號、目標中心點的 x 坐標、y 坐標、目標寬度、目標高度。坐標全部做了歸一化處理取值都在 0 到 1 之間分母是圖像的寬和高不是像素絕對值。我拿一份典型的標注拆開說明1 0.513462 0.288741 0.034615 0.040727這一行表示這張圖里有一個類別編號為 1 的目標它的中心點位于圖像水平方向 51.35%、垂直方向 28.87% 的位置目標本身寬度約占整張圖寬度的 3.46%高度約占整張圖高度的 4.07%。換算成像素值只需要把前兩個數乘以圖像寬高、后兩個數乘以圖像寬高就能得到真實的像素框。萌芽期的小苗在整張圖中往往只占很小一塊面積所以 w、h 這類數字普遍落在 0.02 到 0.08 之間屬于典型的小目標標注。做這類數據集訓練最忌諱的就是把 w、h 的順序記反還有把中心點坐標誤當成左上角坐標。我見過不止一個同事用 LabelImg 導出時選了 PASCAL VOC 格式然后又手動轉 YOLO轉完忘了除寬度訓練出來的框全部偏移到圖像角落。這份數據集里常見類別有兩種組織方式一類是只標“萌芽”一個類別適合單純的出芽計數另一類會把“未出芽的空穴”和“已出芽”區(qū)分開甚至把子葉展開的苗單獨列一類。后者在實際補苗場景中更有用因為自動補苗需要同時知道哪里空著、哪里已經長出來了。拿到數據集后先打開 yaml 文件確認 names 列表的內容不要按我的項目場景強行套你的業(yè)務邏輯。2.3 用一段腳本把數據集的健康狀況查一遍訓練之前我強烈建議把下面這段校驗腳本跑一遍。它做的事很簡單遍歷每張訓練圖檢查同名標簽是否存在、每行是不是 5 個字段、坐標是否都落在 0 到 1 范圍內。這段腳本幾乎可以套用在任何 YOLO 格式數據集上不止這一份資源。from pathlib import Path root Path(plant_sprout) bad_count 0 for split in [train, val]: img_dir root / images / split lbl_dir root / labels / split for img_p in sorted(img_dir.glob(*.jpg)): lbl_p lbl_dir / (img_p.stem .txt) if not lbl_p.exists(): print(f[標簽缺失] {img_p.name}) bad_count 1 continue for line in lbl_p.read_text().splitlines(): parts line.split() if len(parts) ! 5: print(f[格式錯誤] {img_p.name}: {line}) bad_count 1 continue cls parts[0] try: cx, cy, w, h map(float, parts[1:]) except ValueError: print(f[數值錯誤] {img_p.name}: {line}) bad_count 1 continue if not all(0 v 1 for v in (cx, cy, w, h)): print(f[坐標越界] {img_p.name}: {line}) bad_count 1 print(f檢查完成異常數量: {bad_count})邏輯并不復雜先用glob拿到所有 jpg 文件名用stem屬性去掉擴展名后拼出對應 txt 路徑再逐行解析先查字段數量再查數值范圍。坐標越界是最常見的問題之一比如手工標注時不小心把框拉出了畫布邊緣歸一化后出現大于 1 的值。如果異常數量為 0說明這份數據集在結構層面是干凈的可以進入訓練環(huán)節(jié)。如果報出一堆標簽缺失建議直接補一份空 txt 或者刪除對應圖像不要讓模型把無標簽區(qū)域當負樣本學。這條規(guī)則對所有計算機視覺數據集都適用尤其是做行業(yè)數據集復用時前人的標注習慣未必嚴謹自檢這一步不能省。3. 用 YOLOv12 把萌芽檢測模型跑通環(huán)境、參數與驗證3.1 訓練環(huán)境與數據集劃分YOLOv12 的訓練流程和整個 YOLO 系列基本一致主流做法還是基于 Ultralytics 框架。先裝好依賴pip install ultralytics albumentations如果你的 Ultralytics 版本還沒有收錄 YOLOv12 的預訓練權重可以先換成 yolov11n 或 yolov8n 驗證整套流程數據集本身不綁定特定模型版本標注格式是所有 YOLO 家族通用的。常見做法是先跑通小模型確認數據和標簽沒有問題再切換到大模型。數據集劃分前要注意一個容易被忽略的點如果原始圖像里存在同一苗盤的連拍序列直接隨機打散劃分 train/val 會造成圖片泄漏驗證指標虛高。按拍攝批次或時間先后切分例如前 80% 時間段的圖像進 train、后 20% 進 val才是模擬真實新場景的做法。這一點在工業(yè)農業(yè)醫(yī)學行業(yè)目標檢測數據集里尤其重要因為現場采集往往是一次性拍幾百張連圖。我會在數據目錄外新建一份數據集描述文件內容如下# plant_sprout.yaml path: ./plant_sprout train: images/train val: images/val nc: 2 names: [empty_hole, sprout]path寫數據集根目錄的相對路徑train、val相對于path填寫nc是類別總數names按類別順序列出。如果你的數據集是單類別把nc改成 1names只保留一個即可。3.2 訓練參數模板與說明下面是我平時訓練萌芽檢測時用的參數模板。YOLOv12 訓練入口與 YOLOv8/YOLOv11 風格一致下面這段按 Ultralytics 通用接口寫成from ultralytics import YOLO model YOLO(yolov12n.pt) model.train( dataplant_sprout.yaml, epochs120, imgsz640, batch16, lr00.01, lrf0.01, optimizerSGD, patience20, augmentFalse, seed42, )逐項解釋我的選擇理由epochs120是考慮到數據集規(guī)模不大給足迭代次數讓小目標框的 anchor 充分調整imgsz640兼顧顯存占用和大多數手機/工業(yè)相機圖片的分辨率比例如果圖像本身就是 1920×1080 的航拍圖建議直接提到 960 再訓練否則芽的像素面積會被壓縮到十幾像素batch16是 24GB 顯存的典型配置顯存小的機器降到 8lr00.01是 SGD 優(yōu)化器的常用初值配合patience20早停在驗證指標不再上升時自動保存最好權重augmentFalse是因為我習慣先跑一版不帶增強的基線確認數據和標簽正確再開增強。先解釋imgsz對小目標的影響。imgsz640意味著輸入圖像會被縮放到 640×640原本 4000×3000 的大圖里一個 40×40 像素的芽縮放后只剩約 6×6 像素幾乎在主干網特征圖上消失。第一版訓練如果發(fā)現漏檢嚴重優(yōu)先把imgsz提到 960 或 1280。再解釋augmentFalse的用意。Ultralytics 默認開啟 Mosaic、HSV 擾動等增強數據集本身存在標注偏差時很難判斷是增強過度還是模型欠擬合。先關閉增強跑一版干凈的再增開是我處理所有行業(yè)數據集的一貫順序。推理驗證的代碼也貼出來方便直接復現from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) results model.predict( sourcetest_images/, imgsz640, conf0.3, saveTrue, save_txtTrue, )conf0.3是出芽檢測場景比較合理的下限。芽體小、邊緣模糊置信度普遍比大目標低一截卡在 0.5 會漏掉大量真值save_txtTrue會把檢測結果存成 YOLO 格式文本方便后續(xù)統(tǒng)計每張圖的芽數。3.3 驗證指標怎么讀訓練結束后Ultralytics 會輸出一張 results.csv里面逐行記錄了每個 epoch 的 mAP50、mAP50-95、precision、recall。萌芽檢測這類小目標任務我更關注 recall 而不是 mAP。因為補苗場景里漏掉一個芽意味著空穴被當成有苗后期不會有人再補種損失更不可逆誤報多一個芽頂多補苗時多放一粒種子成本低得多。如果 recall 低于 0.85建議按第 4 章的方法加大輸入尺寸、調整增強策略。如果 precision 遠低于 recall再去排查是不是標注框偏大導致模型把背景也包了進來。我通常會從 results.csv 里抽最后 10 行的數據做判斷避免只看最佳權重那一個點。4. 數據增強與小目標優(yōu)化讓模型對現場光照更魯棒4.1 針對萌芽圖像的增強參數萌芽檢測的圖像大多在溫室或苗床拍攝光照條件受天氣、補光燈、遮陽網影響很大同一批苗在不同時段拍出來的色溫、亮度完全不同。模型需要對這些變化不敏感才能在現場穩(wěn)定工作。開啟增強時我比較關注下面這幾項model.train( dataplant_sprout.yaml, epochs120, imgsz960, batch8, hsv_h0.015, hsv_s0.6, hsv_v0.5, degrees15, translate0.1, scale0.4, fliplr0.5, flipud0.1, mosaic0.8, )hsv_v0.5允許亮度在正負一半的區(qū)間內隨機擾動溫室補光燈開啟和關閉時的亮度差異基本能被覆蓋hsv_h0.015只做輕微色相擾動避免把芽的綠色和土壤的黃色混到一起degrees15模擬相機安裝角度偏移苗盤在視野里稍微歪一點也能被識別。flipud0.1只給 10% 概率因為俯拍角度下圖像上下翻轉雖然物理上合理但如果現場苗盤有方向性紋理翻轉過多反而引入噪聲。Mosaic 增強會把四張圖拼成一張放大圖像中的上下文信息。對小目標檢測來說Mosaic 能顯著提升模型對“芽周圍土壤環(huán)境”的建模能力但也要注意如果標注框本身有偏差拼圖后偏差會被放大。我習慣把mosaic從默認的 1.0 降到 0.8給正常圖像留一些訓練比例。4.2 輸入尺寸、類別不平衡與困難樣本挖掘萌芽數據集普遍存在一個反直覺的現象類別不平衡不在“萌芽 vs 背景”而在“容易檢測的萌芽 vs 難檢測的萌芽”。剛破土而出的芽只有兩片子葉甚至只有一條縫面積小、對比度低和土壤顏色接近模型傾向于只學那些已經展開子葉、邊界清晰的大芽。針對這種困難樣本有兩個常見做法我經常組合使用。第一把輸入尺寸從 640 提到 960。萌芽框寬度占整圖的比例通常在 0.03 到 0.05 之間640 輸入下對應 19 到 32 像素屬于小目標但還不算極小960 輸入下能到 29 到 48 像素特征圖上的響應明顯增強。顯存不夠時用batch8或者開啟梯度累積也要上大圖尺寸這一步對小目標檢測的收益往往比調任何超參數都明顯。第二對低置信度樣本做二次標注加入訓練集。訓練完第一版模型后把驗證集里 recall 為 0 的圖像抽出來人工檢查是沒標還是標錯。常見情況是原數據集漏標了那些特別小的芽模型學到了正確特征但 label 里沒有對應框損失函數把正確的預測也當負樣本懲罰。把這些漏標補上再訓練一輪recall 通常能提升三到五個百分點。類別不均衡的處理則要看 yaml 里的 names 定義。如果你的數據集區(qū)分了empty_hole和sprout兩個類別且空穴數量遠多于芽數可以在采樣時對sprout類別的圖像做上采樣復制讓每個 epoch 里兩類目標出現的頻率接近。Ultralytics 沒有直接提供 per-class 采樣參數常見做法是提前在數據層面復制少數類圖像或者直接用外部腳本做重采樣。5. 避坑五個翻車現場與排查記錄5.1 損失正常下降驗證 mAP 卻一直是 0現象訓練日志里 box loss 從 0.08 慢慢降到 0.03看起來很健康但每個 epoch 結束后的 mAP50 和 recall 都停在 0 附近整張驗證集一個框都預測不出來。原因標簽文件路徑寫錯了。plant_sprout.yaml里train和val寫的是images/train和images/val但 Ultralytics 會默認去labels/train找同名 txt。如果 labels 目錄名大小寫不一致或者 txt 文件壓根沒放進去訓練時所有圖像都成了“無標簽”狀態(tài)模型學不到任何監(jiān)督信號損失下降只是背景知識的正常收斂。解決回到 2.3 的校驗腳本先統(tǒng)計 labels/train 下的 txt 數量確認和 images 數量一致。如果 txt 文件存在但訓練仍顯示 0 標簽打開其中一份看內容是否為空文件?？瘴募热笔募[蔽因為文件名對得上但沒有任何標注行模型依然拿不到監(jiān)督信號。5.2 預測框整體偏到芽旁邊的土壤上現象置信度挺高框也方方正正但框的中心點不在芽體上而是落在芽基部旁邊的土塊或基質上尤其是小芽特別明顯。原因標注框不夠緊。很多標注工具導出的框是矩形外接框如果標的時候圖省事把邊框劃大了幾像素芽體本身又小于 10 像素框中心點就會偏離目標區(qū)域。模型訓練過程中會學著預測這個“偏了的中心”最后輸出的預測自然也是偏的。解決我一般會抽查 50 張訓練圖把標注框畫回原圖看貼合度。如果固定偏移方向比如都是偏右下說明標注時統(tǒng)一出現了系統(tǒng)性偏差用腳本把所有標注按像素偏移修正再訓練。如果是隨機偏移就把這類邊界模糊的樣本找出來重新標注重點修那些面積小于 20×20 像素的框。5.3 剛破土的芽頻繁漏檢已展開子葉的芽都能檢出現象分類別統(tǒng)計時sprout類的 recall 明明有 0.92但實際看可視化推理結果漏掉的全是最小的那批芽很多只有三五個像素寬。原因這是典型的小目標在多尺度特征圖中響應不足。YOLO 系列的主干網絡下采樣倍數決定了最小檢測尺寸輸入 640 時P3 特征圖的 stride 是 8對應感受野大約 8 像素小于 8 像素的目標基本只能靠上下文推測難以形成穩(wěn)定的特征響應。解決兩個手段組合一是按 4.2 把imgsz提到 960 或 1280讓目標在輸入圖像里的像素面積變大二是用切圖推理。我常用的工具是 SAHISlicing Aided Hyper Inference把大圖切成 640×640 的重疊切片分別推理再合并結果能在不改訓練配置的情況下把 recall 拉高五到十個點。對萌芽檢測這種目標小、分布密的任務切圖推理幾乎是現場落地的保底方案。5.4 顯存不夠batch 調小后損失曲線劇烈震蕩現象24GB 顯卡跑batch16沒問題換到 8GB 顯卡只能batch4訓練損失從 0.05 到 0.11 來回跳驗證指標也不穩(wěn)定早停機制頻繁誤判。原因batch 太小的情況下BNBatch Normalization層的統(tǒng)計量計算不穩(wěn)定每批數據的均值和方差波動大梯度方向的噪聲也隨之放大。這在目標檢測的早期訓練階段尤其明顯因為前期 anchor 分配還在劇烈變化。解決優(yōu)先做梯度累積單卡上模擬出更大的 batch。Ultralytics 支持在訓練參數里通過batch和accumulate配合或者手動在優(yōu)化器層面累積梯度。其次把優(yōu)化器從 SGD 換成 AdamW它對小 batch 的適應性更好一些。如果兩者都不方便就強制凍結 backbone 前 10 層訓練只更新檢測頭能顯著降低顯存占用和梯度波動。5.5 驗證指標很好一到現場新場景就翻車現象訓練集和驗證集都是從同一次拍攝里隨機劃分的mAP50 到了 0.95結果到現場換了一批苗盤拍攝檢測率直接掉到 0.6 以下。原因隨機劃分造成數據泄漏。同一苗盤、同一時段拍攝的圖像之間高度相似模型記憶了這些圖像的紋理特征而不是“芽”本身的通用特征驗證集和訓練集太像導致評估結果虛高。解決所有行業(yè)數據集都應該按時間或場景做分組劃分而不是隨機打散。具體到這個數據集我會把所有圖像先按拍攝日期排序取前 80% 的圖像做訓練后 20% 做驗證。如果資源里沒帶時間信息就按文件名序號的大段切分保證同一個批次的連拍不會同時出現在訓練和驗證里。這個改動看起來小但對現場泛化能力的影響是決定性的。6. 訓練完成后我建議你在交付前強制走一遍的驗證流程模型訓練完不代表能用每年因為這個翻車的人不少。我自己的習慣是留出一個叫final_check的小目錄里面放 20 到 30 張與訓練集完全不同場景的圖片比如不同育苗盤的、不同光照下的甚至手機拍攝角度與工業(yè)相機不同的。每次訓練完不管驗證集指標多好看都要把這個目錄跑一遍推理肉眼檢查輸出結果。檢查時重點看兩類錯誤一類是漏檢模型對某個明顯的芽沒輸出任何框另一類是錯檢把土壤里的石子、基質顆?；蚩潭染€誤判成芽。前者說明泛化不足后者說明特征學習有偏差。漏檢多的回到第 4 章調輸入尺寸和增強錯檢多的往往是標注時把背景物體框了進去需要回查訓練集里有沒有類似的臟標簽。我還習慣把每張測試圖的置信度分布打印出來統(tǒng)計conf 0.3的檢測框數量占比。如果一張 640×640 的圖上模型輸出了上百個低置信度框說明模型對背景產生了過度敏感需要在后處理里把conf閾值往上提到 0.35 或 0.4同時檢查是不是訓練集里空穴類別樣本太少。最后分享一個我自己的血淚教訓有一次做實時的苗盤巡檢設備訓練階段只跑通了 YOLOv8 的默認配置沒有做小目標優(yōu)化結果拿到現場后漏檢率高出預期好幾倍。從那以后我每次訓練前都強制走一遍數據校驗、按場景劃分訓練集、開大輸入尺寸這三個步驟雖然多花一兩個小時但再也沒有出現過交付現場翻車的情況。這份植物萌芽檢測數據集本身標注得算規(guī)范但任何數據集到了自己手里都值得按這個流程過一次手希望我的經驗能幫你少走一段彎路。本文還有配套的精品資源點擊獲取