簡介這套YOLOv5打電話行為檢測方案面向需要快速落地行為識別項目的開發(fā)者與算法學(xué)習(xí)者解決模型訓(xùn)練門檻高、數(shù)據(jù)標(biāo)注繁瑣的問題。包內(nèi)含訓(xùn)練好的.pt權(quán)重文件、YOLOv5工程源碼、配套數(shù)據(jù)集標(biāo)簽同時提供txt與xml兩種格式可靈活用于YOLO系列訓(xùn)練或VOC格式處理PyQt5界面支持圖片、視頻和攝像頭實時檢測開箱即用適合課堂實訓(xùn)、畢業(yè)設(shè)計或安防場景二次開發(fā)。資源共165個文件以Python腳本、pyc、yaml配置、jpg/png圖像樣本、xml/txt標(biāo)簽、pt模型和ui界面文件為主另有mp4演示視頻整體約433.91MB。目前已有604人學(xué)習(xí)/瀏覽完整工程結(jié)構(gòu)便于按目錄復(fù)現(xiàn)訓(xùn)練流程參考博客還可查看數(shù)據(jù)集與檢測結(jié)果能幫助節(jié)省大量整理和調(diào)參時間。1. 一套能直接跑的YOLOv5打電話行為檢測方案難的不是訓(xùn)練而是這三樣先說結(jié)論YOLOv5打電話行為檢測這個組合項目結(jié)構(gòu)拆開就是“YOLOv5模型 訓(xùn)練好的權(quán)重 打電話數(shù)據(jù)集 PyQt界面”四塊聽著像拼積木真正落地時模型訓(xùn)練只占三分之一工作量數(shù)據(jù)集的質(zhì)量和PyQt界面能不能流暢跑起來才是大頭。我見過不少團(tuán)隊拿開源模型跑兩天就換方案翻車點(diǎn)根本不在mAP而在“打電話”這個動作怎么定義——是手機(jī)出現(xiàn)在畫面里就算還是手機(jī)必須貼著耳朵才算這個標(biāo)準(zhǔn)沒定清楚訓(xùn)練出來的模型就處在薛定諤的可用狀態(tài)。這篇文章把我做過的方案講透從打電話數(shù)據(jù)集的構(gòu)成、標(biāo)注規(guī)則、YOLOv5訓(xùn)練參數(shù)到PyQt界面怎么不卡殼地實時出框再到驗收時看什么指標(biāo)、發(fā)布埋了哪些雷。適合做運(yùn)輸安全監(jiān)控、工地紀(jì)律檢測、考場行為分析以及想把手頭YOLOv5模型接進(jìn)桌面程序的工程師照著復(fù)現(xiàn)。2. 打電話行為檢測的技術(shù)選型為什么用YOLOv5而不是圖像分類2.1 打電話檢測不是圖像分類先定檢測目標(biāo)再談類別“檢測打電話”在計算機(jī)視覺里其實是一個復(fù)合任務(wù)它同時包含兩個子問題人在哪里以及這個人是否處于打電話狀態(tài)。純圖像分類模型只能回答“這張圖里有沒有人打電話”回答不了“畫面里三個正在打電話的人分別在哪個位置”更扛不住攝像頭視野里同時出現(xiàn)多人、多姿態(tài)的場景。YOLOv5是單階段目標(biāo)檢測模型一個模型同時輸出目標(biāo)框、類別和置信度天然適合“定位分類”的需求所以拿來做打電話行為檢測是合理的。真正讓這個任務(wù)難的不是模型選型而是“打電話”這個類別的類內(nèi)差異。打電話的姿態(tài)至少有三種手機(jī)緊貼耳朵、手機(jī)舉在耳邊還沒貼上、拿著手機(jī)低頭看屏幕負(fù)樣本更麻煩手拿飲料、手夾煙、手扶方向盤、摸頭發(fā)都可能被模型誤判成“手持手機(jī)”。也就是說模型要學(xué)的是“手機(jī)與頭部區(qū)域的空間關(guān)系”而不是“畫面里有沒有一塊矩形物體”。很多新手直接把公開的人手檢測模型拿來當(dāng)打電話檢測用結(jié)果誤報率高得沒法看原因就在這個建模思路上。所以在做數(shù)據(jù)集標(biāo)注之前得先把類別體系想清楚。我的做法是拆成三個類別phone手持手機(jī)但沒打電話、call手機(jī)貼耳或舉在耳邊、person人體全身框。不要只標(biāo)一個“打電話”類別因為標(biāo)注的人對“打電話”的判斷標(biāo)準(zhǔn)不一致模型學(xué)到的邊界就會漂移。多一個phone做硬負(fù)樣本等于主動告訴模型“手里有東西和正在打電話是兩回事”。2.2 YOLOv5s、v5m、v5l怎么選顯存、幀率與精度的天平Y(jié)OLOv5官方倉庫提供了s、m、l、x四檔模型對應(yīng)參數(shù)量和推理速度的取舍。打電話檢測場景通常部署在監(jiān)控工控機(jī)或者普通辦公電腦上很少用得上x檔。我一般只在s和m之間選訓(xùn)練好的模型權(quán)重文件也不大分發(fā)成本低。模型參數(shù)量權(quán)重大小640分辨率算力我的最低顯存建議YOLOv5s7.2M14MB16.5 GFLOPs4GB可跑batch 16YOLOv5m21.2M42MB49.0 GFLOPs6GB以上穩(wěn)妥YOLOv5l46.5M92MB109.1 GFLOPs8GB勉強(qiáng)不推薦這里的GFLOPs是YOLOv5官方給出的640分辨率下的理論計算量實際部署時還受顯卡、輸入分辨率影響。選擇邏輯很簡單打電話檢測對框的精細(xì)程度要求不高但對幀率敏感因為后續(xù)還要做時序判定幀率低于10FPS會導(dǎo)致“打電話”這個狀態(tài)在連續(xù)幀上斷斷續(xù)續(xù)。攝像頭分辨率是1080P時推流到模型前通常要縮到640×640YOLOv5s在GTX 1660上能跑到40FPS以上m檔會掉到25FPS左右。如果部署機(jī)器只有核顯或者老式工控機(jī)s檔幾乎是唯一選擇。低顯存環(huán)境下還有一條路訓(xùn)練時用s檔推理時把輸入分辨率從640降到480顯存占用能再降三分之一。代價是小目標(biāo)遠(yuǎn)處的手機(jī)漏檢率上升適合人物離攝像頭較近的室內(nèi)場景。如果你手里的機(jī)器連4GB顯存都沒有那別碰m和l老老實實s檔加CPU推理后面講PyQt界面時會給出對應(yīng)的優(yōu)化策略。2.3 三件套的分工檢測模型負(fù)責(zé)看見邏輯層負(fù)責(zé)判讀界面負(fù)責(zé)交互整個YOLOv5打電話檢測項目的主流程可以畫成一條線視頻幀進(jìn)入YOLOv5模型輸出每個人的框、每個手機(jī)的框以及它們的類別接著進(jìn)入一段后處理邏輯判斷手機(jī)框和人體框或頭部區(qū)域之間的位置關(guān)系記錄連續(xù)多幀的檢測結(jié)果最后PyQt界面負(fù)責(zé)把畫面、檢測框、狀態(tài)文字實時渲染出來。這里有個關(guān)鍵設(shè)計決定打電話判定的空間基準(zhǔn)到底用人體框還是頭部框。如果攝像機(jī)安裝角度是平視或微俯視頭部區(qū)域大約在人體框的上三分之一處直接用人體框的比例去估算耳朵位置即可如果攝像頭是高位俯拍比如走廊頂裝攝像頭手機(jī)遮擋頭部嚴(yán)重人體框的上邊緣根本對不準(zhǔn)耳朵這時候得單獨(dú)訓(xùn)練一個人頭檢測器配合使用。做運(yùn)輸監(jiān)控時我常用的是人體框方案因為道路槍機(jī)抓的是車身中景人頭上方有較多留白估出來的頭部區(qū)域還算穩(wěn)定。時序判定是容易被忽略的一層。單幀模型輸出噪聲很大一個“手拿手機(jī)”的姿態(tài)可能連續(xù)幾幀被誤判為“call”單幀就報警的話系統(tǒng)會不停誤報。常見的做法是維護(hù)一個長度為10幀的滑動窗口窗口內(nèi)call類別出現(xiàn)7幀以上才確認(rèn)一次“正在打電話”連續(xù)3幀無call則解除狀態(tài)。這一層邏輯放在檢測模型的輸出之后、PyQt界面渲染之前代碼量不大但能把誤報率壓下去一大截。3. 從打電話數(shù)據(jù)集到能用的模型數(shù)據(jù)清洗、標(biāo)注規(guī)則與訓(xùn)練參數(shù)全流程3.1 數(shù)據(jù)從哪里來、怎么篩公開數(shù)據(jù)集與自采數(shù)據(jù)混排打電話數(shù)據(jù)集可以從兩個渠道湊齊公開數(shù)據(jù)集和自采數(shù)據(jù)。公開的駕駛分心數(shù)據(jù)集比如Kaggle上的State Farm Distracted Driver Detection里有大量“打電話”和“發(fā)短信”的標(biāo)注圖片畫面是車內(nèi)攝像頭對著駕駛員拍的類別和“打電話”高度相關(guān)另一種常見來源是國內(nèi)博客和網(wǎng)盤上有人整理過的“打電話行為檢測”數(shù)據(jù)集下載后注意看清楚標(biāo)注格式有的是VOC的XML有的是COCO的JSON需要統(tǒng)一轉(zhuǎn)成YOLO需要的txt格式才能訓(xùn)練。先把公開數(shù)據(jù)集拉過來看一遍篩掉清晰度太差、過曝、目標(biāo)被大面積遮擋的圖片。自采數(shù)據(jù)的價值在于對齊部署場景。公開數(shù)據(jù)集大多是車內(nèi)視角如果你要監(jiān)控的是辦公室或者工地畫面里人物大小、攝像頭俯仰角都和公開數(shù)據(jù)集差很遠(yuǎn)直接用公開數(shù)據(jù)訓(xùn)練換個場景就漏檢。我的做法是拿手機(jī)在學(xué)校附近天橋、辦公室通道錄幾段5到10分鐘的視頻人走動、打電話、玩手機(jī)、正常行走混著來抽幀后加入數(shù)據(jù)集讓模型見過目標(biāo)場景的真實光線和視角。自采數(shù)據(jù)不用太多占到總量的20%到30%就能明顯改善場景遷移的落差。數(shù)據(jù)清洗定三條硬規(guī)則第一刪除有明顯噪點(diǎn)、運(yùn)動模糊到看不出手機(jī)輪廓的圖片這類樣本會讓模型在訓(xùn)練時學(xué)習(xí)到錯誤的紋理特征第二檢查有沒有“標(biāo)簽與畫面完全對不上”的臟數(shù)據(jù)公開數(shù)據(jù)集里時?；熘鴺?biāo)簽錯位的樣本不篩掉的話訓(xùn)練損失會異常抖動第三正負(fù)樣本比例控制住正樣本call和負(fù)樣本沒在打電話的人至少要做到1比3純正樣本訓(xùn)練出來的模型會把一切手部動作都當(dāng)成打電話。3.2 標(biāo)注規(guī)則三個類別的邊界怎么劃才不翻車標(biāo)注環(huán)節(jié)是整個項目里最耗時也最影響上限的步驟。我推薦用CVAT或者labelImg工具不重要規(guī)則才重要。三個類別的判定標(biāo)準(zhǔn)在動手標(biāo)注前就要和參與標(biāo)注的人對齊否則每個人標(biāo)出來的框五花八門。phone類手機(jī)出現(xiàn)在畫面里無論手持、放在桌上、放在腿上都算但只要手機(jī)清晰可見就得框。這個類別存在的意義是給模型提供“手機(jī)”這個物體的基礎(chǔ)特征讓模型先學(xué)會找手機(jī)再去判斷手機(jī)和頭部的關(guān)系。call類手機(jī)貼耳、手機(jī)與耳朵在同一焦平面并發(fā)生遮擋關(guān)系、手機(jī)舉著但明顯停在耳邊位置這三種姿態(tài)都算call。關(guān)鍵判斷點(diǎn)是“手機(jī)是否在頭部區(qū)域內(nèi)或緊貼頭部邊緣”而不是“手有沒有抬起來”因為戴耳機(jī)打電話手可以完全垂著。person類全身框不需要框得太緊背后的一些背景可以帶進(jìn)來這有助于模型理解人物和遠(yuǎn)景之間的關(guān)系。還有一個容易犯的錯誤是框的范圍。手機(jī)框一定要只標(biāo)手機(jī)本體不要包住整只手。很多人圖省事把手機(jī)和手一起框成一個大矩形訓(xùn)練出來的模型會對“手的形狀”產(chǎn)生過擬合換個人戴不同顏色的手套就開始漏檢。call類的框也是這樣只需要把手機(jī)框住不需要體現(xiàn)手或臉的位置空間關(guān)系由模型自己去學(xué)習(xí)。一張圖里界乎于“靠近但沒貼耳”的模糊姿態(tài)寧可標(biāo)成phone也不要標(biāo)call這樣可以訓(xùn)練出更嚴(yán)格的分類邊界。3.3 數(shù)據(jù)劃分腳本一份可以抄的YOLO格式切分代碼YOLOv5訓(xùn)練時要求圖片和標(biāo)簽文件同名圖片放在images目錄標(biāo)簽放在labels目錄目錄結(jié)構(gòu)按數(shù)據(jù)集劃分成train和val即可。這個腳本把原始圖片目錄和標(biāo)注目錄按比例隨機(jī)切分到新的數(shù)據(jù)集目錄固定隨機(jī)種子保證每次劃分結(jié)果一致。import os import random import shutil def split_dataset(image_dir, label_dir, output_dir, val_ratio0.15, test_ratio0.05, seed42): random.seed(seed) images [f for f in os.listdir(image_dir) if f.endswith((.jpg, .png, .jpeg))] random.shuffle(images) n len(images) n_val int(n * val_ratio) n_test int(n * test_ratio) splits { train: images[n_val n_test:], val: images[:n_val], test: images[n_val:n_val n_test], } for split_name, imgs in splits.items(): img_out_dir os.path.join(output_dir, split_name, images) lbl_out_dir os.path.join(output_dir, split_name, labels) os.makedirs(img_out_dir, exist_okTrue) os.makedirs(lbl_out_dir, exist_okTrue) for img_name in imgs: base os.path.splitext(img_name)[0] shutil.copy2(os.path.join(image_dir, img_name), os.path.join(img_out_dir, img_name)) shutil.copy2(os.path.join(label_dir, base .txt), os.path.join(lbl_out_dir, base .txt)) for split_name, imgs in splits.items(): print(f{split_name}: {len(imgs)} 張) if split_name val: print(f驗證集圖片總數(shù): {len(imgs)}) if __name__ __main__: split_dataset(raw_images/, raw_labels/, phone_dataset/)腳本邏輯不復(fù)雜但有幾個細(xì)節(jié)值得說明。隨機(jī)種子固定為42這樣反復(fù)執(zhí)行切分結(jié)果一致團(tuán)隊協(xié)作時不會各切各的。圖片和標(biāo)簽用copy2而不是rename保留原始數(shù)據(jù)做備份因為后期發(fā)現(xiàn)標(biāo)注錯誤還要回頭改。驗證集比例取15%對幾千張的中等規(guī)模數(shù)據(jù)集夠用了測試集單獨(dú)切出一份5%放一邊最后驗收模型時才用避免訓(xùn)練過程里反復(fù)看測試集導(dǎo)致過度擬合。3.4 寫data.yaml并啟動訓(xùn)練這些超參值得一個個調(diào)數(shù)據(jù)準(zhǔn)備好后寫一個data.yaml描述數(shù)據(jù)集路徑和類別信息train: ./phone_dataset/train/images val: ./phone_dataset/val/images test: ./phone_dataset/test/images nc: 3 names: [phone, call, person]路徑用相對路徑時要確保是相對于你執(zhí)行訓(xùn)練命令的目錄而言建議直接在YOLOv5倉庫根目錄下運(yùn)行data.yaml放在根目錄或指定路徑都可以。names的順序必須與標(biāo)注txt里的類別編號一一對應(yīng)這里phone是0call是1person是2標(biāo)注腳本里生成txt時就要按這個編號寫入。訓(xùn)練命令如下python train.py \ --data phone_data.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --cache ram \ --patience 20逐項拆解參數(shù)的含義。--weights yolov5s.pt表示加載COCO預(yù)訓(xùn)練權(quán)重這不是偷懶而是用別人已經(jīng)學(xué)好的底層視覺特征做初始化能大幅縮短訓(xùn)練時間在中小規(guī)模數(shù)據(jù)集上幾乎不會帶來負(fù)面效果。--img 640是訓(xùn)練時隨機(jī)縮放的基準(zhǔn)分辨率如果攝像頭畫面里手機(jī)目標(biāo)很小可以提高到960或1280但顯存占用和推理延遲都翻倍建議先用640跑通全流程再調(diào)這個值。--cache ram把訓(xùn)練集圖片一次性緩存到內(nèi)存中避免每個epoch都從磁盤重新讀圖訓(xùn)練速度提升明顯前提是內(nèi)存夠大幾千張圖大概需要8GB到12GB內(nèi)存。--patience 20是早停機(jī)制連續(xù)20個epoch驗證集損失沒有下降就自動停止訓(xùn)練防止模型過擬合之后還繼續(xù)空轉(zhuǎn)。關(guān)于超參數(shù)YOLOv5默認(rèn)的anchor基本不用調(diào)打電話數(shù)據(jù)集的物體比例非常穩(wěn)定默認(rèn)anchor能覆蓋大部分框的形狀。真正值得動的是mosaic增強(qiáng)的開啟程度如果訓(xùn)練數(shù)據(jù)來自同一個監(jiān)控攝像頭場景高度重復(fù)可以把mosaic保持默認(rèn)并在訓(xùn)練后期用--multi-scale增強(qiáng)尺度多樣性如果數(shù)據(jù)來自多個不同場景mosaic的作用就沒那么大了。3.5 訓(xùn)練后看什么指標(biāo)別只盯著loss訓(xùn)練結(jié)束后YOLOv5會在runs/train/exp/weights/目錄下生成best.pt和last.ptbest.pt是驗證集上表現(xiàn)最好的權(quán)重last.pt是最后一個epoch的權(quán)重部署時一定選best.pt。打開runs/train/exp目錄下的results.png重點(diǎn)看三條曲線訓(xùn)練損失、驗證損失、驗證集mAP0.5。對打電話檢測這個任務(wù)我通常把mAP0.5作為主要驗收指標(biāo)0.5的交并比閾值意味著不需要框非常精準(zhǔn)只要大概框住手機(jī)就能算對的框。實際部署時置信度閾值會卡在0.25到0.4之間所以mAP0.5比mAP0.5:0.95更有參考意義。另一個要重點(diǎn)看的是混淆矩陣YOLOv5訓(xùn)練結(jié)束會在runs/train/exp目錄下輸出confusion_matrix.png如果call類別大量被識別成phone說明標(biāo)注里“貼耳”和“沒貼耳”的邊界樣本太少回去補(bǔ)充這類數(shù)據(jù)比調(diào)參有用得多。4. 把訓(xùn)練好的YOLOv5接進(jìn)PyQt界面視頻流、QThread與實時畫框4.1 PyQt界面的三個基本件窗口、畫面標(biāo)簽、控制按鈕PyQt部分不用做得多花哨一個能工作的桌面工具只需要三樣?xùn)|西主窗口QMainWindow、顯示視頻畫面的QLabel、控制啟停的QPushButton。主窗口左側(cè)放按鈕和狀態(tài)信息右側(cè)放畫面標(biāo)簽布局用QVBoxLayout或者QHBoxLayout都可以。攝像頭來源可以直接用OpenCV的VideoCapture設(shè)備號0表示第一個攝像頭也可以支持傳入視頻文件路徑方便直接用錄制好的測試視頻驗證模型效果。界面邏輯上要注意的一點(diǎn)模型加載放在界面初始化階段而不是點(diǎn)擊“開始檢測”之后。YOLOv5模型初始化需要加載權(quán)重、構(gòu)建網(wǎng)絡(luò)結(jié)構(gòu)耗時從幾秒到十幾秒不等放在按鈕響應(yīng)里會讓界面陷入無響應(yīng)狀態(tài)。更規(guī)范的寫法是初始化界面時就把模型加載成全局或類成員變量點(diǎn)擊按鈕后只是拉起一個視頻循環(huán)線程。這樣用戶打開程序后點(diǎn)擊開始就能立刻看到畫面體驗好很多。狀態(tài)信息區(qū)可以放兩個標(biāo)簽一個是實時推理耗時顯示每幀處理多少毫秒另一個是檢測狀態(tài)顯示當(dāng)前是否判定為“正在打電話”。這兩個數(shù)據(jù)對調(diào)試和驗收都非常重要推理耗時能直觀反映模型和分辨率選型是否合理檢測狀態(tài)則能驗證時序判定邏輯是否生效。4.2 用QThread跑推理為什么不能把detect寫在UI線程PyQt最經(jīng)典的翻車現(xiàn)場就是新手把while循環(huán)和模型推理直接寫進(jìn)按鈕的槽函數(shù)結(jié)果程序一啟動攝像頭畫面就卡住窗口拖不動、按鈕點(diǎn)不了。原因是UI線程被推理循環(huán)阻塞住了Qt的事件循環(huán)無法處理窗口繪制和鼠標(biāo)事件。解決辦法是把視頻讀取和模型推理放進(jìn)QThread子線程通過信號把結(jié)果傳回主線程更新界面。import cv2 import time from PyQt5.QtCore import QThread, pyqtSignal class DetectWorker(QThread): frame_ready pyqtSignal(object, list, float) error pyqtSignal(str) def __init__(self, model, source0, parentNone): super().__init__(parent) self.model model self.source source self.running True def run(self): cap cv2.VideoCapture(self.source) if not cap.isOpened(): self.error.emit(無法打開攝像頭或視頻文件) return while self.running: ok, frame cap.read() if not ok: break t0 time.time() results self.model(frame) # 提取 x1, y1, x2, y2, confidence, class_id dets results.xyxy[0].cpu().numpy() spend time.time() - t0 self.frame_ready.emit(frame, dets, spend) cap.release() def stop(self): self.running False self.wait()這段代碼里值得注意的地方有幾個。results.xyxy[0]返回的是一個包含所有檢測結(jié)果的tensor維度是N×6分別是x1、y1、x2、y2、置信度、類別索引。.cpu().numpy()把它轉(zhuǎn)成numpy數(shù)組方便在主線程直接遍歷。這里沒有用pandas().xyxy[0]因為pandas解析會慢一些在實時推理循環(huán)里每幀多花幾毫秒對幀率敏感的場景屬于不必要的開銷。frame_ready信號攜帶原始幀、檢測結(jié)果、推理耗時三個數(shù)據(jù)一次性傳給主線程避免多信號之間的時序錯亂。線程停止的寫法也需要注意。self.running False只是一個標(biāo)志位如果模型推理一幀超過幾秒比如CPU推理大圖stop()方法里的wait()會等到當(dāng)前循環(huán)結(jié)束才返回界面會短暫無響應(yīng)。改進(jìn)方式是設(shè)置一個超時時間或者在run循環(huán)里多次檢查running標(biāo)志但實際場景中幾百毫秒的等待用戶基本無感可接受。4.3 主線程畫框坐標(biāo)映射的坑檢測結(jié)果里的坐標(biāo)是相對于原始視頻幀的而QLabel顯示的尺寸很可能和原始幀不匹配尤其是用戶拖拽窗口改變布局后。直接在原始坐標(biāo)上畫矩形再縮放顯示會導(dǎo)致框的偏移和變形。必須先計算顯示區(qū)域的縮放比例再映射坐標(biāo)。def update_frame(self, frame, dets, spend): h, w frame.shape[:2] label_w self.video_label.width() label_h self.video_label.height() scale_x label_w / w scale_y label_h / h # OpenCV讀進(jìn)來的是BGRQImage需要RGB display cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) for det in dets: conf det[4] cls_id int(det[5]) if conf 0.35: continue x1, y1 int(det[0] * scale_x), int(det[1] * scale_y) x2, y2 int(det[2] * scale_x), int(det[3] * scale_y) # 類別1對應(yīng)call綠色顯示其他類別黃色 color (0, 255, 0) if cls_id 1 else (0, 255, 255) cv2.rectangle(display, (x1, y1), (x2, y2), color, 2) label_text f{self.names[cls_id]} {conf:.2f} cv2.putText(display, label_text, (x1, max(0, y1 - 8)), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color, 2) h2, w2 display.shape[:2] qimg QImage(display.data, w2, h2, 3 * w2, QImage.Format_RGB888) self.video_label.setPixmap(QPixmap.fromImage(qimg).scaled( self.video_label.size(), Qt.KeepAspectRatio, Qt.SmoothTransformation))坐標(biāo)映射的關(guān)鍵在于scale_x和scale_y這兩個值是用顯示控件當(dāng)前尺寸除以原始幀的寬高得到的。使用QLabel的當(dāng)前寬高而不是固定值是為了支持窗口縮放后框依然對齊。顏色按類別區(qū)分很實用call類用綠色phone類用黃色一眼就能看出模型當(dāng)前狀態(tài)下正在檢測什么。cv2.putText的坐標(biāo)Y方向需要減去一個像素偏移否則文字會蓋在框線上閱讀體驗差。QImage構(gòu)造函數(shù)的第三個參數(shù)傳入3 * w2表示每一行像素占用的字節(jié)數(shù)。這里最容易踩坑的是忘了把BGR轉(zhuǎn)成RGB直接拿OpenCV的原始幀構(gòu)造QImage畫面會出現(xiàn)偏藍(lán)和偏橙的詭異顏色。轉(zhuǎn)換那行cv2.cvtColor不能省。4.4 打電話狀態(tài)的時序確認(rèn)邏輯模型輸出的是單幀的檢測結(jié)果直接用會導(dǎo)致報警狀態(tài)頻繁抖動。我在前面提到滑動窗口的時序判定這里給出具體代碼實現(xiàn)class CallStateJudge: def __init__(self, window_size10, threshold7): self.window [] self.window_size window_size self.threshold threshold def update(self, has_call): 每幀調(diào)用一次傳入本幀是否檢測到call類別 self.window.append(has_call) if len(self.window) self.window_size: self.window.pop(0) confirmed sum(self.window) self.threshold return confirmed使用方式是在主線程的update_frame槽函數(shù)里判斷當(dāng)前幀是否存在類別為call的檢測結(jié)果把布爾值傳給CallStateJudge.update()。返回True時界面狀態(tài)欄顯示“正在打電話”同時可以觸發(fā)寫入日志或抓圖保存。窗口大小10幀、閾值7幀這兩個參數(shù)對應(yīng)的是“10幀里至少7幀檢出call才確認(rèn)”的規(guī)則既過濾了偶發(fā)誤檢又能容忍單幀漏檢。如果攝像頭幀率是30FPS這個窗口對應(yīng)約0.33秒確認(rèn)延遲是可以接受的。5. 避坑YOLOv5打電話檢測項目里最具迷惑性的5個坑5.1 “手機(jī)放桌上”也被識別為call類別邊界標(biāo)歪了現(xiàn)象模型訓(xùn)練完推理時一個放在桌面上、沒人碰觸的手機(jī)被標(biāo)成call觸發(fā)報警。最開始我以為是模型過擬合把置信度閾值從0.25調(diào)到0.5也擋不住。原因查了訓(xùn)練集的標(biāo)注后發(fā)現(xiàn)標(biāo)注的人把“手機(jī)在畫面中靠近人物”的樣本都標(biāo)成了call而沒有嚴(yán)格按照“手機(jī)與頭部接觸”的標(biāo)準(zhǔn)。模型的注意力被帶偏學(xué)到的是“畫面里有手機(jī)且離人近”就是call桌面手機(jī)自然中招。解決把這類樣本的標(biāo)注全部改回phone同時補(bǔ)充一批“手機(jī)在桌面、在手里但沒有舉到耳邊”的負(fù)樣本。改完之后重新訓(xùn)練call混淆到phone的量明顯下降。這個事說明標(biāo)注規(guī)則手冊必須細(xì)化到“貼耳才算call”這種程度否則交付的模型就是薛定諤的。5.2 低頭看手機(jī)完全漏檢手機(jī)屏幕被遮擋現(xiàn)象正面機(jī)位拍到的畫面里人物低頭看手機(jī)模型既沒檢出phone也沒檢出call直接放過去了。從人體姿態(tài)來看人確實在操作手機(jī)但目標(biāo)檢測模型依賴的是手機(jī)這個物體本身的外形特征。原因低頭場景下手機(jī)屏幕與攝像頭視角接近垂直屏幕紋理丟失手機(jī)的輪廓幾乎是一條線加上手部遮擋模型提取不到足夠特征。這不是模型訓(xùn)練的問題是成像角度造成的物理限制。解決常見做法是調(diào)整攝像頭安裝位置用下壓式俯拍或側(cè)方機(jī)位讓手機(jī)屏幕不被完全遮擋如果機(jī)位固定沒法調(diào)整就要在界面邏輯里加入姿態(tài)輔助判定比如“長時間低頭且雙手靠攏”也作為疑似打電話的提示但結(jié)果標(biāo)記為待人工確認(rèn)而不是直接報警。將檢測和判定做成兩個層面能降低漏報帶來的安全風(fēng)險。5.3 訓(xùn)練loss能降到0.02測試集上誤報卻一個接一個現(xiàn)象訓(xùn)練過程看起來非常漂亮loss曲線一路下降mAP0.5超過0.9但換一段真實攝像頭錄的視頻跑誤報率高到不堪入目。這應(yīng)該是很多人在訓(xùn)練自己的數(shù)據(jù)集時碰到過的最困惑的問題。原因把驗證集和測試集切成同分布了驗證集圖像和訓(xùn)練集圖像來自同一批數(shù)據(jù)模型從這里學(xué)到了復(fù)制粘貼式的記憶而非泛化能力。前面切分腳本里專門保留5%的test目錄就是用來做這個隔離的。解決訓(xùn)練完成后把test目錄里的圖片單獨(dú)跑一遍推理統(tǒng)計結(jié)果。如果test上的mAP明顯低于val說明模型過擬合訓(xùn)練集分布回去補(bǔ)數(shù)據(jù)或增強(qiáng)正則化。更進(jìn)一步用錄制的一段真實場景視頻跑端到端測試不只看mAP還要統(tǒng)計誤報數(shù)和漏報數(shù)這才是發(fā)布的真實基線。5.4 PyQt界面花屏或顏色怪異RGB與BGR沒轉(zhuǎn)現(xiàn)象界面能顯示畫面但整個圖像顏色嚴(yán)重偏藍(lán)、發(fā)黃或者出現(xiàn)像素錯位的花屏。有時窗口一拖動畫面直接變成橫條紋像是編碼格式錯了。原因OpenCV讀取視頻幀返回的是BGR三通道排列而QImage默認(rèn)接收的是RGB排列直接構(gòu)造QImage不轉(zhuǎn)換通道順序就會偏色QImage構(gòu)造時第三個參數(shù)每行字節(jié)數(shù)寫錯比如寫成3而不是3*w就會導(dǎo)致每一行像素錯位成花屏。解決構(gòu)造QImage之前先cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)。每行字節(jié)數(shù)寫成3 * w對RGB888格式來說是固定的。如果用了QPixmap.fromImage(qimg)顯示后畫面方向不對檢查VideoCapture的寬高設(shè)置再不行就用qimage.mirrored()修正鏡像。5.5 推理循環(huán)越來越慢最終只剩3FPS現(xiàn)象開頭的50幀運(yùn)行流暢后面越來越卡接近一分鐘時幀率掉到個位數(shù)CPU占用接近滿載?？雌饋硐袷悄Ｐ屯评肀旧淼膯栴}其實是內(nèi)存管理問題。原因YOLOv5模型每幀推理產(chǎn)生的tensor對象沒有得到有效的回收累計在內(nèi)存里。另一個可能因素是OpenCV的VideoCapture緩沖隊列積壓攝像頭幀不斷往內(nèi)存塞推理速度跟不上讀取速度積壓越來越多。解決在run循環(huán)里把每幀的中間變量用局部變量接收不持有引用推理結(jié)果通過signal傳給主線程后立即釋放。對視頻文件讀取用cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)把緩沖隊列壓到最小讓攝像頭幀只保留最新一幀丟掉處理不過來的舊幀。還有一個實用的做法是每次循環(huán)末尾調(diào)用cv2.waitKey(1)釋放底層資源這個函數(shù)會觸發(fā)OpenCV內(nèi)部事件處理幫助釋放部分緩存。6. 發(fā)布前的最后一公里精度復(fù)測、ONNX導(dǎo)出與模型瘦身6.1 用一段沒見過的真實視頻做端到端驗收測試集圖測完不等于模型可以上線真正的驗收是錄一段部署場景的視頻逐幀跑完整推理鏈路統(tǒng)計兩個核心數(shù)字誤報次數(shù)和漏報次數(shù)。我的習(xí)慣是錄5分鐘正樣本視頻和5分鐘負(fù)樣本視頻正樣本視頻里人在正常打電話、玩手機(jī)、喝水負(fù)樣本視頻里人只是走路交談、看文件。跑一遍后如果負(fù)樣本視頻里觸發(fā)報警超過2次就需要回到時序判定層去提高確認(rèn)閾值如果正樣本視頻里“打電話”狀態(tài)的檢出幀數(shù)低于80%就說明模型的召回不夠要考慮降低置信度閾值或補(bǔ)充訓(xùn)練數(shù)據(jù)。這個階段要記錄的信息不止報警次數(shù)還有一個容易被忽略的指標(biāo)確認(rèn)延遲。從畫面里人物第一次把手機(jī)舉到耳邊到界面亮出報警中間經(jīng)過了多少幀。延遲過長會讓保安或管理人員覺得系統(tǒng)不靈敏一般目標(biāo)控制在0.5秒以內(nèi)。如果延遲超標(biāo)檢查是不是時序確認(rèn)窗口設(shè)得太長或者推理幀率太低導(dǎo)致狀態(tài)切換變慢。6.2 導(dǎo)出ONNX并切換成CPU推理PyTorch模型文件在部署機(jī)器上跑推理需要安裝對應(yīng)版本的PyTorch依賴體積大且顯存占用高。導(dǎo)出成ONNX后可以用ONNX Runtime做推理CPU和GPU都能跑依賴小很多啟動速度也更快。YOLOv5官方倉庫直接提供導(dǎo)出腳本。python export.py --weights best.pt --include onnx --opset 12opset 12是ONNX算子集的版本新版ONNX Runtime對opset 12的支持非常成熟不會出現(xiàn)算子兼容問題。導(dǎo)出后會生成best.onnx文件在Python里加載推理import onnxruntime as ort import numpy as np session ort.InferenceSession(best.onnx, providers[CPUExecutionProvider]) def infer_onnx(frame): # 預(yù)處理縮放、歸一化、通道轉(zhuǎn)換 img cv2.resize(frame, (640, 640)) img img[:, :, ::-1].transpose(2, 0, 1)[None].astype(np.float32) / 255.0 outputs session.run(None, {session.get_inputs()[0].name: img}) return outputs[0]這段推理代碼返回的outputs[0]形狀是1×25200×6其中25200是YOLOv5在640分辨率下的默認(rèn)anchor數(shù)量需要經(jīng)過非極大值抑制才能得到最終的框。ONNX Runtime在無顯卡的工控機(jī)上跑YOLOv5s的640分辨率通常能達(dá)到15到25FPS對打電話檢測這種人員動作變化慢的場景已經(jīng)夠用。如果你部署的機(jī)器是樹莓派或其他ARM開發(fā)板這個導(dǎo)出方案同樣適用性能取決于內(nèi)存帶寬和CPU核心數(shù)。6.3 模型瘦身與幀間隔策略模型部署的前沿優(yōu)化有三個方向按投入產(chǎn)出比排序。第一是降低輸入分辨率把640降到480推理時間能縮短三成到四成代價是遠(yuǎn)距離小目標(biāo)的召回下降。在做通話檢測時如果攝像頭距離人物在3米以內(nèi)降到480完全可接受。第二是跳幀檢測每2幀做一次完整推理中間幀直接復(fù)用上一幀的檢測框配合簡單的IoU追蹤用戶看起來畫面是連貫的實際推理量減半。這個方案部署成本最低普通工控機(jī)也能跑出實時效果。第三是INT8量化用ONNX Runtime的量化接口把模型從FP32壓到INT8體積縮小為原來的四分之一推理速度在CPU上能再翻一倍打電話檢測對框精度不敏感量化掉的那點(diǎn)精度損失幾乎無感推薦做。每次模型更新迭代之后保留上一次的best.pt和量化后的ONNX文件在驗證視頻上做回歸測試確認(rèn)新版本沒有引入新的誤報類型。這個習(xí)慣幫我擋掉過好幾次上線前才發(fā)現(xiàn)的反向回歸。最后說一個個人習(xí)慣交付給別人的項目我一定會在界面里留下一個debug模式開關(guān)打開后顯示原始檢測框和置信度方便現(xiàn)場調(diào)試時一眼看出是模型漏檢還是后處理邏輯在搗亂。這套YOLOv5打電話檢測方案做完之后最大的體會是工業(yè)場景里模型的mAP不是核心數(shù)據(jù)邊界定義、線程穩(wěn)定性、坐標(biāo)轉(zhuǎn)換這些擺在明面上的工程細(xì)節(jié)才是決定項目能不能用起來的關(guān)鍵。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取