GIF 분석 — GIF 안에 실제로 무엇이 있는지

{name} 읽는 중… {name}은(는) GIF가 아닙니다: {why}. 이 도구는 GIF 형식 자체를 읽기 때문에 다른 파일에 대해서는 할 말이 없습니다. {name}을(를) 읽지 못했습니다: {why} 파일이 {available}바이트에서 끝나는데, {at} 자리에서 {wanted}바이트가 더 필요했습니다 이 파일은 “GIF”가 아니라 {what}(으)로 시작합니다 JPEG PNG RIFF 파일 — WebP나 WAV PDF zip 파일 바이트 {bytes} 코드 크기가 {size}인데, 형식이 허용하는 것은 2에서 8까지입니다 {n}프레임 {n}프레임 {n}색 {n}색 {n}개 항목 {n}개 항목 프레임별 표 {n}개 프레임별 표 {n}개 {n}번 {n}번 {n}바이트 {minutes}분 {seconds}초 {n}초 {time} ({fps} fps) {n}개 프레임이 0.02초보다 짧게 요청하지만, 모든 브라우저가 대신 0.10초 동안 붙잡아 둡니다. 한 번 — 반복 블록 없음 무한 {n}번 문제 알아 둘 것 메모 {frames}. 그중 {drawn}개를 여기에 그렸습니다. 나머지는 한꺼번에 메모리에 담기엔 너무 커서 머리말만으로 설명합니다. {frames}, 화면 전체를 덮는 것은 하나도 없습니다. {frames}, 모두 화면 전체를 덮습니다. {frames}, 그중 {n}개가 화면 전체를 덮습니다. 나머지 {frames} 보기 프레임 {n}이(가) 그 자체로 담고 있는 것 프레임 {n} 다음의 화면 프레임 {n} 그리지 않음 지연 {delay} → 0.10초 사각형 ⁦{left}, {top}⁩에 ⁦{width} × {height}⁩ 팔레트 자체 {n} 전역 팔레트 아예 없음 투명 인덱스 {n} 없음 크기 {size} — {share} 인터레이스 예 압축비 {ratio}× 문제 데이터가 일찍 끝납니다 이 파일의 표들이 모두 합쳐 {declared}을 선언하고, 픽셀이 가리키는 것은 그중 {referenced}이며, 그중 서로 다른 것이 {different}입니다. {entries}, {size}, {frames}이(가) 함께 씁니다. 흐린 항목은 어떤 픽셀도 가리키지 않는 항목입니다. {tables} (모두 {size}) 프레임 {n} — {colours} {n} 가운데 앞의 24개를 보여 줍니다. 나머지는 내려받는 보고서에 있습니다. 주석입니다. 보여 주는 뷰어는 없고, 파일의 모든 사본이 이것을 들고 다닙니다. 무한히 재생하라고 말하는 반복 블록입니다. GIF 규격의 일부가 아니라 넷스케이프가 1995년에 만들어 낸 것인데, 그래도 모두가 구현했습니다. {times} 재생하라고 말하는 반복 블록입니다. XMP 패킷입니다. 이미지 편집기가 자기가 한 일을 적어 두려고 쓰는 XML이고, 이것을 그리는 것은 없습니다. ICC 색 프로파일입니다. 팔레트의 숫자가 색으로서 무엇을 뜻하는지 말해 주지만, GIF 안에서 이것을 읽는 것은 거의 없습니다. 평문 블록입니다. 뷰어에게 그림 위에 글자를 그려 달라고 요청하는 것으로, 1989년 규격에 있었지만 어떤 것도 구현한 적이 없습니다. 응용 블록입니다. 뷰어는 알아보지 못하는 것을 건너뜁니다. 재생 길이 적힌 대로 {time} 실제 재생 {time} - 0.02초 미만인 {n}프레임은 모든 브라우저가 0.10초로 올립니다 프레임률 초당 {fps}프레임 반복 반복 블록 없음 - 한 번 재생 전역 팔레트 {n}색 없음 그려진 색 배경 인덱스 복사했습니다. 평문이고, 클립보드로만 갔습니다. 이 브라우저가 페이지의 클립보드 쓰기를 허용하지 않았습니다. 대신 “내려받기”를 쓰세요. 헤더와 화면 서술자 서명과 캔버스 크기와 플래그. 13바이트, 지금까지 만들어진 모든 GIF에 들어 있습니다. 전역 색상표 색 하나에 3바이트씩 {colours}색. 자기 색상표를 들고 오지 않는 모든 프레임이 함께 씁니다. 이 파일에는 없습니다. 프레임마다 자기 팔레트를 들고 있습니다. 프레임별 색상표 다른 색이 필요했던 프레임이 따로 가진 팔레트입니다. 매번 색 하나에 3바이트씩 듭니다. 프레임 타이밍 블록 프레임당 8바이트. 지연 시간, 정리 방식, 그리고 어느 색이 투명한지가 들어갑니다. 프레임 서술자 프레임당 11바이트. 사각형이 어디 놓이는지, 얼마나 큰지, 압축기가 어떤 코드 크기로 시작하는지가 들어갑니다. 압축된 픽셀 그림 그 자체를 LZW로 압축한 것입니다. 멀쩡한 GIF라면 이것이 파일의 거의 전부입니다. 블록 테두리 데이터 255바이트마다 길이 바이트 하나, 그리고 각 묶음을 끝내는 0 하나. 피할 수 없고, 볼 만한 값입니다. 주석과 메타데이터 반복 블록, 주석, 색 프로파일, 그리고 편집기가 남기고 간 XMP 같은 것들입니다. 종료 표시 파일이 끝났다고 말하는 1바이트입니다. 끝난 뒤의 바이트 종료 표시 뒤에 놓인 데이터입니다. 어떤 디코더도 읽지 않고, 순전히 무게일 뿐입니다. 셈에 들어가지 않은 것 이 리더가 멈춰 선 블록 안의 바이트입니다. 블록 도중에 끝나는 파일은 이런 바이트를 남깁니다. 두 번 센 것 블록이 겹칩니다. 이 파일이 블록의 시작 위치를 두고 스스로 어긋난다는 뜻입니다. 지정되지 않음 그대로 두기 배경으로 되돌리기 아래에 있던 것 되살리기 예약됨 ({n}) 정리 방식 GIF 분석 — {name} abox.tools/gif-analyzer/ 가 브라우저 안에서만 읽었습니다. 파일은 업로드되지 않았습니다. 파일 버전 캔버스 ⁦{width} x {height}⁩ 픽셀 크기 {rounded} ({exact}) 프레임 바이트가 어디로 갔는지 합계 눈에 띄는 것 프레임 목록 파일이 담고 있는 텍스트 전역 팔레트 자체 {colours}색 전역 캔버스 전체 번호 위치 크기 지연 정리 팔레트 바이트 파일이 종료 바이트 없이 끝나 불완전합니다 — 일찍 끊긴 내려받기이거나 중간에서 잘린 파일입니다. {at}번 바이트가 0x{marker}인데, 이 형식의 어떤 블록도 그렇게 시작하지 않습니다. 그 뒤는 모두 무시했습니다. 그래픽 제어 블록이 {first}과 {second}에 연달아 두 개 있습니다. 첫 번째는 어떤 이미지도 설명하지 않고 아무 일도 하지 않습니다. {at}에서 시작하는 블록의 한가운데에서 파일이 끝납니다. {detail}. 사전에 아직 아무것도 없는데 코드 {code}이 먼저 나왔습니다. 뷰어는 할 수 있는 만큼 그리고 사각형의 나머지는 비워 둡니다. 코드 {code}이 사전 항목 {code}번을 가리키는데, 항목은 {entries}개뿐입니다. 뷰어는 할 수 있는 만큼 그리고 사각형의 나머지는 비워 둡니다. 이 파일에는 프레임이 없습니다. 헤더는 읽혔지만 뒤이어 이미지 블록이 오지 않았습니다. 이것이 무엇이든 어떤 뷰어도 여기서 아무것도 그리지 못합니다. 파일이 깔끔하게 끝나지 않습니다. 파일이 끝난 뒤에 {bytes}가 남아 있습니다. 모든 디코더는 종료 바이트에서 멈추므로 이 부분은 읽히지도 그려지지도 않습니다. 대개 첫 파일 뒤에 두 번째 파일이 이어 붙었거나, 프로그램이 제 끝을 넘어 쓴 경우입니다. 종료 바이트에서 파일을 잘라도 잃는 것은 없습니다. 한 프레임이 0.02초보다 짧게 머물기를 요구하지만, 그렇게 해 주는 브라우저는 없습니다. {count}개 프레임이 0.02초보다 짧게 머물기를 요구하지만, 그렇게 해 주는 브라우저는 없습니다. 넷스케이프 이후 모든 브라우저는 100분의 2초 미만의 지연을 10으로 올림합니다 — 1996년에 그 시절 회전하는 지구본을 위해 쓰인 뒤 한 번도 없어지지 않은 규칙입니다. 그래서 이 애니메이션은 {nominal}이라고 말하면서 실제로는 {real} 동안 재생되어 약 {factor}배 느립니다. 0.01 대신 0.02로 적으면 원하던 속도가 나옵니다. 모든 프레임의 지연이 0입니다. 파일이 시간을 전혀 지정하지 않아 재생 속도는 전적으로 뷰어에 달려 있습니다 — 보통 초당 열 프레임이지만 보장하는 것은 없습니다. 두 브라우저가 서로 다른 속도로 재생해도 둘 다 옳습니다. 프레임 간격이 고르지 않습니다: {shortest}부터 {longest}까지 {delays}가지 지연이 섞여 있습니다. 마지막 프레임을 길게 잡아 두는 것은 의도적이고 흔합니다. 중간에 지연이 흩어져 있다면 대개 변환기가 영상에서 프레임을 버리고 그 빈자리를 메우려고 이웃 프레임을 늘린 것입니다. 반복 블록이 없어서 한 번 재생하고 멈춥니다. 반복은 GIF 규격에 없습니다. 1995년 넷스케이프가 만들었는데도 모두가 구현한 블록이고, 그것이 없는 파일은 어느 브라우저에서든 정확히 한 번만 보입니다. 반복할 생각이었다면 이 파일을 쓴 쪽이 블록을 빠뜨린 것입니다. 이 파일은 한 번 재생하고 멈춥니다. 이 파일은 {count}번 재생하고 멈춥니다. 반복 블록이 보통의 0 대신 횟수를 적어 두었습니다. 0은 무한을 뜻합니다. 오래된 뷰어 중에는 횟수를 무시하고 계속 반복하는 것도 있습니다. 모든 프레임이 캔버스 전체를 다시 그립니다. GIF는 프레임을 직전과 달라진 사각형만으로 저장할 수 있고, 거의 멈춰 있는 창을 녹화한 파일이 작을 수 있는 이유가 그것입니다. 여기서는 어느 프레임도 그러지 않습니다. 모든 프레임이 ⁦{width}×{height}⁩ 캔버스 전체입니다. 서로 관계 없는 그림들로 만든 프레임이라면 맞는 방식이고, 촬영하거나 녹화한 것 — 즉 화면 대부분이 움직이지 않는 것 — 이라면 그냥 버리는 용량입니다. {total}개 중 한 프레임이 캔버스 전체를 다시 그리고, 나머지는 달라진 부분만 저장합니다. {total}개 중 {count}개 프레임이 캔버스 전체를 다시 그리고, 나머지는 달라진 부분만 저장합니다. 잘 최적화된 GIF가 이렇게 생겼습니다. 캔버스 전체를 그리는 것은 보통 첫 프레임과 그림이 통째로 바뀐 지점들입니다. 캔버스 전체를 다시 그리는 프레임이 없습니다. 첫 프레임 이후는 모두 달라진 사각형만 저장합니다. 형식을 제대로 쓴 것이고, 이 파일이 이만큼 작은 이유입니다. 한 프레임이 캔버스 밖으로 나갑니다. {count}개 프레임이 캔버스 밖으로 나갑니다. 캔버스는 ⁦{width}×{height}⁩인데 한 프레임이 가장자리를 넘어가는 사각형을 주장합니다. 디코더들은 넘친 부분을 어떻게 할지 의견이 다릅니다. 잘라내는 쪽도 있고 파일을 거부하는 쪽도 있습니다. 캔버스는 ⁦{width}×{height}⁩인데 일부 프레임이 가장자리를 넘어가는 사각형을 주장합니다. 디코더들은 넘친 부분을 어떻게 할지 의견이 다릅니다. 잘라내는 쪽도 있고 파일을 거부하는 쪽도 있습니다. 한 프레임이 자기 색상표를 지니고 있어 {bytes}가 듭니다 — 파일의 {share}입니다. {count}개 프레임이 저마다 색상표를 지니고 있어 {bytes}가 듭니다 — 파일의 {share}입니다. 자기 팔레트가 있으면 공용 색상표에 없는 색을 쓸 수 있지만, 쓸 때마다 항목당 3바이트가 듭니다. 프레임들이 같은 장면이라면 전부를 위한 색상표 하나가 더 작고 보기에도 안정적입니다. 프레임마다 팔레트가 출렁이는 것, 그것이 바로 GIF 깜빡임입니다. 전역 색상표가 없습니다. 잘못된 것은 없습니다 — 여기서는 프레임마다 자기 것을 가져옵니다 — 다만 첫 프레임이 도착하기 전에는 뷰어가 캔버스를 칠할 것이 없다는 뜻입니다. 색상표 항목 {entries}개가 전혀 쓰이지 않으며, 그것이 {bytes}입니다. 이 파일의 색상표는 {declared}색을 선언하는데 픽셀은 그중 {referenced}색만 가리킵니다. 색상표 길이는 내용과 무관하게 항상 2의 거듭제곱이라, 아홉 색을 쓰는 프레임도 열여섯 자리를 받습니다. 어느 정도의 올림은 피할 수 없습니다. 그보다 훨씬 많다면 팔레트가 결국 프레임에 담긴 그림이 아니라 다른 그림을 위해 만들어진 것입니다. 애니메이션 전체가 한 가지 색으로 그려집니다. 애니메이션 전체가 {count}가지 색으로 그려집니다. 평면적인 그림이고, GIF가 원래 그런 것을 위해 만들어졌습니다. 이런 파일은 잘 압축되고 디더링은 잘 받지 않으니, 얼룩덜룩해 보인다면 꺼야 할 것은 디더링입니다. 사진이거나 사진에서 나온 것입니다. GIF는 한 프레임에 최대 256색만 주므로 그라데이션이 있는 것은 모두 근사치로 표현됩니다 — 디더링과, 파일을 크게 만드는 잡음이 거기서 나옵니다. 이 파일에는 {bytes}짜리 주석 블록이 있습니다. 주석은 어떤 뷰어도 보여 주지 않으면서 파일의 모든 사본이 지니고 다닙니다. 보통 파일을 쓴 프로그램 이름이고, 가끔은 작성자가 공개하려 하지 않았을 것도 들어 있습니다. XMP 메타데이터 패킷이 {bytes}를 차지합니다 — 파일의 {share}입니다. XMP는 이미지 편집기가 자기가 한 일을 기록하려고 쓰는 XML 블록이고, 편집 이력과 소프트웨어, 때로는 작성자까지 담을 수 있습니다. 어떤 뷰어도 그것을 그리지 않습니다. 지워도 그림이 잃는 것은 없습니다. ICC 색 프로파일이 {bytes}를 차지합니다. 프로파일은 팔레트의 숫자가 색으로서 무엇을 뜻하는지 알려 줍니다. GIF 안의 것을 읽는 프로그램은 거의 없으니 대개는 값 없는 무게입니다 — 다만 읽는 뷰어에서는 지웠을 때 색이 달라질 수 있습니다. 이 파일에는 일반 텍스트 확장이 있습니다. 뷰어에게 그림 위에 칸 격자로 글자를 그려 달라고 요청하는 블록입니다. 1989년 규격에 있었고, 어디에서도 구현된 적이 없으며, 모든 디코더가 건너뜁니다. 무엇이 적혀 있든 화면에는 나오지 않습니다. “{name}”이라는 이름의 애플리케이션 블록이 있고, 크기는 {bytes}입니다. 애플리케이션 블록은 규격 밖의 것이 GIF 안으로 들어오는 통로입니다. 뷰어는 모르는 블록을 건너뛰므로, 특정한 무언가가 읽고 있지 않다면 이것은 무게일 뿐입니다. 한 프레임이 인터레이스로 저장되어 있습니다. {count}개 프레임이 인터레이스로 저장되어 있습니다. 느린 회선으로 들어오는 그림이 일찍부터 거친 형태나마 보이도록 행을 네 번에 나누어 저장한 것입니다. 1993년에는 말이 되었고, 행을 순서대로 저장하는 것보다 압축이 조금 나쁘며, 오늘날 이득을 보는 뷰어는 없습니다. 이 파일은 GIF89a가 아니라 GIF{version}이라고 말합니다. GIF87a가 먼저 나왔고 타이밍 블록도, 투명도도, 반복 블록도 없습니다. 그중 무엇인가를 담고 있으면서 87a라고 주장하는 파일은 흔합니다 — 디코더가 확인하지 않으니까요 — 다만 헤더를 직접 쓴 게 아니라 복사했다는 표시입니다. 배경색이 {index}번인데 전역 색상표에는 항목이 {entries}개뿐입니다. 무엇이 깨지지는 않습니다 — 뷰어가 대신 투명을 씁니다 — 다만 그 칸이 한 번도 설정되지 않았거나, 지금 파일에 든 것과 다른 팔레트를 기준으로 설정되었다는 뜻입니다. 픽셀 종횡비가 {ratio}(으)로 설정되어 있습니다. 픽셀이 정사각형이 아니던 화면을 위한 칸입니다. 요즘 뷰어는 모두 무시하고 저장된 크기 그대로 그리므로, 여기에 기대는 파일은 만든 사람에게만 늘어나 보이고 다른 모두에게는 정상으로 보입니다. 압축기가 사전을 {count}번 초기화했습니다. LZW는 진행하면서 사전을 만들고 4,096개 항목까지 담습니다. 가득 차면 인코더가 처음부터 다시 시작합니다. 프레임당 한 번은 정상입니다 — 프레임은 그렇게 시작합니다. 그보다 많다면 그림이 사전을 도중에 소진할 만큼 변화가 많았다는 뜻이고, 사진이나 강한 디더링이 그런 일을 합니다. 그런 파일이 큰 이유입니다. 한 프레임이 바로 앞 프레임과 완전히 같습니다. {count}개 프레임이 바로 앞 프레임과 완전히 같습니다. 압축된 크기를 고스란히 쓰면서 화면에서는 아무것도 바꾸지 않습니다. 대신 그 지연을 앞 프레임에 더하면 보기에는 똑같으면서 크기는 더 작습니다. 한 프레임이 끝까지 디코딩되지 않습니다. {count}개 프레임이 끝까지 디코딩되지 않습니다. 프레임이 다 차기 전에 압축 데이터가 끝납니다. 뷰어는 할 수 있는 만큼 그리고 사각형의 나머지는 비워 둡니다. GIF는 어디로도 가지 않았습니다. 파일 {total}개를 불러왔습니다. {platform} 무언가가 {hosts}에 접속했는데, 이 도구는 절대 그러지 않습니다. {platform} 광고와 측정과 후원 버튼을 위한 이 사이트 자신의 스크립트가 호스트 {hosts}곳에서 왔습니다. 그중 어느 쪽도 파일을 받지 않았습니다. 광고와 측정과 후원 버튼을 위한 이 사이트 자신의 스크립트가 호스트 {hosts}곳에서 왔습니다. 그중 어느 쪽도 파일을 받지 않았습니다.