꺼내먹는지식 준

Object Detection Neck 본문

AI/CV

Object Detection Neck

알 수 없는 사용자 2022. 3. 22. 20:36

Object Detection Neck 

그간 Object Detection 논문들 읽으면서 Neck 에 해당되는 개념들을 아주아주 간단하게 작성하고 넘어갔는데, 드디어 한번 살펴본다. 

 

NECK 이 나오기 전, backbone의 마지막 feature map 으로 ROI 를 수행했다. 

 

NECK은 여기서 backbone의 마지막 feature map만을 활용해야하는 이유가 있을까? 라는 의문에서 뭔가를 해보고자 했다. 

왜냐, 마지막 feature map은 high level 정보를 담고는 있지만, 그 과정 속에서 유실되는 정보도 있고, spatial 정보도 많이 유실 되었기 때문이다. 

NECK 이 왜 필요한가? 

 

결론적으로는 NECK이 없다면 여러 크기의 물체를 감지하는 것이 어렵다. 

즉, 여러 feature map을 활용하면 볼 수 있는 크기가 많아진다. 

(작은 feature map 큰 물체 탐지, 큰 feature map 작은 물체 탐지)

SSD에서 등장했던 아이디어

 

다만 SSD와 같은 방법으로는 아쉽게도 low level(localization)만 담고 충분히 성숙한 semantic 정보를 담고 있지 못하다. 

 

이에 따라 먼저 최종 feature map을 제작한 후, 다시 크기를 키워가며 여러 크기의 feature map에서 여러 물체의 크기를 뽑아내고자 했다. 

 

다만 이러한 과정 속에서 spatial info(low level, localization) 는 점점 유실 된다. 이에 따라 Neck 전 최종 feature map 을 생성하는 과정에서 만들던 feature map을 Neck에서 키워가는 feature map에 더하거나 concat 해서 두가지 강점 모두 반영 

FPN 

이 것이 바로 FPN. 위와 같이 섞인 feature map으로 부터 region 을 뽑아 작은 개체를 더 잘 잡아내게 되었다. 

 

FPN 이전에도 이러한 시도는 있었다. 

이미지 자체의 사이즈를 조절하며 feature map을 뽑고자한 연구가 존재 

 

이미지의 마지막 feature map으로부터 prediction을 하자던 연구 

중간 중간 발생하는 featuremap을 그대로 활용하자. 

SSD 에서 사용한 아이디어! 

 

최종적 등장! FPN 

 

간단한 bottom up, 후 top down으로 high level feature를 low level로 전달

How?

leteral connections 

up convolution + 1 X 1 convolution 

 

botton up 과 top down의 size 가 안 맞는다. 

이를 맞춰주기 위해서 1 X 1 으로 channel을 키우고, up sampling을 통해 shape 을 맞춰준 후 element wise 하게 덧셈 

 

upsampling 예시 

FPN에서는 해당 upsampling사용 

 

FPN backbone: ResNet

4개의 stage, 각 stage마다 feature 를 뽑아내고, 그 feature map 대상으로 leteral connection 추가, 이로 P5 ~ P8 제작 

이 후 RPN 통과하면 (object score에 따라)여러개의 ROI 가 나온다. 여기서 NMS 를 적용해서 1000개 RoI 선택 

 

FPN 은 input stage가 여러개이다보니 RoI가 어느 stage에서 왔는지 알 수가 없다. 

 

RoI대상 projection 진행시, projection 대상의 feature map 이 필요. 이에 따라 다음의 공식 사용으로 몇번째였는지 파악

 

$k = [k_0 + \log_2(\sqrt{wh}/224)]$

 

k_0는 4, featuremap의 크기가 작을 수록 early(low) level임을 알 수 있다. 

 

성능 

a) conv4 , b) 최종 layer 

$\textrm{AR}^{1k}_s$ small 객체 대상 1000장에서의 성능 향상 

 

 

 

문제점

top down path way 로 semantic 을 살렸었다.

문제는 resNet backbone의 길이가 엄청나게 길다. 즉 bottom up 과정에서 low level feature가 high level로 잘 전달이 될 수 있는가? 라는 의문이 존재했다. 

이로 인해 등장한 PANet! 

PANet

엄청 직관적이다. Top down 한걸 다시 bottom up! 

lowlevel feature를 다시한번 high level feature 에 전달을 해주자는 것이 골자. 

마지막 bottom up 은 간단하게 stage 4개만 통과하면 되어서 low level 정보가 보존된다. 

오른쪽 figure 는 사실 정확하지는 않다. 앞단 resNet은 길이가 길어서. 

해당 페이퍼는 instance segmentation을 위해 등장한 paper 라 RoI Align 이 등장 

최종 bottom up 후 얻은 feature map으로 부터 RPN 통과하여 RoI 뽑아낸다. 

각 RoI에 대해 공식으로 몇번 째 stage인지 결정했었다. 

 

하지만 해당 공식은 경계에 있는 RoI에 대해서는 제대로 못 맞췄었다. 

ex. 10 pixel 차이만 나도 stage가 바뀌곤 함. 

