在上回书中我们已经介绍了FasterRCNN面对旋转框检测问题时可能遇到的问题：https://zhuanlan.zhihu.com/p/105841613

在本章节中，我将介绍几种常见的旋转框检测方法，分析这些方法是如何克服FasterRCNN的问题，从而实现旋转框检测的。另外，我也会简单的分析一下各个方法的优缺点，介绍在实际场景中应用这些方法时可能会遇到的问题。事实上，许多的论文在提出方法的时候会更多的侧重于论文在公开数据集上的表现，但在真实场景中反而会表现不佳。

本文将介绍常见的旋转框检测方法：

RRPN : 更多的框

R3Det : 暴力破解基础下的速度优化

ROITransfomer：三阶段算法的精度提升

all you need is Boundary ：三阶段算法的特殊化应用

1 暴力破解派

一、暴力破解代表：RRPN

1.1 RRPN 简述

在FasterRCNN 的问题当中，我们介绍了使用水平的Anchor 生成水平的Proposal ，进一步预测旋转框时可能会出现的一系列问题。那么，当讨论到这个问题的解决办法时，一个最简单的解决办法，就是从生成水平的Anchor，转变成生成各种不同角度的旋转Anchor：

RRPN ( Arbitrary-Oriented Scene Text Detection via Rotation Proposals ) 的基本思想是，在FasterRCNN 的基础上，对每个按照原先方法生成的框，都“原地”旋转6个角度（上图c），即对每个位置每个尺度(Scale),每个长宽比(Ratio) 的框，都衍生成6个不同角度的框，这样，我们就能够更好的贴合旋转框检测的任务了。因为这种思考方式简单粗暴，在这里我们称他们为“暴力破解派“，即”通过生成更加密集的旋转Anchor 来适应旋转框检测的任务“。

为了实现这种策略，RRPN 当中创新的提出了两个关键的组件:

1、 pairwise_iou_rotated：用于计算任意一个旋转矩形和另一个旋转矩形之间的IoU 的函数

pairwise_iou_rotated：计算各种旋转矩形交叠情况下的IOU

2、RROIPooling/RROIAlign , 在RPN完成之后，通过输入一个任意角度的旋转Proposal，能够返回一个标准的Pooling/Align 的结果，从而可以接入到一个类似于ROIHeads 的结构当中，进一步对目标旋转框的 五个信息进行预测

RROIPooling

整体的论文流程图如下：

介绍RRPN 论文细节的文章有很多，在这里不多做赘述。在detectron2当中也已经将这些内容进行了很好地集成：

RotatedAnchorGenerator:

https://github.com/facebookresearch/detectron2/blob/634770ed51ce3de969557db143d9a673508635b0/detectron2/modeling/anchor_generator.py#L202github.com

RRPN(rotated proposal 生成器)：

https://github.com/facebookresearch/detectron2/blob/master/detectron2/modeling/proposal_generator/rrpn.pygithub.com

RROIHeads：

https://github.com/facebookresearch/detectron2/blob/master/detectron2/modeling/roi_heads/rotated_fast_rcnn.pygithub.com

在这里，我想按照我们介绍的整体思路，看一下RRPN是如何解决上一篇文章当中提到的三个问题的：

1、通过使用旋转的Anchor，优化Anchor/Proposal和GT 的匹配问题。

如图，如果在蓝色点生成如图所示大小的蓝框，并将框绕着蓝点进行旋转，每30°生成一个Anchor，可以看到当蓝框旋转至绿色框的位置时，能够和GT更加的匹配，生成更加合适的Anchor，同理，对应利用绿色区域生成Proposal 信息，Proposal 和GT 的关系会比利用水平框更加贴近

2、使用旋转的框，能够生成更多“接近于”GT样式的框

在上篇文章当中，我们介绍了如果使用水平的Proposal，存在着水平Proposal的高宽和 旋转GT 的真实高宽“相差很大”，导致回归困难的问题。而在RRPN当中，如下图，可以看到旋转Proposal 和真实GT 的高度和宽度“差异性大大降低”，从而使得回归“更加容易”

