나무모에 미러 (일반/어두운 화면)
최근 수정 시각 : 2024-11-02 21:39:48

프레임 보간

프레임 더블링에서 넘어옴
1. 개요2. 기법
2.1. 프로그레시브(예:60i→60p) 동영상으로 변환하기2.2. 모션 인터폴레이션(Motion Interpolation)
2.2.1. 원리2.2.2. 지원하는 하드웨어 및 소프트웨어2.2.3. Avisynth 설정법
3. 단점4. 참고 문서

1. 개요

파일:3066c4bfb18.jpg

기존의 동영상 또는 실시간 렌더링 영상의 프레임을 올려주는 작업을 말한다. 이 경우 기존의 동영상 화면이 떨리는 등의 현상을 상당히 줄여주고 보다 자연스럽게 화면이 나오도록 할 수 있다. 또한 LCD TV 등에서 잔상을 줄이기 위해 프레임 더블링 기술을 사용하고 있다.

영어로는 모션 인터폴레이션(Motion Interpolation) 으로 불리며 게임에 사용하는 경우에는 프레임 제네레이션(Frame Generation)이라 불린다.

2. 기법

2.1. 프로그레시브(예:60i→60p) 동영상으로 변환하기

파일:external/upload.wikimedia.org/Interlaced_Animation.gif

디인터레이싱 항목 참고.

송출 용량을 줄이기 위해 주사선에 맞추어 만들어진 인터레이스(Interlaced) 동영상을 프로그레시브(Progressive)동영상으로 바꾸는 작업이다.

주로 동영상 주사선으로 잘게 나눠진 화면을 고르게 교정한 다음에 프레임 수를 60프레임으로 변환시킨다.

이 경우 모션 인터폴레이션에 비하여 상당히 간단하게 이뤄지는 경우가 많으며 주로 PC모니터 같이 프로그레시브 출력장치에서 HDTV동영상을 자연스럽게 보기 위하여 이용하는 경우가 많다. 현재 판매되는 대부분의 그래픽카드와 평판 TV가 60i→60p 프로그레시브 변환 기능을 하드웨어로 지원하고 있다.

아예 없는 프레임을 만들어내서 2배로 불려야 하는 30p에 비하면 60p로 보간하는 것이 쉬운 편이지만, 세로 해상도를 아무 열화나 왜곡 없이 100% 완벽하게 디인터레이싱하는 건 사실상 불가능하다보니 아무래도 네이티브 60p/30p 동영상에 비해서는 화질은 떨어진다.

2.2. 모션 인터폴레이션(Motion Interpolation)

2.2.1. 원리

파일:external/www.e-trend.co.jp/idx_09_img_02.jpg
[1]

광학 흐름을 구현해 프레임 사이 사이에 GPU나 CPU 연산을 통해 예측된 가상의 이미지를 프레임으로 만들어서 동영상 프레임 사이에 삽입하여 프레임 수를 늘리는 방식이다. 지포스 RTX 20 시리즈부터는 광학 흐름 전용 가속 유닛도 지원하며, RTX 40부터는 게임용(DLSS 3)으로도 쓸 수 있게 성능이 강화되었다.[2] 이 경우 프로그레시브 30프레임 동영상을 흡사 프로그레시브 60프레임 동영상처럼 변환시킬 수 있다.

하지만 움직임이 격하거나 글씨가 존재하거나 화면 테두리에 대상이 걸쳐 있는 상태로 움직일 시 예측 실패로 인한 인위적인 노이즈 비스무리한 아티팩트(artifact)가 생기게 된다. 이런 현상은 애니메이션 쪽에서 특히 두드러져 보이는데 실사는 움직임이 끊김 없이 잘 이어지는 반면 애니메이션은 하나하나 다 수작업으로 그리기 때문에 프레임 간이 완벽하게 이어지지 못 하고 일부러 이어지지 않게 하는 기법도 많이 사용하기 때문이다. 그 외에는 상당히 자연스럽게 나오기 때문에 상당히 선호되는 기술이다. 현재 TV에서는 사용되는 경우가 많지만, 컴퓨터에서는 기술 상의 문제와 홍보 부족 등으로 제대로 활용되지 못하고 있다.

단점 문단에서도 후술하지만 24와 60는 맞아 떨어지지 않아서 60hz 디스플레이에서 영화 등의 쌩 24프레임 영상을 정상적으로 재생할 수 없으므로, 이걸 해결하는 전통적인 방식이 따로 존재한다. 다만 인터레이스 시절 방식이다보니 CRT로 보는게 아닌 이상 일정 주기로 주사선 잔상이 생기기 때문에, 최근엔 프로그래시브로 응용한 방식도 사용된다. 일정 주기로 프레임을 필드로 뒤섞어서 불리기/한번 더 반복하기라 인공적으로 추가되는 프레임은 없다는 게 차이점. 전술했듯 60이 24의 정배수가 아니기 때문에 24프레임은 60프레임보단 48프레임으로 보간하는게 더 자연스럽다. 최근 TV는 24프레임을 그대로 재생하거나 48프레임으로 보간할 수 있는 48hz를 지원하는 모델도 있다. 72~75Hz나 144Hz 모니터라면 72프레임으로 보간하는 선택지도 있다.

프로그램에서는 Splash Pro player 등에서 지원하고 있으며, 플러그인으로서는 AviSynth + SVPflow[3][4] 조합으로 이용되고 있다.
AviSynth+SVPflow의 경우 ffdshow video decoder를 이용하여 실시간으로 모션 인터폴레이션을 이용하거나 MeGUI를 이용하여 인코딩 용으로 사용되는 경우가 많다. 다만 AviSynth 스크립트는 영어로 작성해야 하며, 필터마다 사용되는 파라메터등이 복잡하게 구성되어 어느 정도 공부를 해야 한다.

2.2.2. 지원하는 하드웨어 및 소프트웨어

2.2.3. Avisynth 설정법

다음 팟플레이어 등에서 AviSynth를 사용할 수 있으며 InterFrame2 필터를 이용해 실시간 프레임 더블링 재생이 가능하다. 단 CPU의 성능을 상당히 잡아 먹는다는 점에 유의할 것.[11]

단, 이 필터는 64비트 동영상 플레이어에선 지원하지 않는다. 64비트 플레이어는 AviSynthPlus를 사용하면 된다. AMD 사용자의 경우 위에 소개된 플루이드 모션을 이용하면 더 간단하면서 동일한 효과를 얻을 수 있다.[12]

AviSynth InterFrame2 스크립트의 예: (팟플레이어의 Avisynth 설정에 아래 스크립트로 간단하게 60프레임으로 만들 수 있다)[13]

#!syntax cpp
SetMTMode(6,CPU 스레드 수)
potplayer_source()
SetMTMode(2)
InterFrame(Preset="Medium", Tuning="Animation", GPU=true, Cores=CPU 코어 수)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

동영상이 버벅거릴 경우 Preset의 Medium을 Fast로 변경하면 된다.

허나 현재는 위 스크립트에 오류가 나서 적용되지 않고 노란색 스크립트 에러가 뜬다.
단 팟플레이어 AviSynth 스크립트 매뉴에 자동으로 추가된 항목들이 있으니 그걸 이용해보자

가장 빠르면서 프레임 연동되는 스크립트로는 이렇게 짤 수도 있다. 이렇게 짤 경우, 스크립트를 일일이 다른 걸로 불러오거나 해제할 필요 없이 동영상 프레임에 따라 자동적으로 연동되어서 번거로움이 줄어든다.
하단에 나와있는 framerate ? eval 부분은 조건 연산자다.

#!syntax cpp
SetMemoryMax(128)
SetMTMode(1,0)
potplayer_source()
super=MSuper(pel=1, hpad=0, vpad=0, chroma=true, sharp=0, rfilter=0)
backward=MAnalyse(super, chroma=false, isb=true, search=0, searchparam=0, pelsearch=0, truemotion=true, blksize=16, blksizev=16)
forward=MAnalyse(super, chroma=false, isb=false, search=0, searchparam=0, pelsearch=0, truemotion=true, blksize=16, blksizev=16)
Framerate ← 26 ? Eval("""
MBlockFps(super, backward, forward, num=60, den=1)
""") : Framerate ← 30 ? Eval("""
MBlockFps(super, backward, forward, num=FramerateNumerator(last)*2, den=FramerateDenominator(last)*1)
""") : Framerate ← 50 ? Eval("""
AssumeFPS(30, 1, true)
MBlockFps(super, backward, forward, num=60, den=1)
""") : Framerate ← 60 ? Eval("""
MBlockFps(super, backward, forward, num=FramerateNumerator(last)*1, den=FramerateDenominator(last)*1)
""") : Framerate ← 120 ? Eval("""
AssumeFPS(24, 1, true)
MBlockFps(super, backward, forward, num=60, den=1)
""") : last
GetMTMode(false) > 0 ? distributor() : last

자세한 설정법

3. 단점

