GIF를 프레임으로 나누는 법

짧은 답

GIF 프레임 분리를 열고 GIF를 넣으면 모든 프레임이 내려받을 수 있는 PNG로 나옵니다. 한 장씩 받아도 되고, 전부를 ZIP 하나로 받아도 됩니다. 설정을 건드리지 않으면 대부분의 사람이 생각하는 그대로 나옵니다. 각 프레임이 그 순간 애니메이션에서 보이는 모습 그대로, 그림 전체로 말입니다.

이 페이지의 나머지는 그다음에 사람들을 놀라게 하는 세 가지에 대한 것입니다. 작은 조각뿐인 프레임, 다른 데서는 검게 변하는 투명, 그리고 프레임이 각각의 파일이 되는 순간 사라지는 시간 정보입니다.

GIF의 프레임이란 실제로 무엇인가

GIF는 그림을 쌓아 놓은 더미가 아닙니다. 그림 한 장과, 그 뒤로 이어지는 조각들의 행렬입니다.

첫 프레임 다음의 모든 프레임은 달라진 네모만 저장하고, 그 뒤에 캔버스를 어떻게 할지에 대한 규칙 하나를 함께 답니다. 화면의 나머지는 앞선 프레임들이 거기 남겨 둔 것일 뿐입니다. 가만히 있는 벽 앞에서 사람이 말하는 장면은 프레임마다 그림 한 장이 아니라 얼굴 크기의 네모 하나만 값으로 치릅니다. 움직임 보상도 없고 손실 단계도 없는 형식이 아예 못 쓸 물건이 되지 않은 이유는 전부 여기 있습니다.

그래서 “14번 프레임 주세요”에는 서로 다르지만 똑같이 정직한 답이 둘 있고, 이 도구는 둘 다 내놓습니다.

보이는 그대로의 프레임. 그 순간의 그림 전체, 즉 14번 프레임을 그 앞의 모든 것 위에 그린 결과입니다. 기본값이고, 목록용 시트나 섬네일, 올릴 스틸, 영상 편집기로 가져갈 프레임이라면 이쪽이 맞습니다.

그 프레임이 저장한 픽셀만. 조각 자체를 제 크기, 제 위치 그대로 두고, 담고 있지 않은 부분은 전부 투명으로 남깁니다. 14번 프레임이 ⁦60 × 40⁩ 픽셀짜리 입일 수도 있습니다. GIF의 용량이 어디로 갔는지 설명해 주는 것이 이 화면이고, 그림을 거두어 가는 게 아니라 애니메이션 자체를 손보는 중이라면 필요한 것도 이쪽입니다.

저장된 프레임이 조각처럼 보인다고 해서 파일에 문제가 있는 것은 아닙니다. 그게 바로 그 파일입니다.

처리 규칙, 그리고 어떤 프레임이 구멍을 남기는 이유

모든 프레임은 다음 프레임이 그려지기 전에 자기 네모를 어떻게 할지에 대한 네 가지 지시 중 하나를 함께 갖고 있습니다. 저장된 내용을 보는 화면에서 도구가 각 프레임 아래에 그것을 적어 줍니다.

화면에 남깁니다. 흔한 쪽입니다. 조각은 내려앉은 자리에 그대로 있고 다음 프레임이 그 위에 그립니다.

그 뒤에 자기 영역을 지웁니다. 다음 프레임이 내려앉기 전에 그 네모가 닦입니다. 투명한 물체가 움직이는 애니메이션이 이렇게 하고, 깜빡이는 GIF의 고전적인 원인이기도 합니다.

아래 있던 것을 되돌립니다. 캔버스가 이 프레임이 그리기 전 모습으로 돌아갑니다. 도장을 찍고 나서 되돌리는 셈입니다. 드물고, 손수 만든 GIF 해독기가 가장 자주 틀리는 규칙입니다.

도구를 비교할 생각이라면 알아 둘 만한 점이 하나 있습니다. 명세는 “자기 영역을 지운다”가 배경색을 되돌려야 한다고 적어 두었지만, 1990년대 이후의 모든 브라우저는 대신 투명으로 지웁니다. 그 시절 애니메이션들이 그렇게 가정하고 만들어졌기 때문입니다. 이 도구는 일부러 브라우저를 따릅니다. 당신이 받는 프레임이 당신이 본 프레임이도록 하기 위해서입니다.

투명은 어떻게 되나

GIF의 투명은 1비트입니다. 픽셀은 칠해졌거나 보이지 않거나 둘 중 하나이고, 그 사이는 없습니다. 부드러운 가장자리도, 절반쯤 드리운 그림자도 없다는 뜻입니다. 배경이 투명한 GIF의 윤곽이 딱딱하고 살짝 톱니처럼 보이는 이유가 그것입니다.