1.2 RRPN 的问题

在最开始学习的时候，我对RRPN “给予厚望”。我认为这个方法真的能够很好的解决这一系列的问题，加上detectron2 内置了RRPN 的相关函数，几乎“改改配置文件”就能够训练出一个“精妙的模型”，但是在实际操作中，我发现RRPN 实际存在如下的问题：

1.2.1 如何表示一个旋转框？

首先，在标签生成的时候，我们就会直面一个现实的问题？旋转框应该如何表示？

事实上，虽然我们说了可以使用5个值 来表示一个旋转框( )特别指代框的中心位置，但是注意到这个的框表示其实有个bug: 一个框的表示不是唯一的。比如下面这张图，当我们把不同的边作为高和宽的时候，计算出来的角度也会随之发生变化(按照惯例，我们一般把逆时针旋转的角度视为负值)：

总的来说，在带角度的这种框表示方法当中，有三种不同的"流派"：

1. opencv 表示法：

2. 最长边表示法：角度定义为图像的最长边和x轴的角度

3. 以及比较其实肉眼比较直观的表示方式

（在文字检测当中，一般我们会定义文本框左上角的点为x1，顺时针遇到的第二个角为x2，则可以视x1 到 x2 的边为w，对应另一边为h，角度为 x1->x2射线和x轴的夹角）

表达方式不同，在后期模型的训练中，对于负责预测角度对FC层的构造有很大的影响，当想要复现RRPN 或者类似的旋转框检测算法时，需要特别的小心

1.2.2 如何回归

在RRPN 原始的论文中，对角度的回归方法如下：

https://blog.csdn.net/ChuiGeDaQiQiu/article/details/79821576

这里基本可以视为直接回归 gt 和 anchor 之间的角度差。

事实上，所有“基于角度的旋转框表示方法下”，都需要预测Anchor 和GT 的角度差，但是角度回归结果的一点点偏差对于最后结果的影响很大：

R3Det 论文截图

上图是论文R3Det 当中的一个示例图，比如图中的蓝色曲线表示对于长宽比为1：5的框，当把一个框绕着原点旋转任意的一个角度后(如下图从蓝框旋转到绿框的位置)，旋转后的框和原先的框 的IoU值。从图中我们可以看出，当偏差角度在20°的时候，框和原先的框的IOU就只有0.4了。

事实上，RRPN一类的旋转框检测方法，都会有如下的问题：

1、分布在图中的GT 的旋转角度是任意的，而生成Anchor 使用的角度是固定的，但是如上所述，如果生成Anchor 时，使用的旋转角度不足，比如不够每20°生成一个Anchor，就很容易出现尽管生成了很多的Anchor ，但是还是很难有Anchor 能够和GT 具有高的IoU

2、对角度回归出现一点点的偏差，会造成回归的结果和GT的IoU没有那么好，即”角度对学习是很敏感的“，所以计算其Smooth_L1_Loss 并加入到回归偏差中，会使得回归相关的参数不容易被学习

3、角度的变化是不连续的，因此可能会难以被学习，且学习成本很大（SCRDet 对此有详细的介绍和Loss 的设计，这里不展开讨论）

1.2.3 令人崩溃的速度

事实上，上述问题都不是问题，最大的问题在于：慢！

在众多文字检测比赛当中，一张图上其实框很少：

但是在真实应用场景中，一张图上的GT 的数量可能多达几百个(比如报表啊，各种单据)，然后，然后RRPN 就会慢的不行...这主要是因为你需要在每个位置生成足够的框(旋转的角度不够会导致1.2.2 提到的问题)，所以，RRPN 陷入了无尽的自我矛盾：

1、速度不够，增大旋转角度的间隔
2、旋转角度间隔增大，模型的精度一定会下降

介绍完开山之作RRPN, 之后的文章基本就是在此基础之上的不断细化，在本篇专栏之中不做进一步细致的介绍，只是列出大家针对RRPN 提出的一系列的创新，供读者参考和思考。