영화 같은 프리렌더링 영상이 아닌 게임 등의 리얼타임 영상 프레임 보간 기능은 GPU가 데이터등을 처리하는 시간을 늘리기에 입력지연 등 레이턴시 문제가 발생한다. 리플렉스나 라데온 지연방지로 어느정도 제어가 가능하나 원본 프레임레이트가 낮거나[14], 프로게이머 수준으로 가면 체감될 수 있다.

24프레임으로 제작되는 영화의 경우 프레임 보간을 적용하면 이질적인 느낌이 심하게 든다. 소위 말하는 필름 룩이 훼손되기 때문이다. 사람 눈의 구조상 24프레임 모션은 그 특유의 느낌을 가지며[15], 이를 바꾸면 호불호가 갈릴 수밖에 없다. 불호가 심한 경우 순수 48프레임~120프레임으로 촬영한 HFR 영화에도 불만을 표하기도 한다.

또한 대다수 극장 영화들의 전통적인 연출, 촬영 기법들은 당연히 거의 100년 가까이 24프레임 특유의 움직임을 기준 삼아 만들어지고 이어져 왔기 때문에[16] 프레임을 보간하면 감독의 의도한 결과물과는 다른 영상이 되어버리는 경우가 많다. 때문에 영화 업계에서는 프레임 보간 기술이 영화 고유의 영상미를 해친다고 원본대로 감상할 것을 권장하고 있다. 그러나 가전 대기업들에서는 프레임 보간 기능을 가진 TVR를 2000년대부터 출시해왔으며, 중고급 TV면 프레임 보간이 기본 기능으로 들어있고 거의 무조건 별도의 안내 없이 디폴트로 켜놓는다. 해당 기능은 본래 3D TV의 핵심 기능 중 하나였는데 3D TV가 폭망하면서 해당 기능만 살아남아 기본 기능으로 편입된 것. 톰 크루즈는 이런 TV 업계의 행태에 반발하여 모션 스무딩 옵션을 꺼달라는 트위터영상을 올리기도 했다.

다만 시네필이 아닌 일반 대중의 경우 이런 영상 보정을 구분 못하는 경우도 많고 오히려 영상이 부드럽다며 좋아하는 경우도 많다. 프레임 보간을 다룬 영상의 댓글란을 보면 알 수 있다. 보간이라는 과정을 거치는 이유가 있기에 어찌보면 당연한 결과다. 원본을 훼손한다고 프레임 보간을 싫어하는 사람이어도 디인터레이싱[17]이나 업스케일링을 할 땐 어지간하면 보간은 한다. 사실 진짜 프레임 보간을 극단적으로 싫어하는 사람이라면 애초에 저 둘도 정말 어쩔 수 없을 때 아니면 안하긴 한다(...). 결국 취향 차이란 얘기.

보간 자체에 대한 호불호와는 별개로, 24프레임 실사 영상은 보간이 중간 프레임을 재현해내는 것이 애니메이션 영상에 비해 훨씬 자연스럽다. 실사 영상은 당연히 대체로 현실에 있는 물체를 찍으므로 화면 간에 일종의 불연속이나 첨점이 많지 않고, 무엇보다 현실의 카메라셔터 스피드의 개념이 있어서[18] 빠른 움직임은 원본 자체도 전혀 뚜렷하지 않은 흐릿한 잔상과 잔상의 연속이기 때문에 보간 또한 중간 프레임으로 자연스럽게 적용된다. 모든 장면이 연속적이므로 보간의 결과가 오히려 현실과 가까워지는 것이다.

반면 애니메이션 영상, 특히 전통적인 2D 프레임 애니메이션은 물리법칙을 무시하고 갑자기 화면 전환이 일어나거나 캐릭터가 순간 이동하거나, 의도적인 작붕 프레임을 넣는 경우가 많고, 결정적으로 실사 영상과는 달리 프레임을 한장 한장 그리는 것이므로 셔터 스피드의 개념을 적용할 수 없기 때문에 연속적이고 빠른 움직임에도 프레임마다 아무런 잔상이 없다.[19] 그리고 실사 영상에 비해 선과 면, 명암, 색채 등의 화면 정보가 때로는 극단적일 정도로 훨씬 단순하고 뚜렷한 점이 오히려 '자연스러운' 보간에는 걸림돌로 작용한다.[20] 이런 점들 때문에 2D 프레임 애니메이션은 보간을 할 경우 (특히 빠른 움직임에선) 중간 프레임이 어느쪽도 아닌 흐릿하고 깨진, "인공적으로 만들어낸" 티가 팍팍 나는 비주얼로 생성되기 굉장히 쉽다.참고 영상

