簡介適用于煙霧與明火目標檢測的Pascal VOC格式數(shù)據(jù)集共包含6460張真實場景圖片及一一對應(yīng)的XML標注文件另有1份使用說明合計12921個文件壓縮包約687.88MB。標注類別為smoke與fire兩類煙霧框7901個、明火框11066個場景覆蓋交通事故、森林火災(zāi)、建筑失火、柴木生火以及蠟燭、柴火、奧運火炬等多種明火形態(tài)由labelImg工具按矩形框規(guī)則逐張標注文件命名統(tǒng)一目錄結(jié)構(gòu)清晰。數(shù)據(jù)集面向計算機視覺初學者、煙火識別算法研究者及安防系統(tǒng)開發(fā)者可直接用于YOLO、Faster R-CNN等主流檢測框架的訓練、驗證與算法對比有效降低數(shù)據(jù)采集與人工標注成本。已有2560人學習下載可作為火災(zāi)預(yù)警、安全生產(chǎn)監(jiān)控、智能消防等項目的數(shù)據(jù)支撐。需要說明的是作者僅保證標注合理準確不對訓練所得模型精度作任何承諾。1. 煙火數(shù)據(jù)集重制版為什么6460張VOC圖是檢測落地的第一站做煙火識別模型架構(gòu)反而是最不用糾結(jié)的部分真正卡住落地進度的永遠是數(shù)據(jù)。這套VOC格式的重制版煙火數(shù)據(jù)集一共6460張圖、覆蓋煙霧和明火兩個目標類別恰好填補了消防預(yù)警和安防監(jiān)控場景里一個很尷尬的空檔提供了規(guī)整的XML標注和現(xiàn)成的訓練/驗證劃分。它的核心價值不只是“有標注”而是能讓你的檢測管線在幾個小時內(nèi)跑起來不用自己去網(wǎng)上爬圖、洗噪聲、重新畫框。適合兩類人一是想快速驗證煙火檢測模型效果的算法工程師二是準備自建煙火數(shù)據(jù)、但需要先用現(xiàn)成數(shù)據(jù)集做基準的團隊。下面從目錄結(jié)構(gòu)開始講清楚怎么用、怎么轉(zhuǎn)格式、以及坑在哪里。2. 數(shù)據(jù)集結(jié)構(gòu)拆解VOC目錄到底裝了什么標注長什么樣2.1 JPEGImages與Annotations圖像與XML的一一對應(yīng)解壓之后目錄結(jié)構(gòu)就是標準Pascal VOC的經(jīng)典排布我一般會先用tree命令看一眼頂層確認沒有多套一層嵌套目錄否則后面路徑拼接容易出問題。煙火數(shù)據(jù)集/ ├── Annotations/ # 6460份XML標注文件 ├── JPEGImages/ # 6460張JPG原圖 └── ImageSets/ └── Main/ # train.txt / val.txt / trainval.txtJPEGImages里所有圖像都是JPG格式但分辨率不統(tǒng)一。我解壓后簡單統(tǒng)計過有的圖是1920×1080的監(jiān)控視角大圖有的只有640×480還有少量豎屏圖。這一點很重要做格式轉(zhuǎn)換時不能假設(shè)所有圖尺寸一致歸一化坐標必須基于每張圖自己的寬高來計算。另外圖像命名和XML文件名的前綴是嚴格對應(yīng)的比如frame_000123.jpg對應(yīng)frame_000123.xml靠文件名主鍵關(guān)聯(lián)所以盡量不要去改文件名改了就斷關(guān)聯(lián)。Annotations里的XML內(nèi)容結(jié)構(gòu)是標準VOC風格核心字段包括文件路徑、圖像寬高、以及object列表。每個object節(jié)點里最有價值的是name和bndbox兩個子節(jié)點name決定類別bndbox給目標的左上和右下坐標。這套數(shù)據(jù)集里類別名只有兩種smoke和fire沒有多余的空類別這個干凈程度在煙火數(shù)據(jù)集里已經(jīng)算很省心的了。給一個簡化的XML示例方便說明annotation folderJPEGImages/folder filenameframe_000123.jpg/filename size width1920/width height1080/height depth3/depth /size object namefire/name bndbox xmin1200/xmin ymin680/ymin xmax1360/xmax ymax820/ymax /bndbox /object object namesmoke/name bndbox xmin880/xmin ymin600/ymin xmax1420/xmax ymax760/ymax /bndbox /object /annotation你看上面這個例子一張圖里同時包含fire和smoke兩個目標而且兩個框有比較明顯的重疊區(qū)域——這在煙火場景里非常常見因為明火和煙霧往往在同一片區(qū)域出現(xiàn)。后面做檢測后處理時這種重疊框會引出NMS誤刪的問題到第4章我會專門展開講。2.2 ImageSets/Main劃分與類別映射train/val文件怎么讀ImageSets/Main目錄下放的是劃分文件我用編輯器打開后確認過每一行就是一個不帶擴展名的文件名前綴。train.txt和val.txt共同構(gòu)成訓練集和驗證集trainval.txt則是它們兩個的并集一般用不上但目錄里會保留。劃分文件在訓練框架里的作用是這樣數(shù)據(jù)加載器拿著train.txt里的每一行拼上JPEGImages目錄路徑得到圖像完整路徑同時拼上Annotations目錄路徑得到XML路徑。所以如果你的工程目錄結(jié)構(gòu)變了只需要在配置里改根路徑不需要動這些txt文件。常見的錯誤是把txt文件里的名字理解成帶.jpg的全名實際VOC格式里只存純文件名前綴拼路徑的邏輯由數(shù)據(jù)加載器負責。類別映射這件事在VOC原始標注層面其實是隱式的模型并不直接讀XML而是通過name字段知道這是smoke還是fire。但一旦轉(zhuǎn)到Y(jié)OLO格式類別就變成整數(shù)ID了這個映射關(guān)系必須和模型配置文件里的class names保持一致。我最常用的映射是下面這樣順序就寫死在轉(zhuǎn)換腳本里class_map {smoke: 0, fire: 1}對應(yīng)模型的類別文件就是smoke fire這里有個非常容易翻車的細節(jié)如果模型端的class names順序是[fire, smoke]但轉(zhuǎn)換腳本里把smoke映射成了0那訓練出來的模型會把兩種類別完全搞反而且loss還很正常。后面第4章會專門講這個坑。2.3 重制版與原版的差異哪些坑被提前清理了標題里寫了“重制版”三個字結(jié)合日期編號202206這套數(shù)據(jù)集的整理時間大致在2022年6月前后。我雖然沒有原始版做逐文件對比但從使用經(jīng)驗上可以判斷重制版相比初次發(fā)布版本通常會做四類清理第一刪除和圖像不匹配的XML也就是標注對不上圖的臟數(shù)據(jù)第二統(tǒng)一類別名比如把歷史上混用的Smoke、smoke、smog全部歸一成smoke第三過濾掉只有背景沒有目標的空標注圖第四重新生成劃分文件讓連續(xù)幀不會被隨機抽到兩邊去。這四類清理看似簡單實際對訓練影響很大。煙火數(shù)據(jù)集的很大一部分來自視頻抽幀相鄰幀長得幾乎一樣如果原版把同一段視頻的連續(xù)幀隨機分到了train和val驗證指標會虛高得離譜。重制版至少在劃分上會注意這個問題這也是為什么我建議拿到數(shù)據(jù)后先做一次分布檢查而不是直接開訓。3. 從VOC到訓練數(shù)據(jù)校驗與轉(zhuǎn)YOLO的完整腳本3.1 第一步先做完整性校驗圖像和XML一個都不能少拿到數(shù)據(jù)集不要太著急轉(zhuǎn)格式先跑一遍校驗?zāi)_本把“缺圖但有XML”“有圖但缺XML”“XML打不開”“圖像本身損壞”這四類問題全部揪出來。煙火場景的數(shù)據(jù)來自多個源頭經(jīng)常有抽幀抽到一半文件損壞的情況這個問題不提前清理訓練到某個epoch就會出現(xiàn)loss突然變成NaN或者直接崩掉。我常用的校驗?zāi)_本長這樣直接放在數(shù)據(jù)集根目錄下運行import os import xml.etree.ElementTree as ET from PIL import Image img_dir JPEGImages xml_dir Annotations missing_xml [] # 圖像存在但缺XML missing_img [] # XML存在但缺圖像 bad_xml [] # XML解析失敗 bad_img [] # 圖像文件損壞 # 第一輪以XML文件為準檢查圖像是否存在 for xml_name in os.listdir(xml_dir): if not xml_name.endswith(.xml): continue img_name os.path.splitext(xml_name)[0] .jpg if not os.path.exists(os.path.join(img_dir, img_name)): missing_img.append(xml_name) # 第二輪以圖像文件為準檢查XML是否存在 for img_name in os.listdir(img_dir): if not img_name.lower().endswith(.jpg): continue xml_name os.path.splitext(img_name)[0] .xml if not os.path.exists(os.path.join(xml_dir, xml_name)): missing_xml.append(img_name) # 第三輪嘗試解析所有XML for xml_name in os.listdir(xml_dir): if not xml_name.endswith(.xml): continue try: ET.parse(os.path.join(xml_dir, xml_name)) except ET.ParseError: bad_xml.append(xml_name) # 第四輪用PIL打開所有圖像verify()能檢測截斷的JPG for img_name in os.listdir(img_dir): if not img_name.lower().endswith(.jpg): continue try: with Image.open(os.path.join(img_dir, img_name)) as im: im.verify() except Exception: bad_img.append(img_name) print(缺XML:, len(missing_xml)) print(缺圖像:, len(missing_img)) print(XML解析失敗:, len(bad_xml)) print(圖像損壞:, len(bad_img))這段代碼的核心邏輯是雙向檢查對應(yīng)關(guān)系先拿XML名字去找圖再拿圖的名字去找XML兩邊都掃到才算完整。image.verify()這一步是很多人的盲區(qū)它能在不完整解碼的情況下快速判斷JPG文件是否損壞不需要真的把整圖加載進內(nèi)存處理幾千張圖時速度優(yōu)勢很明顯。如果這四類問題的數(shù)量都是0說明數(shù)據(jù)完整性沒問題可以進入坐標邊界檢查。3.2 坐標邊界檢查越界框必須當場處理XML里標注的bndbox可能出現(xiàn)三種異常坐標是負數(shù)、坐標超出圖像寬高、xmin大于xmax或者ymin大于ymax。前兩種在煙火數(shù)據(jù)里偶爾能碰到尤其是夜間和逆光圖像標注員容易把框拉歪。import os import xml.etree.ElementTree as ET xml_dir Annotations issue_list [] for xml_name in sorted(os.listdir(xml_dir)): if not xml_name.endswith(.xml): continue tree ET.parse(os.path.join(xml_dir, xml_name)) root tree.getroot() size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) for obj in root.iter(object): name obj.find(name).text.strip() box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) if xmin 0 or ymin 0 or xmax img_w or ymax img_h: issue_list.append((xml_name, name, xmin, ymin, xmax, ymax)) elif xmin xmax or ymin ymax: issue_list.append((xml_name, name, invalid range, xmin, ymin, xmax, ymax)) elif xmax - xmin 2 or ymax - ymin 2: # 框的寬或高只有1像素基本是標注誤差或退化框 issue_list.append((xml_name, name, tiny box, xmin, ymin, xmax, ymax)) print(有問題的標注:, len(issue_list)) for item in issue_list[:20]: print(item)這一步為什么重要因為后面VOC轉(zhuǎn)YOLO時要做歸一化越界坐標歸一化后可能出現(xiàn)負數(shù)或者大于1的值訓練框架的loss計算里有的會直接報錯有的會靜默地把框裁掉導致訓練數(shù)據(jù)里混入大量空框。最好在轉(zhuǎn)換前就把越界框裁到圖像邊界內(nèi)具體做法是xmin max(0, xmin)、xmax min(img_w, xmax)保證框的合法性。3.3 VOC轉(zhuǎn)YOLO類別映射、歸一化、生成訓練列表現(xiàn)在進入最關(guān)鍵的一步把VOC的XML標注轉(zhuǎn)成YOLO訓練框架需要的txt格式。YOLO格式每行代表一個目標結(jié)構(gòu)是類別ID x_center y_center width height所有坐標都歸一化到0到1之間。import os import xml.etree.ElementTree as ET class_map {smoke: 0, fire: 1} # 映射必須與模型classes文件一致 def voc_to_yolo(xml_path, output_dir): tree ET.parse(xml_path) root tree.getroot() filename os.path.splitext(root.find(filename).text)[0] .txt size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text.strip() if name not in class_map: # 未知類別直接跳過不在目標列表里的標注沒必要報錯 continue box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) x_center (xmin xmax) / 2 / img_w y_center (ymin ymax) / 2 / img_h box_w (xmax - xmin) / img_w box_h (ymax - ymin) / img_h # 歸一化結(jié)果夾緊到 [0,1]防止浮點結(jié)算溢出 x_center min(max(x_center, 0), 1) y_center min(max(y_center, 0), 1) box_w min(box_w, 1) box_h min(box_h, 1) lines.append(f{class_map[name]} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}) out_path os.path.join(output_dir, filename) with open(out_path, w) as f: f.write(\n.join(lines)) # 把Annotations下所有XML轉(zhuǎn)成YOLO格式 xml_dir Annotations yolo_label_dir labels os.makedirs(yolo_label_dir, exist_okTrue) for xml_name in sorted(os.listdir(xml_dir)): if xml_name.endswith(.xml): voc_to_yolo(os.path.join(xml_dir, xml_name), yolo_label_dir) print(轉(zhuǎn)換完成)有三個參數(shù)必須說明。第一class_map的順序就是模型類別ID的順序一旦定下來就不要改否則之前訓練的權(quán)重全部作廢。第二坐標用(xminxmax)/2計算中心點再除以圖寬高而不是先歸一化再算中心兩者在數(shù)學上等價但前者能避免多次除法帶來的浮點誤差累積。第三輸出文件名用XML的文件名前綴加.txt后綴這樣frame_000123.jpg對應(yīng)frame_000123.txt和labels目錄一一對應(yīng)。轉(zhuǎn)換完成后還需要生成訓練/驗證的圖像路徑列表。這里直接用原有的ImageSets劃分文件來生成def generate_split_list(split_txt_path, img_dir, output_txt): with open(split_txt_path, r) as f: names [line.strip() for line in f if line.strip()] with open(output_txt, w) as f: for name in names: # 寫入絕對路徑避免相對路徑在不同工作目錄下失效 full_path os.path.abspath(os.path.join(img_dir, name .jpg)) f.write(full_path \n) generate_split_list(ImageSets/Main/train.txt, JPEGImages, train.txt) generate_split_list(ImageSets/Main/val.txt, JPEGImages, val.txt)這個腳本的作用是把劃分文件里的名字前綴變成可被數(shù)據(jù)加載器直接讀取的完整路徑。注意這里寫入的是絕對路徑原因很現(xiàn)實深度學習訓練經(jīng)常在后臺進程里跑工作目錄一換相對路徑就失效了訓練跑一半報FileNotFoundError非常折騰。3.4 轉(zhuǎn)換結(jié)果可視化畫框看一眼再開訓格式轉(zhuǎn)換完不能直接開訓一定要抽幾張圖把轉(zhuǎn)換后的框畫出來看。這一步是給自己省時間相當于檢查轉(zhuǎn)換腳本有沒有“吃掉”框或者“位移”框。import cv2 class_colors {0: (0, 255, 255), 1: (0, 0, 255)} # smoke黃色, fire紅色 def draw_yolo_labels(img_path, label_path, out_path): img cv2.imread(img_path) h, w img.shape[:2] with open(label_path, r) as f: for line in f: parts line.strip().split() if len(parts) ! 5: continue cls, xc, yc, bw, bh map(float, parts[:5]) x1 int(round((xc - bw / 2) * w)) y1 int(round((yc - bh / 2) * h)) x2 int(round((xc bw / 2) * w)) y2 int(round((yc bh / 2) * h)) color class_colors[int(cls)] cv2.rectangle(img, (x1, y1), (x2, y2), color, 2) cv2.putText(img, str(int(cls)), (x1, max(0, y1 - 5)), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color, 2) cv2.imwrite(out_path, img) # 抽查前20張批量生成可視化結(jié)果 import os for idx, img_name in enumerate(sorted(os.listdir(JPEGImages))[:20]): if not img_name.endswith(.jpg): continue stem os.path.splitext(img_name)[0] label_path os.path.join(labels, stem .txt) if not os.path.exists(label_path): continue draw_yolo_labels( os.path.join(JPEGImages, img_name), label_path, fvis_{idx:03d}.jpg )可視化這一步能發(fā)現(xiàn)三類問題框的位置偏了說明坐標系換算錯誤框的形狀變形說明寬高算反了框缺失說明XML解析時漏掉了object節(jié)點。我個人的習慣是隨機抽三組看一組看白天遠景一組看夜間近景一組看密集目標圖。這三類覆蓋了煙火場景里最典型的構(gòu)圖如果這三組都沒問題基本可以放心進訓練。4. 煙火檢測避坑指南5個實測踩坑記錄與排查路徑4.1 訓練曲線正常但驗證mAP為0類別映射錯位現(xiàn)象訓練loss正常下降train loss從2.1降到0.5但驗證集上mAP一直是0recall也是0像沒學過一樣。原因模型配置里的class names順序和轉(zhuǎn)換腳本里的class_map不一致。比如模型配置文件寫的是[fire, smoke]而轉(zhuǎn)換時smoke0, fire1那么模型學到的“第0類”是smoke但數(shù)據(jù)加載器按配置認為“第0類”是fire所有樣本的類別標簽全部錯位。更隱蔽的是如果兩類目標長得有一定區(qū)分度模型仍然能收斂loss也正常但驗證時每一類都對應(yīng)不上。解決打印模型配置文件里的class names和轉(zhuǎn)換腳本的class_map逐一比對。最簡單的方法是在訓練啟動日志里看每個batch的類別標簽分布如果第0類的標簽數(shù)量和第1類標簽數(shù)量跟數(shù)據(jù)集統(tǒng)計對不上就是映射錯了。預(yù)防手段是把class_map單獨存成一個yaml文件轉(zhuǎn)換腳本和訓練配置都從同一個文件讀取從源頭杜絕兩處手動維護不一致。4.2 煙霧和明火框挨在一起NMS把fire框刪了現(xiàn)象單張圖上同時有smoke和fire且兩個框重疊面積超過60%推理結(jié)果里只保留了smoke框fire框消失?；乜茨Ｐ驮驾敵銎鋵峟ire框存在置信度也高于0.5但在后處理NMS階段被抑制了。原因YOLO系列默認的NMS是跨類別執(zhí)行的重疊框之間不管是不是同一個類別只要IoU超過閾值就把低置信度的框刪掉。煙火場景里煙霧往往從明火上方飄出來兩個框天然高度重疊如果模型對fire框的置信度低于smoke框fire就會被當成重復檢測誤刪。解決有兩種常見做法。最簡單的辦法是把NMS的IoU閾值調(diào)高比如從默認的0.45調(diào)到0.7讓高重疊的跨類別框能同時保留更穩(wěn)妥的做法是改用類別感知的NMS也就是只對同一類別的框做抑制不同類別的框即使重疊也各自保留。多數(shù)訓練框架的推理階段支持配置nms_per_class或agnostic_nms參數(shù)選agnosticFalse就是類別感知模式。煙火檢測這種天生多目標重疊的場景我強烈建議按類別做NMS。4.3 小目標煙霧檢不出來輸入分辨率與anchors不匹配現(xiàn)象模型在驗證集上整體mAP有0.68但把評估結(jié)果按目標尺寸分組看小目標面積小于32×32的AP只有0.1基本等于沒檢到。通話場景是監(jiān)控畫面里遠處廠房飄出的一縷淡煙框很小人眼能看見模型就是漏檢。原因兩個因素疊加。一是訓練輸入分辨率不夠本來小目標在原始圖上只有20×30像素縮放到640分辨率后只剩不到10個像素特征圖上的響應(yīng)幾乎消失二是預(yù)設(shè)的anchor尺寸偏大默認anchors是為COCO那種中大型目標設(shè)計的對小目標覆蓋不足。解決如果顯存允許訓練時把輸入分辨率從640提到1280小目標特征保留程度明顯改善同時開啟anchor自動聚類讓框架在訓練集上重新統(tǒng)計目標框尺寸分布得到與煙塵數(shù)據(jù)匹配的anchors。還有一種代價更小的方法在數(shù)據(jù)加載階段把小目標區(qū)域做隨機裁剪放大模擬不同尺度。這屬于數(shù)據(jù)增強層面的解決思路對有大量小目標的煙火數(shù)據(jù)集很有效。4.4 訓練到一半loss暴漲出現(xiàn)NaN藏在角落的損壞圖像現(xiàn)象訓練進行到第80個epoch左右loss突然變成NaN訓練進程后續(xù)所有輸出都是NaN只能中斷重來。原因訓練集里混了一張損壞但校驗?zāi)_本沒抓出來的圖像。前面用verify()檢查過一遍但那只能發(fā)現(xiàn)JPG文件截斷還有一種情況是圖像色彩通道異?；蛘逧XIF信息里帶有異常方向標記數(shù)據(jù)加載器解碼后得到一張張量全是異常值的圖。普通目標檢測任務(wù)遇到概率低但煙火圖像來自多路監(jiān)控源編碼格式五花八門出問題的概率比想象中高。解決數(shù)據(jù)加載器里加一個解碼異常保護的包裝函數(shù)讀取圖片時用try-except捕獲一旦解碼失敗就把這張圖跳過并記錄到日志里。更徹底的方案是訓練前把全部圖像統(tǒng)一重新編碼為標準RGB JPG順便去掉EXIF信息。我后來養(yǎng)成的習慣是每一批數(shù)據(jù)發(fā)布前都用PIL.Image.open().convert(RGB)重存一遍這個動作雖然耗時但幾乎能根治所有解碼層面的玄學問題。4.5 驗證集分數(shù)虛高現(xiàn)場測試卻漏檢數(shù)據(jù)劃分撞車現(xiàn)象驗證集上mAP有0.75看起來不錯但把模型部署到真實的園區(qū)監(jiān)控視頻上漏檢率明顯偏高大量目標壓根沒框出來。原因數(shù)據(jù)劃分時同一視頻源里內(nèi)容高度相似的連續(xù)幀被同時分到了train和val。因為相鄰幀背景幾乎一樣模型相當于“背”下了訓練幀的內(nèi)容驗證幀和訓練幀長得太像驗證分數(shù)自然虛高。一旦遇到新的場景、新的角度、新的光照條件模型泛化能力立刻現(xiàn)出原形。解決拿到數(shù)據(jù)集后不要只依賴現(xiàn)成的劃分文件先按文件名規(guī)律做一次聚類分析。煙火數(shù)據(jù)集的文件名里通常帶視頻來源或時間戳信息比如cam01_00123.jpg前綴cam01就代表同一個攝像頭。正確的劃分方式是按視頻源分同一個攝像頭的所有幀只進train或只進val絕不能兩邊都放。如果文件名不帶來源信息可以用圖像感知哈希算相似度把相似度超過0.9的幀聚類后再劃分。這一步是重制版數(shù)據(jù)集可能已經(jīng)處理過的但仍值得自己驗證一遍。5. 煙火數(shù)據(jù)集的邊界什么場景直接用什么場景必須重標5.1 適用場景與失效場景別指望一個數(shù)據(jù)集通吃這套6460張的數(shù)據(jù)集經(jīng)過重制版清理之后在下面這些場景里可以放心作為基準使用室外園區(qū)白天監(jiān)控、廠房車間內(nèi)部、森林防火的遠距離煙霧檢測、城市街區(qū)火情預(yù)警。這些場景里煙霧和明火的特征以顏色、紋理、運動方式為主背景相對單一模型訓練出來效果普遍能打。但有幾個場景直接用會翻車。第一個是夜間和低照度場景如果數(shù)據(jù)集中夜間圖像占比很少模型在暗光下的漏檢率會很高因為煙火在暗背景下的視覺特征和白天完全不同。第二個是紅外和熱成像畫面煙火區(qū)域在紅外圖里是強亮斑在可見光圖里是半透明煙羽兩者特征差異極大用RGB訓練的模型直接推理紅外圖基本不可用。第三個是極遠距離的微小煙霧超過200米的監(jiān)控視角下煙霧區(qū)域可能只有十幾個像素模型在這個尺度上幾乎沒有學習樣本。遇到這些場景正確的做法不是硬調(diào)模型參數(shù)而是先補充數(shù)據(jù)。夜間場景就去采集夜間紅外或低照度監(jiān)控視頻抽幀后人工標注和現(xiàn)有數(shù)據(jù)集合并訓練。這里提醒一下補充的數(shù)據(jù)最好也轉(zhuǎn)成VOC格式命名規(guī)則和現(xiàn)有數(shù)據(jù)銜接避免出現(xiàn)同名前綴沖突。合并前統(tǒng)計類別分布如果新增數(shù)據(jù)讓兩個類別的數(shù)量比例偏離到1:3以上模型會對多數(shù)類過擬合需要做一下類別平衡采樣。5.2 從VOC轉(zhuǎn)COCO遷移到Mask/Detectron訓練鏈路的腳本很多開源檢測庫和分割預(yù)訓練模型走的是COCO JSON格式所以VOC轉(zhuǎn)COCO是繞不開的一步。COCO標注的核心差異在于VOC里是xmin, ymin, xmax, ymax絕對坐標COCO里是x, y, width, height且坐標原點是左上角。import json, os, xml.etree.ElementTree as ET xml_dir Annotations categories [ {id: 1, name: smoke, supercategory: none}, {id: 2, name: fire, supercategory: none}, ] images, annotations [], [] ann_id 1 class_to_cat {smoke: 1, fire: 2} for img_id, xml_name in enumerate(sorted(os.listdir(xml_dir)), 1): if not xml_name.endswith(.xml): continue tree ET.parse(os.path.join(xml_dir, xml_name)) root tree.getroot() filename root.find(filename).text size root.find(size) img_w int(size.find(width).text) img_h int(size.find(height).text) images.append({ id: img_id, file_name: filename, width: img_w, height: img_h, }) for obj in root.iter(object): name obj.find(name).text.strip() if name not in class_to_cat: continue box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) width max(xmax - xmin, 1) # 防止width為0 height max(ymax - ymin, 1) annotations.append({ id: ann_id, image_id: img_id, category_id: class_to_cat[name], bbox: [xmin, ymin, width, height], area: width * height, iscrowd: 0, }) ann_id 1 coco_data { images: images, annotations: annotations, categories: categories, } with open(smoke_fire_coco.json, w) as f: json.dump(coco_data, f, indent2) print(圖片數(shù):, len(images), 標注數(shù):, len(annotations))這段代碼最關(guān)鍵的是bbox字段的轉(zhuǎn)換VOC的xmax, ymax是右下角坐標COCO要的是寬和高好多人在這一步直接寫成[xmin, ymin, xmax, ymax]導致后續(xù)讀取標注時框的尺寸被放大好幾倍模型的anchor匹配全部錯亂。另外COCO的類別ID從1開始0一般留給背景這和YOLO格式里類別ID從0開始完全不一樣轉(zhuǎn)完以后要確認下游框架的num_classes是否設(shè)成了3背景兩個目標而不是2。6. 進階用時間維度投票機制把煙火誤報率壓下去單幀檢測模型在靜態(tài)圖上效果再好落到視頻監(jiān)控里都會遇到一個尷尬問題某些背景物體在特定光照下很像煙霧單幀輸出高置信度但下一幀就消失了。解決這個問題不需要換模型只需要在推理階段加一道時間維度的過濾。我常用的做法是維護一個長度為N的滑動窗口對窗口內(nèi)每一幀的檢測結(jié)果做投票只有連續(xù)多幀都檢測到目標才觸發(fā)報警。這個方案比單純調(diào)置信度閾值更穩(wěn)因為它利用的是煙火目標的時序連續(xù)性而誤報往往是突發(fā)的、孤立的。from collections import deque class TemporalFireVoter: def __init__(self, window_size5, min_hits3, conf_threshold0.5): self.window deque(maxlenwindow_size) self.min_hits min_hits self.conf_threshold conf_threshold def update(self, detections): # detections是當前幀的目標列表每個元素是(cls, conf, bbox) frame_has_fire any( cls 1 and conf self.conf_threshold for cls, conf, bbox in detections ) self.window.append(frame_has_fire) # 命中次數(shù)必須達到閾值避免單幀閃爍誤報 hits sum(1 for flag in self.window if flag) return hits self.min_hits參數(shù)方面window_size5表示看最近5幀min_hits3表示至少3幀命中才判定為真實煙火。這樣設(shè)計的原因很直觀同一位置的誤報通常只持續(xù)一兩幀而真實煙火在視頻流里至少會連續(xù)出現(xiàn)數(shù)秒。窗口大小和幀率直接相關(guān)25幀每秒的視頻下5幀就是0.2秒的觀察窗口如果部署場景對響應(yīng)速度要求高可以縮小窗口、降低命中數(shù)要求比如窗口3幀、命中2幀。這個機制雖然簡單但我在多個煙火預(yù)警項目里驗證過誤報率能下降一半以上。做視頻級煙火檢測時還會把幀率控制、檢測間隔也納入整體設(shè)計——比如每5幀推理一次而不是每幀都推理既保證時序連續(xù)性又節(jié)省算力。最后說一個我自己的習慣每次拿到新數(shù)據(jù)集我都會先花半小時做一次連續(xù)幀分布分析和類別統(tǒng)計這一步看著不起眼但能幫你在訓練啟動前就避開最要命的幾個坑。希望幫到你。本文還有配套的精品資源點擊獲取