2 暴力与速度的结合 R3Det

R3Det( Refined Single-Stage Detector with Feature Refinement for Rotating Object ) 主要解决的是RRPN 过程当中的速度问题：

1、使用RetinaNet 构造单阶段目标检测框架
2、使用RefineDet 思想，对FirstStage 一阶段检测结果细化
3、引入了FRM 模块，在一阶段模型当中实现了类似于 ROIPooling 的操作

  3 重新用上RPN：ROITransfomer

3.1 模型结构

事实上，在DOTA数据集(一个航拍旋转物体检测数据集)上，目前得分最高的模型就是这个ROITransfomer模型了，不过基于他复现难度较高，估计大家真正想用起来有点难...

简单的来说，RRPN一个非常直观的问题在于，需要生成大量且冗余的RotateAnchor，所以，一个直观的解决办法是：在RPN阶段，能不能首先先用RPN 水平的Proposal ，并且对于每个Proposal ，通过和GT 的最小包络矩形进行IoU计算分配正负样例，训练出一个生成水平Anchor 的Proposal:

没错，虽然之前我们抛弃了这个思路，但是当时我们说过，其实FasterrRCNN是有能力在最终给出包络住物体的框的，所以其实这种思路生成RPN也是行的通的，但在当前思路下，如何回归GT 的旋转坐标呢？这里文章的思路其实很类似于R3Det，盗用R3Det的一张图：

如果GroundTruth(R) 是我们的GT，即最终希望预测的结果，在ROITransfomer这里的操作其实很类似于CascadeRCNN，即首先从绿框(Anchor) 利用ROIPooling/ROIAlign 的方式回归到一个旋转的结果RefinedBbox，在两阶段的网络结构中，模型推断到这里就应该结束，但事实上，我们可以再做一步，通过使用一个RotateROIPooling，输入黄色的旋转框，再进一步修正框的坐标信息，获得最后的预测结果

通过在中间加一层网络结构，能够使得模型的预测结果更加精准，具体而言，文章的基本思路如下：

这里的RROI Learner 就是第一次的ROIPooling，但是文出于对速度的考量，换成了更快速的PSROIPooling，而ROIWarping 就是第二阶段的框的精修，文中提出了一种新的pooling方式，但是对于我们想快速尝试，可以试试使用RotateROIPooling 替代

3.2 复现困难

我曾经试过使用简单的ROIAign+RROIAlign的策略实现过三阶段的算法，不得不说，虽然减少了框的数量，但是实际上如果不类似于原文，替换为PSROIPooling或者类似于LightHeadRcnn 的网络结构，推断速度是十分不给力的

同样，在复现AnchorBased类型论文当中，Matcher 部分的不一致问题始终是一个很难以解决的问题：

1、如果使用RPN 生成水平的Anchor ，则在RPN训练中，Anchor 和 GT 进行Matcher 匹配的时候,应该是使得Anchor和GT的包络矩形进行比较。

2、则这样RPN生成的Proposal，基本都是"包着GT"的，如下图展示的Proposal，但是在第二轮需要和旋转GT 进行Matcher 的时候，会发现生成的Proposal 如果是和GT 的旋转框进行IoU计算的话，实际上就算是最包络的Proposal ， 和 GT 的IoU值都可能很小（如下图的”单位:人民币元“）

  4 All you need is Boundary：最有技巧的三阶段模型

没啥说的,阿里的文章,技巧极其复杂,复现极其困难.速度嘛,反正用detectron2的话,三阶段都不算快, 这篇中心思想和第三篇类似，但做的更加tricky，感兴趣的可以去看看。

总的来说，第三篇在三阶段仍旧回归框坐标，但是这篇直接回归了文本的”边界点“：

图a) : 从RPN 回归至旋转框

图c): 从旋转框回归到文字边界

论文的基础框架和核心如下：

（两阶段的框检测+一阶段的边界检测）= 三阶段方法