Faster R-CNN中的RPN和anchor機制理解
先上圖看一下Faster R-CNN操作流程：
圖片說明：Faster R-CNN=Fast R-CNN+RPN，其中Fast R-CNN結構不變；RPN負責生成proposals，配合最後一層的feature map，使用ROI Pooling，生成fixed length的feature vector。我們詳細討論一下RPN的操作過程
圖片說明，紅框只是一個滑窗的操作過程，注意這裡的anchor是原影象畫素空間，而不是feature map上的。這樣
anchor是RPN的核心：
假設我們現在得到的feature map為W * H * C(13 * 13 * 256就是feature map的width=13,height=13,channel=256)，我們如何產生網路需要的proposals呢？我們在feature map使用滑動視窗的操作方式（stride=1,padding=1）,當前滑窗的中心在原畫素空間的對映點稱為anchor，以此anchor為中心，生成k(paper中default k=9, 3 scales and 3 aspect ratios)個proposals。
在此feature map滑動一個mini-network，這個network輸入是3 * 3 * 256，經過3 * 3 * 256 * 256的卷積，得到1 * 1 * 256的低維向量；接下來進行分類：①Classification：經過1 * 1 * 256 * 18的卷積核，得到1 * 1 * 18的feature vector，分別代表9個proposals的是/不是Object的概率(這裡有一個疑惑，為什麼要生成一對？生成一個是Object的概率不就好了？也許是為了設計方便？)；②Regression：經過1 * 1 * 256 * 36的卷積核，得到1 * 1 * 36的feature vector，分別代表9個proposals的(center_x,center_y,w,d)。
上述操作只是一個3 * 3的滑動視窗的操作過程，實際操作過程中，必須將13 * 13的feature map均執行一邊；於是在RPN中，產生了兩個損失函式：①Classification loss②Regression loss。
這樣的話，通過滑動視窗和anchor機制，我們就可以找到固定比例、一定大小的proposals：①物體大小不同導致的proposal被覆蓋②物體aspects ratios不同導致proposals也被覆蓋
由上可知，NRP可以代替Selective Search產生proposals，而且最關鍵的一點是RPN 更快
ROI pooling V.S. SSP Pooling
ROI是隻有一層的SSP Pooling：ROI Pooling將proposal在feature map上的對應區域分為W * H 份，每一份取Max/Avg 將其放到固定位置
SSP Pooling是將proposal分為(4 * 4 / 2 * 2 / 1 * 1份，然後進行拼接，得到fixed length=21的feature vector)
建議讀原版faster rcnn論文:https://arxiv.org/abs/1506.01497
原文：https://blog.csdn.net/gm_margin/article/details/80245470