PNG는 그것을 손실 없이 그대로 저장하므로, 프레임은 투명을 온전히 지닌 채 나오고 없던 것이 지어지지도 않습니다. 프레임이 투명을 이해하는 곳으로 갈 예정이라면 그대로 두세요.

그렇지 않다면 색으로 채우세요. 알파 채널을 무시하는 소프트웨어는 보통 그 자리를 검게 그립니다. 그래서 브라우저에서는 멀쩡했던 프레임이 검은 배경을 달고 도착하고, 거의 전부가 투명한 저장 조각은 입 하나가 들어 있는 검은 네모로 도착합니다. 색을 미리 고르는 것이 해결책입니다. 그 색은 PNG에 적혀 들어가고 나중에 되돌릴 수 없는데, 이것이 기본값이 아닌 유일한 이유입니다.

프레임이 지고 갈 수 없는 시간 정보

PNG에는 자기가 화면에 얼마나 머물렀는지 적어 둘 자리가 없습니다. 애니메이션을 PNG로 쪼개면 시간 정보는 사라지고, 그것은 다시 합치려는 순간 바로 문제가 됩니다.

ZIP 안의 frames.txt가 그래서 있습니다. 프레임마다 지연 시간과 위치, 크기가 적혀 있어서 GIF 만들기에서든 다른 데서든 애니메이션을 다시 세울 수 있습니다. 몇 킬로바이트밖에 들지 않고, 나중에 되살릴 방법은 없습니다.

GIF의 지연 시간에는 누구나 걸려 넘어지는 것이 두 가지 있습니다.

단위가 100분의 1초라서, 이 형식이 가진 가장 촘촘한 눈금은 0.01 초입니다. 정확히 30 fps인 GIF 같은 것은 없습니다. 프레임당 0.03 초는 33.3 fps이고 0.04 초는 25입니다.

0.02 초 미만은 모두 0.10 초로 재생됩니다. 브라우저는 1990년대부터 그렇게 묶어 두었습니다. 그 시절 돌아가는 지구본을 위해 쓰였다가 끝내 지워지지 않은 규칙입니다. 파일에 프레임당 0.01 초라고 적힌 GIF는 100 fps를 자처하지만 10으로 재생됩니다. 이 도구는 실제로 재생되는 지연 시간을 보여 주고, 둘이 어긋날 때는 파일에 저장된 값을 옆에 적어 줍니다. 나눴다가 다시 합친 GIF가 원본보다 느리게 나올 수 있는 이유가 바로 그 간극이니까요.

프레임 번호, 그리고 앞에 0을 채우는 이유

프레임은 name-001.png, name-002.png처럼 1부터 세고 마지막 번호의 자릿수에 맞춰 0을 채운 이름으로 나옵니다. 장식이 아닙니다. frame9.png는 어떤 파일 탐색기에서도, 연속 이미지를 불러오는 대부분의 소프트웨어에서도 frame10.png 뒤에 정렬됩니다. 숫자가 아니라 글자로 정렬하기 때문입니다. 0을 채운 이름은 어디서나 제대로 정렬되고, 이미지 시퀀스를 불러오는 영상 편집기는 모두 그 형태를 전제합니다.

긴 애니메이션을 “두 프레임마다 하나 남기기”로 솎아 내도 번호를 다시 매기지는 않습니다. 42번 프레임은 그대로 42번이라, 파일들이 원본과도, 시간 목록과도 나란히 맞습니다.

이 일에 서버가 필요 없는 이유

GIF를 읽는 일은 둘입니다. 파일의 블록을 따라 걷는 일과, 픽셀을 싸고 있는 LZW 압축을 푸는 일. 둘을 합쳐 몇백 줄이고, 저장소에 그대로 적혀 있으며, 당신의 기기 위에서 돌아갑니다. 네트워크를 뽑아도 이 페이지가 계속 작동하는 이유입니다.

브라우저는 이미 GIF를 재생할 줄 알지만 부품을 건네주지는 않습니다. <img>는 애니메이션을 주고, 캔버스에 그리면 영영 첫 프레임만 나오며, 그 이상을 할 수 있는 유일한 API는 사파리에 없습니다. 그래서 여기서는 형식을 직접 읽습니다. 어느 브라우저에서나 같은 방식으로 말입니다. 그리고 직접 읽기 때문에 조각과 처리 규칙을 보여 주는 일도 가능해집니다.

온라인 변환기에 파일을 올려도 괜찮을까요? 에는 이 도구를 포함해 어떤 도구에 대해서도 같은 것을 알려 주는 확인 네 가지가 있습니다.