너비·FPS·색상 수를 조절하고 프레임을 순차 처리합니다.
영상의 구간, 폭(320·480·640 px 또는 원본), 프레임레이트(10·15·24fps)를 고르고, 원하면 속도·반복·역재생·자르기 비율·맞출 용량까지 정하면 Nerulio가 그 프레임을 디코딩해 GIF를 만듭니다. GIF는 프레임당 최대 256색이고 프레임마다 머무는 시간을 100분의 1초 단위로 저장하므로, 용량과 부드러움은 서로 맞바꾸는 관계입니다. 폭 × 높이 × 프레임 수가 용량을 정합니다. 기본값은 480 px·15fps이고, 프레임마다 팔레트를 따로 만들며 디더링은 선택입니다.
Nerulio는 무엇보다 2D 게임 에셋 스튜디오입니다. 도트를 그리고, 스프라이트 시트를 애니메이션으로 자르고, 텍스처 아틀라스를 패킹하고, 오토타일 타일셋을 점검해 Godot·Unity·Phaser 등 엔진용으로 내보냅니다. 브라우저에서 동작하며 파일은 기기 밖으로 나가지 않습니다.
게임 스튜디오 열기 →게임 도구 전체GIF를 스프라이트 시트로스프라이트 애니메이션 미리보기스프라이트 시트 패커
GIF 프레임은 팔레트 번호의 격자로, LZW 압축 전에는 픽셀당 1바이트이고 색상표는 최대 256색입니다. GIF89a 규격은 이미지마다 로컬 색상표를 허용합니다. Nerulio는 각 프레임의 색으로 그 프레임만의 팔레트를 만들기 때문에, 장면이 바뀌어도 앞 장면과 색을 나눠 쓸 필요가 없습니다.
영상에는 256색보다 훨씬 많은 색이 있어서 하늘·피부·그림자 같은 부드러운 그라데이션은 띠처럼 끊어집니다. 디더링 50 %나 100 %는 플로이드-스타인버그 확산으로 반올림 오차를 퍼뜨려 띠를 고운 입자로 바꿉니다. 입자는 LZW 압축에는 잡음이라 디더링한 GIF는 더 큽니다. 색을 줄이면(128·64·32) 파일은 작아지고 띠는 심해집니다.
GIF에는 소리도, 영상 코덱 같은 움직임 압축도 없어서 모든 프레임의 모든 픽셀만큼 커집니다. 머무는 시간은 1/100초 단위라 15fps(66.7ms)는 정확히 저장할 수 없고, Nerulio는 70ms와 60ms를 번갈아 써서 평균을 맞춥니다. 속도는 머무는 시간이 아니라 뽑아낼 순간을 바꿉니다. 2배속이면 부드러움은 같고 GIF 길이가 절반입니다.
GIF의 기본 구간은 처음 6초입니다.
프레임 크기 480 × 270 px = 129,600 픽셀
프레임 수 6 s × 15 fps = 90 프레임
지연 70, 60, 70, 70, 60, 70 … ms (3프레임 = 200 ms)
번호 데이터 129,600 × 90 = LZW 압축 전 1,170만 바이트
24 fps라면 144 프레임, 지연 40, 40, 50 … ms, 번호 데이터 1,870만 바이트
640 px라면 640 × 360 × 90 = 번호 데이터 2,070만 바이트이후 LZW가 번호 데이터를 줄이는 정도는 그림에 따라 달라서, 예상 용량은 추측하지 않고 실제 클립의 프레임 3장을 인코딩해 계산합니다. 2배속이면 같은 6초가 45프레임, 3초짜리 GIF가 됩니다.
| 설정 | 선택지 | 용량 영향 |
|---|---|---|
| 폭 | 320·480·640 px 또는 원본 | 프레임당 픽셀은 폭의 제곱으로 늘어남 |
| 프레임레이트 | 10·15·24 fps | 프레임 수가 비례해 늘어남 |
| 색상 수(고급) | 256·128·64·32 | 색이 적을수록 잘 압축되지만 띠가 늘어남 |
| 디더링(고급) | 끔·50 %·100 % | 그라데이션이 부드러워지고 파일이 커짐 |
| 속도 | 0.5배·1배·2배 | 2배면 프레임 수와 길이가 절반 |
| 자르기 | 없음·1:1·4:5·16:9, 가운데 기준 | 프레임당 픽셀이 줄어듦 |
| 목표 용량(MB) | 임의의 값 | 크기를 재며 최대 네 번 인코딩 |
| 증상 | 유력한 원인 | 확인 방법 | 해결 |
|---|---|---|---|
| 하늘과 피부에 띠가 생김 | 부드러운 그라데이션에 프레임당 256색이 부족함 | 프레임에서 가장 넓은 그라데이션을 보기 | 디더링을 50 %나 100 %로 켜고 256색 유지 |
| GIF가 너무 큼 | 폭과 프레임 수가 곱해짐. 640 px·24fps는 480 px·15fps의 2.8배 픽셀 | 실행 전 예상 용량 비교 | 폭이나 fps를 낮추거나 구간을 줄이거나 자르기, 또는 목표 용량 입력 |
| 목표 용량은 맞췄는데 설정보다 품질이 나빠 보임 | 맞추려고 먼저 색을 64(다음은 32)로, 그다음 폭과 fps를 함께 줄임 | 결과 상자에 최종 폭과 프레임 수가 나옴 | 목표를 키우거나 대신 구간을 줄이기 |
| 긴 클립이 느리거나, 역재생이 메모리 메시지로 멈춤 | 모든 프레임을 디코딩·양자화·압축하며, 역재생은 끝날 때까지 모든 프레임을 들고 있음(번호 데이터 64 MB 상한) | 진행 표시에 전체 중 몇 번째 프레임인지 나옴 | 구간이나 폭·fps를 줄이고, 긴 클립은 역재생 끄기 |
| 휴대폰 영상에서 디코더 오류가 남 | 브라우저가 영상 코덱(주로 HEVC)을 디코딩하지 못함 | 코덱 확인법은 MOV 안내 참고 | 디코딩되는 브라우저를 쓰거나 H.264로 촬영 |
| 방법 | 이럴 때 더 낫습니다 |
|---|---|
palettegen·paletteuse 필터를 쓴 FFmpeg | 클립 전체에 최적화한 팔레트 하나와 다섯 가지 디더링(기본 Sierra-2-4A)을 스크립트로. 명령줄 전용입니다. |
| GIF 대신 짧은 MP4·WebM | 플랫폼이 영상을 받는다면 같은 화질에 훨씬 작고 소리도 있습니다. 영상 압축 참고. |
| 스프라이트 시트를 GIF로 | 촬영한 영상이 아니라 도트 애니메이션 프레임일 때. |
tests/media-browser.mjs로 Chromium 153과 Firefox 155에서 확인했습니다. 2초를 640 px·12fps로 만들면 폭 640 px의 24프레임이 나오고, 0.25 MB 목표는 측정 인코딩으로 달성했으며, 역재생·2배속·1:1 자르기 GIF는 계획한 5프레임과 정사각형 크기를 지켰고, 프레임 3장 예상치는 실제 용량과 25 % 이내였습니다. 프레임은 Mediabunny 1.58.1과 WebCodecs로 디코딩하고 gifenc 1.0.3으로 인코딩합니다. GIF의 한계는 GIF89a 규격에 따른 것입니다.
너비·FPS·색상 수를 조절하고 프레임을 순차 처리합니다.
MP4 / WebM / MOV → GIF — 입력·출력 지원은 브라우저에 따라 다릅니다.
프레임을 하나씩 읽고 GIF 너비·FPS·색상 수·디더링을 선택합니다.
advanced · WebCodecs sequential frames / gifenc adaptive palettes / measured size targets. 품질 검증을 진행 중입니다. Pro·Flagship 수준은 아직 입증되지 않았습니다.
빠른 자르기는 범위 안쪽 키프레임으로 줄어듭니다. 정밀 모드는 재인코딩하며 코덱 지원은 다릅니다. 가능하면 결과를 기기 내 임시 저장소에 씁니다. 호환 녹화 모드의 짧은 구간 제한은 유지됩니다.
기기 메모리·저장 공간·코덱 지원에 따라 달라집니다. 테스트한 사례가 모든 파일의 성공을 보장하지는 않습니다.
이 도구에서 연 파일은 서버에 업로드하지 않고 사용자 기기에서 처리합니다. 커뮤니티 글에 직접 첨부하는 이미지는 별도로 업로드됩니다. 일부 엔진과 모델은 외부에서 내려받으므로 IP 주소 등 연결 정보가 해당 서비스에 전달됩니다.
아니요. 이미지와 편집 상태는 이 탭에 있고 미디어 결과는 기기 내 임시 저장소를 사용할 수 있습니다. 언어를 바꿔도 작업은 유지되지만 새로고침, 탭 닫기, 다른 페이지로 이동하면 사라질 수 있습니다.