Faster-RCNN 中的 anchor 与原图中 boundingbox 的对应关系

通常在 Flag 立下之后的第一篇博客，总想把很多东西都放在一篇文章里面说得透透的，这样就像是在一个迷宫，越走发现可以走的路越多，所以往往就偏离主线越来越远，因此原计划就成了烂尾楼。

而解决拖延症的最好办法就是抛弃完美主义，无论写的多烂，先搞定一个版本，后面再改。因此本篇就是出于这个初衷，可能有理解不到位的地方，希望大家讨论指正。

闲话少叙，下面进入主题

------------------------这是分割线---------------------------

Anchor 的使用是 faster-rcnn 最核心和本质的创新点，faster-rcnn 通过预定义一系列位置相对固定的 anchors，对应回原图获得bounding boxes (bbxes)，然后利用 RPN 网络对anchor 进行 前/背景 判断，位置回归；从而获得最终的 proposals。接下来就是fast-rcnn 的事情了。而一般来说，对于faster-rcnn 的应用，一个好的 anchor 设置方式，能够起到非常关键的作用。

而关于 anchor 到底是怎么和 proposal 对应上的？这个点如果不看代码，只看论文其实还挺让人疑惑的，不知道怎么回事，我也没有找到特别好的技术博客来介绍这个细节 。我原来一直以为是这个点比较简单，以至于大家都不屑于讨论，但是后来我问过很多人，很少能对这个问题给出满意答复。我一直笃信的是，对于一个算法来说，了解其运行原理比能调通它的代码更加重要，只有知道本质所在，才能真正因地制宜，收为己用。基于这个出发点，本博客就是介绍 anchor 是怎么对应到原图上的bbx 的？以及由此过程，带来的一些注意事项。

一、 如何确定原图中对应的 bbxes？

要冲anchor设置中在原图中获得对应的 bbxes， 关注两个因数即可：

1. bbxes 中心点位置；
2. bbxes 的高 和 宽。

如下图所示，每个 bbx 的中心点由 backbone 最后一个卷积层后的 feature map 大小确定。如果 feature ma