论文阅读: Faster R-CNN

Introduction

作者的本意说白了就是：

让 ‘生成RP’ 这个task也能享受到GPU的利好。

RP原本主要用SS (Selective Search) 来生成，只能在CPU上跑。一张图片生成~2,000个proposal，效率0.5fps，实在太慢。 想让GPU来揽下这个活儿，就必须把问题转换成GPU能接受的任务形式：network。

对应的，设计出来的network自然就叫 RPN (Region Proposal Network) 了。 RPN抱上了GPU的大腿，每张图片还是生成~2,000个proposal，但是效率飞跃到了100fps。

Structure

以下是我画的Faster R-CNN结构：

RPN

RPN的本质是 “ 基于滑窗的无类别object检测器 ” 。

以下是我画的RPN结构：

RPN的运用使得region proposal的额外开销就只有一个两层网络。 从此，“生成RP”的市场被RPN完全垄断了。 至于one-stage系，它们压根不需要生成RP，自然也就从未引进RPN。

Note：

• 不生成RP的Detection算法都是one-stage系；
• 生成RP的Detection算法都是two-stage系或者古老的multi-stage系(Cascade R-CNN这种four-stage属于例外)。

Anchor

没有了SS，network要如何“从无到有”地生成~2,000个proposal呢？RBG大神想到了在输入RPN的feature map (起初是topmost，后来变成multi-scale) 上穷举出anchor。

Note：

• “anchor”这个名词是Faster R-CNN第一个提出来的。前人也有过类似尝试，但没有研究这么深。

后来的SSD承接了Faster R-CNN的设计，选用的“anchor套餐”和Faster R-CNN不一样：

从multi-scale的角度看：

• SPPNet第一个提出了multi-scale，但只是在topmost feature map上尝试通过SPP Layer(多scale的max pooling)来实现的multi-scale；
• Fast R-CNN在该方向无作为；
• Faster R-CNN号称自己的multi-scale anchor能够好过你们这些pyramid；
• 在FPN(+Faster R-CNN)时，feature map已经具有了multi-scale，anchor在每层feature map上就只需要单scale了；
• RetinaNet虽然沿用了FPN作为basemodel，却发现在multi-scale的feature map上再分别玩multi-scale anchor(通过anchor分别乘上20202^{0}、21/321/32^{1/3}、22/322/32^{2/3}来实现)，效果更好，并采用之；
• SSD第一个在multi-scale feature map上尝试“multi-scale”；
• 由于意识到了multi-scale对精度的重要影响，后人(除了YOLOv1)都把“multi-scale”作为了标配。

Loss

Faster R-CNN一共有4个loss，包括：

• RPN 的 二分类(1+1)loss、reg loss ；
• RoI-wise network 的 全分类(k+1)loss、reg loss 。

Innovation

RPN的出现，使得SS走入历史。

speed上：

• 解决了two-stage系的 proposal生成慢 的瓶颈(数量并没有发生多少变化)。

accuracy上：

• 对 Fast R-CNN 的一次大提升 (因为RPN生成的proposal质量肯定高过Selective Search生成的) 。

Result

• ILSVRC2015 1st-place
• COCO2015 1st-place

Thinking

Faster R-CNN将Fast R-CNN中的“网络化”趋势做到了极致，实现了“All in one network”。

[1] Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks