RPN&anchor

RPN的本质是 “ 基于滑窗的无类别obejct检测器 ”
通过以下结构生成 anchor（其实就是一堆有编号有坐标的bbox）
anchor的窗口尺寸，这个不难理解，三个面积尺寸（128^2，2562，512^2），然后在每个面积尺寸下，取三种不同的长宽比例（1:1,1:2,2:1）.这样一来，我们得到了一共9种面积尺寸各异的anchor。
在这个特征参数的基础上，通过一个3x3的滑动窗口，在这个51x39的区域上进行滑动，stride=1，padding=2，这样一来，滑动得到的就是51x39个3x3的窗口。

对于每个3x3的窗口，作者就计算这个滑动窗口的中心点所对应的原始图片的中心点。然后作者假定，这个3x3窗口，是从原始图片上通过SPP池化得到的，而这个池化的区域的面积以及比例，就是一个个的anchor。换句话说，对于每个3x3窗口，作者假定它来自9种不同原始区域的池化，但是这些池化在原始图片中的中心点，都完全一样。这个中心点，就是刚才提到的，3x3窗口中心点所对应的原始图片中的中心点。如此一来，在每个窗口位置，我们都可以根据9个不同长宽比例、不同面积的anchor，逆向推导出它所对应的原始图片中的一个区域，这个区域的尺寸以及坐标，都是已知的。而这个区域，就是我们想要的 proposal。
由于每个 proposal 和 ground truth 位置及尺寸上的差异，从 proposal 通过平移放缩得到 ground truth 需要的4个平移放缩参数（对应图上的 bbox_pred）。

实际上，每个33slide window的中心部分都对应一个anchor（anchor位于原图像上，相对位置转换），并且每个anchor对应3种size，三种scale，这样可以获得9种anchor box
如果feature map尺寸为1313，那么anchor box 数目就是13139个（padding = 2，stride = 1）
这样，就获得了一堆anchor box， 就获得了region proposal（基于原图像的）

补充：
看到一位博主这样理解：
anchorbox实际上是基于feature map的，其实featuremap对于anchorbox的生成的贡献就是提供了一个中心点而已，featuremap每个位置上的点，就对应一个anchorbox的中心，然后呢，我知道了这么多中心点，根据base size，scales，aspect ratios就可以算出来一个矩形的长和宽。矩形的中心点就是featuremap上的那个点对应原图上的点。
当前滑窗的中心在原像素空间的映射点称为anchor，以此anchor为中心，生成k(paper中default k=9, 3 scales and 3 aspect ratios)个proposals。

获取region proposal之后，把建议窗口映射到CNN的最后一层卷积feature map上，然后通过RoI pooling层使每个RoI生成固定尺寸的feature map，然后进行类别，回归bbox预测