특히 FRC의 패치 방향이 원래 화면을 적게 사용하더라도 일정한 간격의 프레임을 재생하는 것에 치중하다보니 깨지지 않는 원화를 보여주는 것이 퀄리티에 더 유리한 애니메이션과는 궁합이 잘 맞지 않는다. 최근 몇년간 플루이드 모션이나 프레임 보간 자체가 애니메이션을 더 부드럽게 보기 위해 각광받았던 것을 생각하면 아이러니한 결과. 다만 보간법에 따라 달라질 여지는 있다. 그래서 과거에는 FRC 상에서 모드1과 2를 설정하여 원래 화면을 살리면서 칼같은 블렌딩을 적용할지, 보간을 적극적으로 하여 좀 더 '부드러운' 화면을 보여줄지 선택할 수 있었는데 이것이 일원화되는 것으로 변경개악되어 애니메이션용으로는 안타까운 결과를 가져왔다. 그나마 토파즈 비디오 AI의 아폴로 알고리즘에서 원본 프레임의 정수배를 맞춰 쓰면 원본 화면을 살리는 편인데, 트랜스코딩(변환 저장)용 프로그램이라 실시간 보간의 편의성을 원하는 사용자층엔 부합하기 어렵다.

22년 이후 DLSS나 FSR 등 프레임 보간 기술이 게임 산업에서도 본격적으로 활용되기 시작했으나, 일정 프레임 이상을 더 부드럽게 만들어준다는 당초 개발의도와는 달리 최적화를 개떡으로 해도 보간으로 60프레임 찍으면 만사형통식의 편법처럼 남용되고 있다. 네이티브 30프레임을 기준으로 잡는 경우가 차고 넘치는 상황.

4. 참고 문서



