인공신경망(SOLOv2)의 data pipeline의 구성과 Resized model의 효과

1. SOLOv2 data pipeline

1. 데이터 전처리 흐름

SOLOv2는 다음과 같은 과정을 거치면서 모델 입력을  준비한다.

 

이미지를 로드하고, Annotation을 로드하고, resize하고, flip하고, normalize하고, pad를 추가하고, format을 재설정 하고, 앞선 결과들을 수합하여 meta data로 재구성한 후, 이 결과를 모델로 흘려보낸다.

 

mmdetection에서 이 과정을 config file로 쉽게 설정할 수 있다. SOLOv2의 config안에서 data pipeline부분을 한번 확인해보자.

이렇게 train_pipeline (test_pipeline)은 dictionary 객체들로 구성되어 있는데, 각 dictionary 객체는 데이터 전처리 과정에서 필요한 기능의 이름과, 그 기능에 전달할 인자가 정의되어 있다.

이렇게 정의된 data_pipeline의 dictionary 배열은 mmdetection의 init_detector를 호출할 때 전달되고, 모델을 만들 때 transform 모듈안에서 type의 이름을 바탕으로 다른 모듈과 인자들을 불러오고 이런 모듈들을 이어 붙여 data pipeline을 구성하는 것이다.

 

2. Multi-scale training

여기서 Resize에서 img_scale의 인자가 list로 여러가지 전달되는 부분이 의아해서 서치를 해보았는데, 이를 multi-scale training이라고 부르는 것을 알게 되었다. 이렇게 multi-sclae training을 하는 이유는 다양한 크기로 학습하여 더 일반적인 모델을 구성할 수 있고, 이는 곧 성능의 향상을 야기한다고 한다.

위 experimental result는 SOLOv2의 training schedule에 따른 성능 비교이다. 물론 single-sclae training이냐, multi-scale training이냐는 요인 외에도 1 x means 12 epochs냐, 3x means 36 epochs냐는 차이도 있겠지만, 다양한 모델의 config file을 보았을 때 multi-scale training을 활용하는 것을 보면 꽤나 효과있는 방식이라고 유추할 수 있다.

 

3. 실제 전처리 실행 시간의 분석

실제 데이터 전처리 시간을 한번 확인해보자. 다음은 original model의 coco data 데이터 전처리 시간의 비교이다.

이미지 로드와 normalize외에는 모델에 성능에 그렇게 큰 차이를 가져오지 않음을 확인할 수 있다.

 

2. Reszie model

1. Resize model의 실험적 결과

앞선 SOLOv2의 config file을 통해 우리는 기존 SOLOv2가 1333, 800의 크기로 이미지를 resize함을 확인했었다. 그에 따른 시간도 분석했었는데, resize된 크기는 비단 resize의 실행시간 뿐만 아니라, 줄어든 크기로 인한 conv연산의 감소도 존재한다. 따라서 이를 직접 분석해보았다.

original model

resize model

다음은 coco data의 test결과이다. 속도는 1.6배나 빨라졌고, AP의 감소는 별로 없었음을 확인할 수 있다. 하지만 이 것이 cooc data에만 한정적인 결과일 수 있을것 같아, 4K이미지에 대한 실생시간을 비교하였다.

 

original model

resize model

아까와 다르게, 17%정도만 빨라짐을 볼 수 있었다. 직접 inference해보는 과정에서 AP수치 뿐만 아니라 instance mask의 결과도 약간 차이있음을 볼 수 있었다. resize model의 경우, original model에 비해서, 디테일이 약간 부족하고, 좀 더 관대하게 mask를 만들어 냄을 볼 수 있었다.

 

2. Resize model의 결과 분석

이미지 크기에 따른 속도 비교를 보았는데, 이는 약간의 의문이긴 했다. 왜냐하면 resize 자체의 시간은 그렇게 크지 않고, backbone에 들어가는 크기는 같으니까, 시간도 유사하지 않을까? 라고 생각햇는데 SOLOv2의 특징때문에 그렇지 않았다.

아래는 SOLOv1의 대략적인 실행 흐름도이다.

resize를 통해 아무리 같은 크기의 이미지가 들어가더라도 mask를 만들 때는 원본 이미지 크기에 대한 mask를 만들기 때문에 시간이 backbone과 category보다 mask의 시간에 매우 종속적이게 된다. 그렇기 때문에 앞선 결과가 도출된 것이다.