low level feature map은 localization, high level feature map은 semantic 정보를 많이 포함했다.

 

이로 인해 특정 feature map만 가지고 projection 하는건 효과적이지 않다는 제안 (다 쓰자.)

 

이로 인해 모든 feature map으로부터 RoI projection 을 한 후 그 후 RoI pooling 하고, FC 를 한 후, max pooling해서 최종 feature map을 만들어내자! 는 것이 골자. 

 

 

 


FPN 이후 NECK 연구의 전성기가 왔고, 그 중 의미 있었던 연구들 

 

DetectoRS 

2021 CVPR

 

Looking and thinking twice 

RPN 에서 아이디어 

모델이 객체를 바로 뽑아내는 것이 아니라 객체가 있을 것 같은 위치를 생각을 하고, 그 후 class와 bbox 위치를 뽑아냄

Cascade (RoI pooling을 여러번)

SAC 는 Neck과 관련이 없어서 생략 

 

RFP 

 

FPN 를 recursive 하게 진행, FPN 과 동일해 보이는 바로위 figure 의 형태를 반복해서 진행 

다만, Neck만 반복하는 것이 아니라 neck 정보를 backbone에도 전달을 해서 backbone도 neck 정보를 이용해서 다시 한번 학습을 하도록 유도한 네트워크 

 

low level backbone이 top level feature를 어느정도 이해할 수 있지만, backbone 연산에 의해 FLOPs 가 엄청나게 증가한다. 

몇번 반복하는가는 선택! 

 

$ \textrm{f}_i = \textrm{F}_i(\textrm{f}_{i+1}, x_i), \textrm{x}_i = \textrm{B}_i(\textrm{x}_{i-1})$

 

F 함수: FPN 함수 

B 함수: backbone 함수 

x: feature map 

f: FPN 결과 

그냥 FPN 을 장황하게 적어놓은 것 

 

RFPN은 해당 식에 하나 추가 

 

$ \textrm{f}_i = \textrm{F}_i(\textrm{f}_{i+1}, x_i), \textrm{x}_i = \textrm{B}_i(\textrm{x}_{i-1},  \textrm{R}_i(\textrm{f}_i)))$

 

FPN에서 backbone으로 다시 넘겨줄 때 수행되는 ASPP: 

Receptive field 를 늘리는 방법

Astrous convolution: 오른쪽 그림처럼 conv 를 진행해서 receptive field 를 강제적으로 키우는 연산 

 

ASPP 는 하나의 feature map에서 pooling을 진행할 때, 이 때 atrous conv의 dilation rate 6,12,18 여러 방법으로 줘서 receptive field 를 점점 키워나가며 pooling 진행.

pooling 된 feature map을 concat 해서 사용하는 것이 바로 Astrous Feature pooling 

 

ASPP를 하는 이유는 결국 receptive field 를 키워주고 싶어서이다. 

https://better-tomorrow.tistory.com/entry/Atrous-Convolution

 

Atrous Convolution

Atrous Convolution 1. 일반적인 convolution 2. Atrous convolution(dilated convolution) 위 두 이미지를 한 번 살펴보자 일반적인 convolution과 달리 atrous convolution의 경우 kernel 사이가 한 칸씩 띄워..

better-tomorrow.tistory.com

해당 블로그 발췌글 

일반적인 convolution와 동일한 computational cost로 더 넓은 field of view(큰 receptive field)를 제공하기 때문이다.

 

위 이미지와 비교해보면

일반적인 convolution의 receptive field는 3 x 3에 불과하지만

atrous convolution 경우 동일한 parameter로 5 x 5의 receptive field를 가져간다.

semantic segmentation의 경우

 

픽셀단위의 조밀한 예측(dense prediction)이 필요하다.

 

classification network를 그대로 사용할 경우 계속 feature map의 크기가 줄어들기 때문에 detail한 정보를 얻는데 어려움이 있다.

(일반적인 convolution)

 

이를 해결하기 위해 deeplab에서는 pooling layer를 없애고,

 

atrous convolution을 이용하여 receptive field를 확장시키는 효과를 얻었다.

 

FLOPs 가 굉장히 높을 수 밖에 없다. 

 

BiFPN 

EfficientDet 에서 제안된 것 

Neck 부분만 살펴보자. 

효율성을 위해서 기존의 PANet을 다음과 같이 바꾸자는 제안 

가운데 figure를 보면 효율성을 위해 featuremap 이 한쪽에서만 오는 경우의 node들을 제거 

이를 통해 모델 구축 더 간단해졌다. 

한가지 더 채택한 방법 

: lateral connection의 단순합 문제점 제기 (담고 있는 정보가 다른데, low + high simple summation 은 정보 교환상 좀 논리적 문제가 있다.)

Weighted Feature Fusion

 

feature 별로 가중치를 두어서 가중 합을 하자. 

가중 합 후, 가중 합으로 normalize

$P_6^{out}$만 봐도 3개의 합이다. $P_6$, $P_6^{td}+P_5^{out}$

이 때도 weighted sum, weighted sum으로 normalize 

NasFPN 