[1] 프레임 2배수 방식의 예시. 다만 위 이미지는 광고용 이미지이며, 실제로 프레임간의 변화가 아주 큰, 아주 역동적인 움직임의 경우 보간 시 쉽게 뭉게진다.[2] # "DLSS 3: RTX 40 전용? 상술아냐?" 부분 참고, SVP 개발자 말로는 4K 60프레임이 넘으면 영상 보간용으로도 유의미한 성능 차이가 날 정도라고 한다.[3] AviSynth에 SVPflow 플러그인을 추가한 것이다. 실질적으로 프레임 더블링을 수행하는 것은 SVPflow필터이고 AviSynth는 비선형 비디오 편집 프로그램으로 스크립트를 기반으로 다양한 영상 처리 필터 및 플러그인 등을 이용해 다양한 영상처리를 가능하게 해준다.[4] 이전까지 소개 되었던 Mvtools의 경우 프레임 더블링 외에도 다양한 영상처리 필터가 내장된 범용 필터에 가깝다. 실제론 SVP팀에서 개발된 SVPflow 필터의 기능을 Mvtools에 일부 포함 시킨것이다. 참고로 Mvtools는 SVP 3.0기반이고 SVPflow는 SVP 3.1기반으로 SVPflow쪽이 더 최신 버전이다.[5] 단 GTX 10에 탑재된 가속 기능은 정확도 등에 제약이 심해 적극적으로 활용하는 측에서도 보통 GTX 16 시리즈나 RTX 20부터 지원하는 경우가 많다. 이것도 GPGPU 가속이고, 전용 하드웨어 유닛은 RTX 30부터 탑재되었고, RTX 40에서 대폭 강화되었기에 세대별로 성능 차이가 큰 편이다.[6] 유튜브, 넷플릭스 등 특정 앱에서 동영상을 60/120프레임으로 보간할 수 있다.[7] RTX 3090를 가지고도 1080p 24 fps에서 48 fps로 실시간 보간이 불가능하다.[주의] 이 프로그램은 사후 서비스가 개판이기로 유명하다. 잘 쓰고 있는데 어느 날 갑자기 라이선스에 문제가 생겼다면서 먹통이 되는 경우가 허다하다. 이렇게 라이선스가 먹통이 됐을 경우 라이선스 복구를 해주면 아무 문제가 없는데 개발자가 '그거 내 알바 아님ㅋ 니가 알아서 하셈'을 시전하면서 복구해주지 않는다. 즉, 쌩돈을 날릴 확률이 매우 높으니 구입하기 전 신중히 생각하도록 하자. 다만 아예 안 해주는 건 아니고 간혹 가다가 복구해줬다는 사례가 나온 걸 보면 개발자가 그날 기분에 따라서 복구해줄 수도 있고 안 해줄 수도 있는 듯하다. 그런 주제에 복사 방지 보안은 강력해서 2022년이 되어서야 크랙이 뚫렸는데, 당연히 불법 복제임에도 불구하고 대부분의 사람들이 꼬숩다는 반응을 보였다.[9] RX 6000번대는 가지고 있지 않기에 RX 6000번대 그래픽 카드를 기부해주면 RX 6000번대도 지원해줄 의향이 있다고 한다.[10] #, #[11] InterFrame2 필터도 결국 SVPflow를 기반으로 만들어진 필터이다. SVPflow를 그대로 실시간으로 적용할 경우 연산량이 너무 많아 오히려 재생시 버벅이게 되는 부작용이 생기기 때문에 성능을 상당히 많이 축소해서 어떻게든 실시간 재생이 가능 하도록 만든 필터가 InterFrame2이다. 그래서 프레임 더블링 효과는 SVPflow 보다 많이 떨어지므로 InterFrame2 필터는 실시간 재생용으로만 사용하고 인코딩용으론 SVPflow를 쓰기를 권장한다.[12] Intel GPU의 경우 지원은 하지만 미약한 수준이다.[13] 참고로 해당 스크립트는 멀티스레드 지원을 위한 MT필터도 함께 포함된 스크립트이기 때문에 InterFrame2필터뿐 아니라 MT필터도 따로 설치해 줘야 한다.#[14] 같은 프레임 보간이라도 원래 100 FPS 넘게 나오는 게임을 200 FPS 가깝게 보간하는 쪽은 만족하는 사례가 많지만 30 FPS 정도 나오는 게임을 60 FPS 정도 보간하면 인풋랙을 호소하는 사례가 대부분이다. 이 때문에 AMD FSR 3는 공식적으로 원본이 60 FPS 이상일 것을 권장한다.#"단순히 자사 기술을 소개하는 데 그치지 않고, 그 구현 방식과 특성에 대해서도 빼놓지 않고 소개했습니다. 프레임 레이트가 60fps 이하라면 표본으로 쓸 데이터가 부족하기에 프레임 생성 기능을 쓰는 건 권장하지 않는다네요."[15] "이미 24프레임에 익숙하고 그 특유의 느낌을 ‘영화답다’고 받아들이는" 부분 참고, 영어 원본[16] DCP 등 24프레임에만 완전히 최적화된 대다수의 극장 인프라를 싹다 갈아 엎어야하는 문제, 프레임이 2~2.5배 많으니 후편집(특히 CG)에서 비용도 그만큼 더 늘어나는 문제와 더불어 극장용 실사 영화&3D 애니메이션 업계에서 HFR과 같은 48~60FPS 이상 상용화가 지지부진한 원인 중 하나이기도 하다. 당연하지만 2D 프레임 애니메이션의 48FPS 이상 상용화는 애니메이터들이 전부 기계로 대체되기 전까진 안된다 순수 48~60FPS 이상으로 제작하려면 연출법도 갈아엎어야 할 부분이 생각보다 한두 군데가 아니며, 관객들도 다소 적응 기간이 필요하다. 제미니 맨이 HFR 120프레임으로 촬영, 상영한 후 2차 매체는 60프레임 버전으로 나온 작품인데, 유튜브 등에서 샘플 영상의 댓글을 보면 기술력에 감탄을 표하는 반응이 많은 한편 "실사 영화가 아니라 게임 그래픽 같다"며 이질감을 표하는 반응도 적지 않다.[17] 디인터레이싱 자체가 보간의 일종이기도 하다.[18] 게임으로 따지면 끊겨보이지 않도록 말 그대로 모든 프레임마다 모션 블러가 최대한으로 적용되어 있다고 보면 된다. 반대로, 슬라이드쇼 마냥 프레임들이 뚝뚝 끊겨 보일만큼 셔터 스피드가 지나치게 높은 영상은 후술할 애니메이션과 사실상 속성이 똑같기 때문에, 마찬가지로 보간이 그리 자연스럽게 되진 않는다.[19] 액션 장면 등에서 역동성을 위해 애니메이터가 직접 그려넣는 만화적인 잔상 효과와는 개념이 다르며, '현실의 카메라가 셔터 스피드로 만들어내는 잔상'을 손으로 정확히 그려내는 건 사실상 불가능하다. 컴퓨터나 AI로 따로 모션 블러 처리를 하면 모를까. "애니메이션은 그림을 한 번 카메라로 찍은 것이다"라는 지론을 가진 오시이 마모루 등으로 대표되는 통칭 '리얼계 애니메이터'들 조차도, 이만큼은 누구도 애니메이션으로 제대로 구현하지 못했다.[20] 아이러니하게도 이러한 속성 때문에 해상도 업스케일링은 오히려 애니메이션이 실사 영상보다 훨씬 자연스럽게 된다. 선과 면의 구분이 확실하기 때문이다.

파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r203
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r203 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

분류