faster RCNN簡介
- faster rcnn屬於兩階段目標檢測，所謂兩階段目標檢測，指的就是對檢測框做兩次邊框迴歸，首先使用RPN網絡，生成anchor，挑選出positive anchors，並對這些anchor進行第一次迴歸，再經過nms，得到初步的proposal；在RCNN階段，對於這些proposal，提取對應區域的feature map，並使用RoiAlign或者RoiPooling等方法，將這些proposal變成統一的大小（否則之後沒法接FC等層了），經過各種卷積或者fc操作之後，對proposal進行再一次地迴歸。整個過程迴歸了2次邊框，因此是兩階段的目標檢測。
- 關於faster rcnn更加具體的解釋可以參考這篇知乎文章：https://zhuanlan.zhihu.com/p/31426458
ancho generator分析
- 訓練時，在RPN中，使用anchor generation的方法生成anchor，但是在這個過程中，由於生成了大量的anchor，因此會有非常嚴重的正負樣本不均衡的問題，怎樣保證生成anchor與gt bbox有儘可能大的IOU，其實是非常重要的問題，在FPN中，短邊800訓練時，常規的RP配置如下。
FPNRPNHead:
anchor_generator:
anchor_sizes: [32, 64, 128, 256, 512]
aspect_ratios: [0.5, 1.0, 2.0]
stride: [16.0, 16.0]
variance: [1.0, 1.0, 1.0, 1.0]
anchor_start_size: 32
max_level: 6
min_level: 2
num_chan: 256
在移動端如果希望能夠跑兩階段目標檢測，那麼一般都是需要減少輸入圖像的尺度的，但是這時候，如果使用原始的anchor size，則可能會導致anchor的[email protected](iou)太低。這樣有3個主要問題
- 一方面進一步增加了目標檢測的正負樣本
- 另一方面也增加了網絡學習的難度（召回的anchor不夠多，網絡需要學習更多的偏移量）。
- 不同大小的anchor在不同anchor size的情況下，召回也是不同的（如果anchor size很大的話，則大物體的召回情況會改善，但是這會帶來大小物體召回不平衡的問題）。
因此，需要對anchor size進行一些調整，否則難以召回。
anchor start size修改
在320x320下，分析了anchor_start_size對召回的影響，默認32和修改爲16之後的情況下，召回如下，
| anchor start size | 訓練尺度 | [email protected] for small | [email protected] for medium | [email protected] for large |
|---|---|---|---|---|
| 32 | 320x320 | 0.814 | 18.371 | 23.069 |
| 16 | 320x320 | 2.468 | 4.960 | 5.627 |
上面可以看出，訓練尺度爲320x320anchor start size=32時，大小anchor的召回差距較大，這帶來了不平衡的問題，而使用16的時候，不同尺度的anchor召回比較平衡，基於mobilenetv3模型，實驗證明，32->16的改進，可以直接帶來1.7%的coco mAP提升。
FPN level修改
- 檢測中默認的backbone一般都是
C2~C5，FPN輸出P2~P6，而這其實會帶來很大的計算量，如果通過減少backbone stage的方式（如C2~C4，FPN輸出P2~P4）這可以減少計算量，但是又會帶來召回不足的問題。分析不FPN leve情況下的召回，具體信息如下。 - 注意：在這裏，anchor start size均爲16。
| FPN level | 訓練尺度 | [email protected] for small | [email protected] for medium | [email protected] for large |
|---|---|---|---|---|
| P2~P4 | 320x320 | 2.468 | 4.928 | 1.922 |
| P2~P5 | 320x320 | 2.468 | 4.960 | 4.952 |
| P2~P6 | 320x320 | 2.468 | 4.960 | 5.627 |
由上面可以看出，其實P2~P6的FPN level還是非常有意義的，很大程度上提升了大物體的anchor階段的召回情況。那既然直接使用backbone生成feature map很耗時，我們完全可以使用降採樣卷積的方式生成更多的FPN feature map，這樣在計算量很小的情況下，也可以保證anchor generator的正常運行。
下面可視化了P2~P4作爲FPN feature map時的召回情況.
下面可視化了P2~P6作爲FPN feature map時的召回情況。
其中，綠色框是可以被召回的anchor，紅色框是gt bbox，很明顯可以看出，更多的FPN level帶來了更多可以用於迴歸的正樣本。
使用P2~P6相比於P2~P4，coco mAP漲了1.3%。特別需要注意的是，大物體的mAP漲了2.5%，這個也驗證了之前我們的分析結論。
實現
PaddleDetection中基於該種思路，提供了移動端的實用目標檢測算法，COCO mAP可以達到25.0%，速度和精度都是可以與YOLO與SSD匹敵的。下面給出了精度和預測速度的情況，更加具體的可以參考PaddleDetection的github地址：https://github.com/PaddlePaddle/PaddleDetection/blob/master/configs/mobile/README.md
