旋轉框檢測方法綜述:RotateAnchor系列

在上回書中我們已經介紹了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個值

總的來說，在帶角度的這種框表示方法當中，有三種不同的"流派"：

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 的操作

簡單來說，算法的創新點在於在RetinaNet + RefineDet 的基礎之上，使用FRM 模塊實現類似ROIPooling 的效果。算法對比與RRPN，主要是實現了OneStage的模型框架，但在基於detectron2的框架進行復現時，感覺速度還是不夠快。  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): 從旋轉框回歸到文字邊界

論文的基礎框架和核心如下：

（兩階段的框檢測+一階段的邊界檢測）= 三階段方法