怎么理解anchor？

前言：这是知乎：faster rcnn中rpn的anchor，sliding windows，proposals之间的联系是什么？问题下的一个回答，这个回答首先解决了anchor是什么（what）的问题，对于初次接触到anchor这个概念的朋友来说，理解到这个深度已经够了。待我以后研究相关的论文之后，再来补充为什么这么设置anchor（Why）的问题和如何选择anchor大小（How）的问题。

首先我们需要知道anchor的本质是什么，本质是SPP(spatial pyramid pooling)思想的逆向。而SPP本身是做什么的呢，就是将不同尺寸的输入resize成为相同尺寸的输出。所以SPP的逆向就是，将相同尺寸的输出，倒推得到不同尺寸的输入。

接下来是anchor的窗口尺寸，这个不难理解，三个面积尺寸（128^2，2562，512^2），然后在每个面积尺寸下，取三种不同的长宽比例（1:1,1:2,2:1）.这样一来，我们得到了一共9种面积尺寸各异的anchor。示意图如下：

至于这个anchor到底是怎么用的，这个是理解整个问题的关键。

下面是整个faster RCNN结构的示意图：

利用anchor是从第二列这个位置开始进行处理，这个时候，原始图片已经经过一系列卷积层和池化层以及relu，得到了这里的 feature：51x39x256（256是层数）

在这个特征参数的基础上，通过一个3x3的滑动窗口，在这个51x39的区域上进行滑动，stride=1，padding=2，这样一来，滑动得到的就是51x39个3x3的窗口。

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

所以根据我们刚才的计算，我们一共得到了多少个anchor box呢？

51 x 39 x 9 = 17900

约等于 20 k

个人补充：

讲anchor的大小之前，也要说明一下相对于原图还是第几层的特征图。不同的“参考系”下，anchor的大小有很大的区别。
Yolo的作者犯了一个小的错误，这反倒可以让我们理解anchor大小依托于
比如在YOLOv2中，作者用最后一层feature map的相对大小来定义anchor大小。也就是说，在YOLOv2中，最后一层feature map大小为13X13，相对的anchor大小范围就在（0x0，13x13]。如果一个anchor大小是9x9，那么其在原图上的实际大小是288x288。

而在YOLOv3中，作者又改用相对于原图的大小来定义anchor，anchor的大小为（0x0，input_w x input_h]。以下是作者自己的解释：

So YOLOv2 I made some design choice errors, I made the anchor box size be relative to the feature size in the last layer. Since the network was down-sampling by 32. This means it was relative to 32 pixels so an anchor of 9x9 was actually 288px x 288px.
In YOLOv3 anchor sizes are actual pixel values. this simplifies a lot of stuff and was only a little bit harder to implement
https://github.com/pjreddie/darknet/issues/555#issuecomment-376190325