FPN은 휴리스틱하게 사람의 생각대로 구성했다. 

그리고 단순 일방향 이었다. 

 

FPN 구조에 따라서 성능 변화가 있을 수 있는데, 효율적인 구조를 NAS(neural architecture search) 를 통해서 찾아보자! 

성능

엄청난 성능의 증가! 

단점으로는 coco dataset, resnet 기준으로 찾아서 그 architecture에만 사용이 가능하다. 

dataset, backbone마다 매번 NAS 를 해야해서 search cost가 크다. 

범용적이지 않다. 

AugFPN

FPN 문제점 3개 정의

2번

구성 

Neck 과 관련된 부분만 살펴보자. 

resiual feature augmentation 

FPN 에서 low level feature map은 high level stage의 sementic 정보가 쭉 내려와 추가 된다. 

 

하지만 마지막 stage P5를 보면 1X1 conv 와 3X3 conv 만 수행하기 때문에 (받는 정보가 없다)

기존 채널이 줄어드는 즉 information 손실이 발생한다. 

이에 따라 마지막 stage에 어떠한 high level 정보를 보완해줘야 한다. 

이를 위해 Reisual Feature Augmentation을 $C_5$로부터 $M_6$를 만들고,  $M_6$로 부터 top down 정보가 추가되도록 한다. 

 

$M_6$ feature는 어떻게 만들까? 

 

$M_6$ feature 는 $C_5$를 기준으로 만들어진다. 

Ratio-invariant Adaptive pooling을 통해서 $C_5$ feature를 다양한 scale의 feature map으로 만든다. 

 

※Ratio-invariant Adaptive pooling

: pooling stride를 통해서 target feature map의 사이즈를 피라미드 형태 즉, 작은 것부터 큰 것까지 다양한 크기로 생성한다. 

이렇게 생성된 여러 feature map을 Adaptive Spatial fusion을 통해 병합 

 

※Adaptive spatial pooling 

: Transformer 처럼 중요도를 스스로 학습한다. 다양한 scale로 pooling을 진행한 feature map을 만들었다면, $M_6$로 만들어주기 위해 사이즈를 upsampling을 통해 다시 동일한 사이즈로 맞춰줘야 한다. 

(이때 각각의 channel은 256)

  • 3개의 feature map을 단순히 summation 하면 그냥 $C_5$를 활용하는 것과 크게 차이가 없다. 
  • N = 3 
  • 각 3개의 feature map을 concat한다. 
  • 3C X h X w 를 convolution 연산을 통해 C X h X w 로 만든다. 
  • convolution을 통해 3 X (C X h X w) 로 만든다. 
  • sigmoid 연산을 channel wise 로 진행하여 3 X (1 X h X w)로 만든다. 
  • $\rightarrow$ 각 픽셀별로 3개의 value가 나타난다. 
  • $\rightarrow$ 이는 각 픽셀 별로의 중요도를 나타낸다.
  • (N X (1 X h X w) 각 픽셀을 어느정도 수준으로 반영하는가를 결정한다.)
  • 이 후, 해당 가중치를 이용하여 가중합을 한다. 

이 과정을 Adaptive Spatial Fusion이라 한다. 

 

Soft RoI Selection 

Residual feature Augmentation을 해서 앞의 과정에서 얻은 residual feature가 $P_5$에 leteral 하게 connect

이를 통해 $P_5$에는 $C_5$로부터 추출된 정보, 즉 high level 정보가 어느 정도 보강이 되었다. 

 

이 후 $P_5$ ~ $P_2$로부터 RoI를 추출하는데, FPN과 달리 추출된 RoI에서 stage mapping 없이 모든 feature map으로부터 RoI projection을 진행 

PANet의 경우 max pooling 으로 정보 손실이 존재했다. 따라서 정보 손실을 해결하기 위하여 Soft RoI 설계 

최종 정리  

RoI pooling을 통해 고정된 feature vector를 만들고, 

max pooling을 줄여버리고, weight 를 곱하고 summation 진행하였다.

 

성능

 

그냥 갖다 달기만 했는데 성능 향상 

 

정리

 

PANet 처럼 모든 feature map으로 RoI pooling을 하는게 옳다. 

그러나 PANet maxpooling은 정보 손실이 너무 크다. 

단순 summation 도 정보 손실이 있다. 

즉, 가중합을 해야한다. 가중합을 하기 위해서 weight를 뽑아내야하고, 

Soft RoI Selection 이 weight를 뽑아내는 과정 

4 X (C)로 맞춰준다음에 channel wise 하게 sigmoid를 취해줘서 0~1값을 갖게 하고 

원래 있던 feature map에 곱해줘서 더함. 

$\rightarrow$ 이 과정을 통해 weight 계산 부분도 학습이 가능하니, weight도 학습이 가능하다가 페이퍼의 골자 

 

 

'AI > CV' 카테고리의 다른 글

EfficientDet  (0) 2022.03.23
1 stage Detectors  (0) 2022.03.23
MMdetection  (0) 2022.03.22
COCO data 처리  (0) 2022.03.22
mAP란? FLOPs 란?  (0) 2022.03.21
Comments