Detectron2 部署 十一

2021-10-06 17:47:18 字數 1860 閱讀 8155

作者|facebookresearch 編譯|flin **|github

caffe2部署

我們目前支援通過onnx將detectron2模型轉換為caffe2格式。轉換後的caffe2模型可以在python或c ++中執行而無需detectron2依賴性。它具有針對cpu和移動裝置推理優化的執行時,但不適用於gpu推理。

caffe2轉換需要pytorch≥1.4和onnx≥1.6。

覆蓋範圍

它支援最常見的3元結構:generalizedrcnn,retinanet,panopticfpn,幾乎在這些3元結構的所有官方正式型號。

只要使用者的自定義副檔名不包含caffe2中不可用的控制流或運算子(例如,可變形卷積),就支援這些體系結構下的使用者自定義副檔名(通過註冊新增)。例如,通常開箱即用地支援自定義backbones和heads。

用法轉換api記錄在api文件中。我們提供了乙個工具,tools/caffe2_converter.py作為使用這些api轉換標準模型的示例。

要轉換經過coco訓練的官方mask r-cnn,請先準備coco資料集,位址是:

然後從model zoo中選擇模型,然後執行:

python tools/caffe2_converter.py --config-file configs/coco-instancesegmentation/mask_rcnn_r_50_fpn_3x.yaml \

--output ./caffe2_model --run-eval \

model.weights detectron2://coco-instancesegmentation/mask_rcnn_r_50_fpn_3x/137849600/model_final_f10217.pkl \

model.device cpu

注意:

轉換需要有效的樣本輸入和權重來跟蹤模型。這就是指令碼需要資料集的原因。你可以修改指令碼以其他方式獲取樣本輸入。

僅pytorch的master支援gpu轉換。因此我們使用model.device cpu

使用--run-eval標誌,它將評估轉換後的模型以驗證其準確性。由於以下原因,精度通常與pytorch略有不同(在0.1 ap內)不同實現之間的數值精度。建議始終驗證準確性,以防轉換不支援自定義模型。

轉換後的模型位於指定的caffe2_model/目錄中。兩個檔案model.pb以及包含網路結構和網路引數的model_init.pb對於部署都是必需的。 然後可以使用caffe2的api將這些檔案載入​​到c ++或python中。

該指令碼會生成model.svg檔案,其中包含網路的視覺化內容。 你也可以將model.pb載入到netron(之類的工具中以對其進行視覺化。

輸入和輸出

所有轉換後的模型均採用兩個輸入張量:每個影象的"data"是nchw影象,而"im_info"是nx3張量(高度,寬度,未使用的舊引數)("data"的形狀可能由於填充而大於在"im_info"中顯示的內容)。

轉換後的模型不包含將原始圖層輸出轉換為格式化的**的後處理操作。這些模型僅從未經後期處理的最終層產生原始輸出,因為在實際部署中,應用程式通常需要自定義的輕量級後期處理(例如,通常無需為每個檢測到的物件使用full-image masks )。

由於不同的輸入和輸出格式,該caffe2model.__call__方法包括預處理/後處理**,以匹配原始detectron2模型的格式。它們可以作為實際部署中的預處理的參考。

sklearn機器學習中文官方文件:

Detectron2入門教程

目錄 1.概述 1.1.自己的原始碼閱讀流程 1.2.目錄結構 1.3.搭積木過程 1.4.官方文件閱讀 2.資料處理 2.1.概述 2.2.基本流程 2.3.build detection train loader 方法解析 2.4.其他 3.模型搭建 3.1.概述 3.2.基本流程 3.3.其他...

Detectron2 編寫模型 七

作者 facebookresearch 編譯 flin github 如果你嘗試做一些全新的事情,你可能希望在detectron2中完全從頭開始實現乙個模型。但是,在許多情況下,你可能對修改或擴充套件現有模型的某些元件感興趣.因此,我們還提供了一種註冊機制,可讓你覆蓋標準模型的某些內部元件的行為。例...

Detectron2 擴充套件預設值 三

作者 facebookresearch 編譯 flin github 研究是以新的方式做事。這給如何在 中建立抽象帶來了壓力,對於任何規模較大的研究工程專案而言,這都是乙個挑戰 一方面,它需要具有非常精簡的抽象,以允許以新方式進行所有操作。打破現有的抽象並將其替換為新的抽象應該相當容易。另一方面,這...