잡담:
Academic 한 관점에서 연구를 하며 힘든 순간 중 하나는
내가 나름 기발하다고 생각했던 발상이 이미 논문으로 나와 있는 경우다.
지금까지 생각해 낸 아이디어 중 70% 정도는 아마 이렇게 묻히지 않았나 싶다.
나머지 30% 중, 귀찮음, 시간 없음, 그냥 안 함 등의
이유로 실제로 구현까지 가는 아이디어는 전체의 10% 정도?
흥미롭게도 이렇게 남겨진 20%의 아이디어들은 누군가가 곧 정리해서 논문으로 내버린다.
그럴 때 드는 생각은 크게 2가지인데,
- 별로 못 쓴 논문인 경우에는 내가 얼른 할 걸.
- 잘 쓴 경우에는 고래싸움에 괜히 뛰어들지 않기를 잘했다.
간단히 말해 "내 좋을 대로 생각한다"라는 의미이지만
아무튼 비슷한 분야를 연구하는 사람들 (에디슨 vs. 테슬라?)은 역사적으로도 항상 비슷한 생각을 해왔다.
사실, continuous 한 관점에서의 SR을 생각한 건 2018년 가을이었는데
이경무 교수님의 수업 프로젝트 주제를 정하다 보니
기존의 SR 알고리즘들이 항상 고정된 스케일만 다루는 것이 조금 아쉽다는 생각이 들었다.
그래서 다양한 방법으로 사용 가능한 continuous-scale SR 모델을 만들어보자!라는 proposal을 제출했는데
이유는 모르겠지만 다른 것에 꽂혀서 (+ 귀찮아서?) 주제를 바꿨던 기억이 났다.
그 직후, Meta-SR이라는 paper가 CVPR 2019에 accept 됐다는 소식을 듣고
아쉬운 감정과 다행스러운 감정이 교차했다.
아무튼.
지난 CVPR에는 Meta-SR 등의 arbitrary-scale SR 모델을
homography 등의 일반 transformation에 사용할 수 있지 않을까 하는 생각으로
SRWarp라는 확장된 개념을 제안했다.
솔직히 아주 마음에 드는 결과는 아니었지만 (자기 연구가 아주 마음에 드는 사람이 얼마나 있을까?)
뭔가 최대한 빨리 해야겠다는 촉이 와서 서두를 수 있었고, 다행스럽게도 좋은 리뷰를 받아 accept 되었다.
이와 동시에 이웃 연구실의 김미정 님이 혹시 이런 건 관심 없으시냐고 논문을 하나 보내주셨는데,
그게 이번에 정리해 놓을 LIIF다.
(평소에 개인적으로 이야기를 해본 적도 거의 없는데
어찌 내 관심 주제를 잘 기억하시고 알려주신 거에 대해 상당히 놀랐고 감사했다.)
잘 뜯어보니, Meta-SR이랑 큰 차이는 없음에도
해당 work이 나온 뒤에 내 SRWarp를 내는 것은 꽤 난이도가 있겠구나 하는 생각이 들어서
이번에 서두르기를 참 잘했다는 생각이 든다.
개인적인 사정으로 가뜩이나 힘들었던 연초를 덕분에 잘 버틸 수 있었던 것 같다.
기왕 리뷰도 잘 나왔는데 spotlight이라도 하나 받았으면 더 좋았겠지만.
개인적으로 생각하는 SR 관련 연구의 최종 목표는 유저가 자유롭게 사용 가능한 application을 개발하는 것이다.
이를 위해서는 아직도 많은 관문들이 남아있는데, 그중 하나가 output의 크기를 자유롭게 조절하는 것이다.
의외로 딥러닝 쪽 초기 연구인 SRCNN이나 VDSR 등에서는 이러한 고민이 굉장히 적었는데,
Bicubic 보간법 등을 사용해 일단 input을 원하는 크기로 조절하고
그 후 SR 모델을 적용시키는 접근법을 채택했기 때문이다.
예를 들어 $128 \times 128$ input을 $300 \times 300$으로 만들고 싶다면 큰 고민 없이
일반적인 resizing 알고리즘으로 input을 $300 \times 300$으로 만든 뒤에 모델을 적용한다는 것이다.
물론 효과적인 솔루션이긴 하지만, 여기에는 크고 작은 두 가지의 문제가 있다.
- input이 커지면 크기의 제곱에 비례하여 계산량이 올라간다.
예를 들어 input이 가로세로 3배 커지면 계산량은 제곱인 9배만큼 늘어나는데,
말도 안 되는 수치라는 걸 알 수 있다. - 아주 치명적인 건 아니지만, 보간법을 미리 사용하는 것 자체가 sub-optimal 하다.
Bicubic 보간법을 예로 들자면, 0~255 바깥의 값을 만들어내는 경우가 비일비재하며
input data를 어떤 식으로든 건드는 과정이기 때문에 해당 resizing 알고리즘이
optimal choice가 아닌 경우에 단점이 될 수 있다.
이러한 한계들을 어느 정도 해결해주는 것이 ESPCN에서 제안된 sub-pixel convolution (혹은 pixel shuffle)이다.
사실 transposed convolution과 큰 차이는 없다는 주장도 있지만,
아무튼 ESPCN 이후로 SR 모델들은 input의 크기를 조절해서 원하는 크기의 output을 만들기보다는
특정 레이어를 사용해서 중간 feature의 크기를 조절하는 것으로 훨씬 효율적인 계산을 구현했다.
그런데 이런 레이어들은 CNN이 regular 한 grid 위에서 정의되어 있다는 점 때문에 본질적인 한계를 갖는데,
정수배의 scale이 아니면 적용하기 힘들다는 것이다.
그러니까 효율적인 알고리즘을 구현하고자 새로운 레이어를 개발했는데,
이전에 아무렇지도 않게 사용하였던 arbitrary-scale 개념을 쓸 수 없어졌다는 trade-off가 생겨버렸다.
그런데 연구의 관점에서는 computation을 절약하는 게 (scale이 클 때는 order of magnitude 수준으로)
조금 더 중요하기도 하고, 만약 arbitrary-scale SR 모델이 필요하다면 적당히 사용할 수 있는 대체제가 있기 때문에
Sub-pixel convolution은 암묵적인 표준으로 인정받게 되었다.
여기서 말하는 대체재라는 것은, 만약 $\times r$의 SR 결과가 필요하다면
$s \gt r$인 임의의 $\times s$ 모델을 사용해서 우선 적당히 큰 output을 만들고,
이를 bicubic 보간법 등으로 줄여서 최종 결과를 얻는 것이다.
당연히 어느 정도 잘 작동하지만 근본적인 한계는 있다.
SR은 구조상 scale이 커질수록 문제의 난이도가 급격히 어려워진다.
예를 들어 $\times 4$와 $\times 8$은 단순히 2배의 scale 차이가 난다고 생각할 수도 있지만,
$\times 4$ 모델은 하나의 픽셀로부터 16개의 픽셀을 생성해야 하는 반면
$\times 8$ 모델은 그보다 48개나 많은 64개의 픽셀을 생성해야 한다.
이 말은 곧 $\times 8$ 모델의 성능에는 어느 정도 한계가 있을 수밖에 없다는 뜻이고
만약 $\times 2.5$의 결과가 필요한데 $\times 8$ 모델을 적용하고 이를 축소시키고자 하면,
애초에 $\times 8$ 모델이 생각보다 쓸만한 결과를 만들지 못할 수도 있다.
Meta-SR paper에서는 조금 더 다양한 셋업에서 이러한 SR 후 resizing 파이프라인이
sub-optimal 하다는 것을 실험적으로 보였다.
다시 말해, $\times 2.5$의 결과가 필요하면 해당 scale을 고려하여 모델을 학습하는 것이
제일 좋은 결과를 준다는 것인데, 여기서 또 고려할 사항들이 생긴다.
- 모델이 임의의 scale로 확장된 순간, 기존의 딥 러닝 기반 SR 방법들에서 일반적으로 채택하던
하나의 모델 = 하나의 scale의 가정이 깨지게 된다.
별다른 이유가 있는 것은 아니고, $\times 2.5, \times 2.51, \times 2.52, \cdots$ 모델들을 일일이 만들어 놓을 수는 없으니까. - 그러면 이제 하나의 모델이 여러 (임의의) scale을 처리할 수 있어야 할 텐데,
당연히 이 방법을 우선 고민해야 하고 - 애초에 임의의 scale 개념이 일반적인 CNN에서는 straightforward하지 않은 개념인데,
이를 어떻게 다룰지도 고민을 해야 한다.
LIIF에서는 이러한 요소들을 'implicit function'이라는 개념을 통해서 한방에 해결한다.
사실 이런 문제에 대한 솔루션을 처음으로 내놓은 것은 Meta-SR이고
의외로 Meta-SR과 LIIF를 꼼꼼히 비교해보면 writing이나 설명하는 관점이 많이 다를지언정
실제 아이디어를 구현하는 방식에는 큰 차이가 없는 것을 알 수 있다.
자세한 얘기는 다음 포스트에 정리하도록 하고,
일단 Meta-SR과 LIIF의 근간이 되는 배경 지식을 좀 정리할 필요가 있는데, 아래 포스트들을 참고.
'논문 읽기' 카테고리의 다른 글
| [CVPR 2021] LIIF: Learning Continuous Image Representation with Local Implicit Image Function (2) - Method (0) | 2021.05.07 |
|---|