GIF
1. 개요
GIF는 1987년 CompuServe가 파일 다운로드를 위해 도입한 컬러 이미지 형식이다. LZW 압축 방식을 사용하여 흑백 런-렝스 인코딩 형식을 대체했으며, 1989년 애니메이션, 투명 배경색, 메타데이터 저장 기능이 추가된 89a 버전이 출시되었다. GIF는 LZW 알고리즘 특허 문제로 인해 PNG가 대체재로 개발되었으나, 2004년 특허 만료 이후에도 애니메이션 기능과 간편한 이미지 공유로 널리 사용된다. GIF는 팔레트 기반 형식으로, 최대 256색을 지원하며, 인터레이싱 기능을 통해 이미지를 부분적으로 표시할 수 있다. 애니메이션 GIF는 여러 프레임을 시간 지연과 함께 표시하며, 소셜 미디어 등에서 이미지 리플라이 게시 수단으로 널리 사용된다.
| 파일 확장자 | .gif |
|---|---|
| MIME 형식 | image/gif |
| 타입 코드 | GIFf |
| 균일 타입 | com.compuserve.gif |
| 매직 넘버 | GIF87a/GIF89a |
| 이름 | Graphics Interchange Format (그래픽 교환 형식) |
|---|---|
| 개발사 | 컴퓨서브 |
| 장르 | 무손실 압축 비트맵 이미지 포맷 |
| 발표일 | 1987년 6월 15일 |
| 최신 버전 발표일 | 1989년 |
| URL | 그래픽 교환 형식, 버전 89a |
| 발음 | /ɡɪf/ /dʒɪf/ |
|---|---|
| 관련 항목 | 발음 |
| 기타 정보 | 스ティー브 윌하이트 |
-
그래픽 파일 포맷 -
JPEG
JPEG은 정지 화상의 디지털 압축 및 코딩을 위한 국제 표준이자 이를 만든 위원회의 이름으로, 1992년 최초 표준 발표 이후 웹 환경에서 널리 사용되는 이미지 형식이 되었다. -
그래픽 파일 포맷 -
BMP 파일 포맷
BMP 파일 포맷은 마이크로소프트에서 정의한 다양한 색상 깊이를 가진 컬러 비트맵 표현 방식으로, 장치 독립 비트맵이라고도 불리며, BMP 헤더, 비트맵 정보, 색 팔레트, 비트맵 데이터 등으로 구성되어 높은 호환성을 가지지만 압축을 거의 하지 않아 파일 크기가 큰 편이다. -
오픈 포맷 -
HTML
HTML은 웹 페이지 제작을 위한 표준 마크업 언어로서, 팀 버너스리가 제안하고 구현한 후 인터넷 발전과 함께 널리 사용되며, SGML에 기반하여 하이퍼텍스트 기능으로 다양한 콘텐츠를 표현하고 연결하며, W3C와 WHATWG에서 표준화를 진행하고 최신 버전은 HTML Living Standard이다. -
오픈 포맷 -
오픈 소스
오픈 소스는 제품 설계 및 재배포를 장려하는 모델로, 소프트웨어 개발에서 시작하여 개방형 협업을 장려하며 다양한 분야에서 활용되고 있고 오픈 소스 이니셔티브와 같은 단체가 운동을 지원한다.
2. 역사
컴퓨서브는 1987년 6월 15일 파일 다운로드 영역을 위한 컬러 이미지 형식으로 GIF를 도입했다. 이는 이전에 사용하던 흑백 런-렝스 인코딩 형식을 대체한 것이다. GIF는 LZW 데이터 압축을 사용했기 때문에 인기를 얻었다. 이는 PCX와 MacPaint에서 사용된 런-렝스 인코딩보다 효율적이어서, 느린 모뎀에서도 상당히 큰 이미지를 비교적 빠르게 다운로드할 수 있었다.
GIF의 초기 버전은 87a로 불렸다. 1989년, 컴퓨서브는 89a라는 향상된 버전을 출시했다. 89a 버전에는 애니메이션 지연, 투명 배경 색상, 애플리케이션별 메타데이터 저장 등의 기능이 추가되었다. 두 버전은 파일의 처음 6바이트 ("매직 넘버" 또는 시그니처)를 보고 구별할 수 있으며, 이는 ASCII로 해석될 때 각각 "GIF87a" 또는 "GIF89a"로 읽힌다.
CompuServe는 많은 컴퓨터용 변환 유틸리티를 제공하여 GIF 채택을 장려했다. 예를 들어, 1987년 12월까지 Apple IIGS 사용자는 Atari ST 또는 Commodore 64에서 생성된 그림을 볼 수 있었다. GIF는 웹 사이트에서 일반적으로 사용된 최초의 두 가지 이미지 형식 중 하나였으며, 다른 하나는 흑백 XBM이었다.
1995년 9월, 넷스케이프 네비게이터 2.0은 애니메이션 GIF가 반복될 수 있는 기능을 추가했다.
이미지 스캔 라인을 순서대로 저장하는 선택적 인터레이싱 기능은 GIF의 인기에 도움이 되었다. 사용자는 필요하지 않은 경우 다운로드를 중단할 수 있었다.
2015년 5월 페이스북은 GIF 지원을 추가했다. 2018년 1월 인스타그램은 스토리 모드에 GIF 스티커를 추가했다.
2016년 인터넷 아카이브는 지오시티 아카이브에서 GIF의 검색 가능한 라이브러리를 출시했다.
2.1. 유니시스와 LZW 특허 문제
GIF는 1985년 유니시스가 특허를 낸 LZW 압축 알고리즘을 사용했다. 1994년 유니시스와 컴퓨서브 간의 라이선스 계약 논란은 PNG 표준 개발을 촉진했다. 유니시스는 GIF 사용에 대한 특허료를 요구하여 많은 반발을 불러일으켰다.
유니시스의 LZW 알고리즘 특허는 2003년 6월 20일에 만료되었고, 유럽, 일본, 캐나다에서의 특허는 각각 2004년 6월 18일, 6월 20일, 7월 7일에 만료되었다. 이로써 2004년에 GIF에 사용된 독점 압축과 관련된 모든 특허가 만료되었다.
2000년대 이후 인터넷 회선 속도와 PC 성능 향상으로 풀 컬러 압축 형식 (JPEG, PNG) 수요가 증가하면서 GIF 사용 빈도는 감소했다. 일본에서는 PC 통신 시대에 MAG나 Pi 형식이 주류였고, GIF는 주로 해외에서 이미지 교환 표준 포맷으로 사용되었다.
3. 파일 형식
GIF 파일은 고정 길이 헤더, 논리적 화면 설명자, 전역 색상 테이블(선택 사항), 이미지 데이터, 확장 블록, 트레일러 등으로 구성된다. 이미지 데이터는 LZW 알고리즘으로 압축된다. 확장 블록은 애니메이션 지연 시간, 투명 배경색 등을 지정하는 그래픽 제어 확장 등을 포함한다.
GIF 파일은 개념적으로 고정된 크기의 그래픽 영역("논리적 화면")을 묘사하며, 0개 이상의 "이미지"로 채워진다. 많은 GIF 파일은 전체 논리적 화면을 채우는 단일 이미지를 가지고 있다. 다른 GIF 파일은 논리적 화면을 별도의 하위 이미지로 나눈다. 이미지들은 애니메이션 GIF 파일에서 애니메이션 프레임으로 기능할 수도 있지만, 이 또한 전체 논리적 화면을 채울 필요는 없다.
GIF 파일은 버전 정보를 제공하는 고정 길이 헤더("GIF87a" 또는 "GIF89a")로 시작하며, 그 뒤에는 논리적 화면의 픽셀 치수와 기타 특성을 제공하는 고정 길이 논리적 화면 설명자가 온다. 화면 설명자는 또한 전역 색상 테이블(GCT)의 존재 여부와 크기를 지정할 수 있으며, GCT가 존재할 경우 그 다음에 온다.
그 후 파일은 다음과 같은 유형의 세그먼트로 나뉘며, 각 세그먼트는 1바이트 감시자로 시작한다.
* 이미지 (0x2C, ASCII 쉼표로 시작)
* 확장 블록 (0x21, ASCII 느낌표로 시작)
* 트레일러 (0x3B, ASCII 세미콜론 값의 단일 바이트)는 파일의 마지막 바이트여야 한다.
이미지는 고정 길이 이미지 설명자로 시작하며, 로컬 색상 테이블(존재할 경우 그 다음에 옴)의 존재 여부와 크기를 지정할 수 있다. 이미지 데이터는 인코딩되지 않은 심볼의 비트 너비를 제공하는 1바이트 (이진색 이미지의 경우에도 최소 2비트 너비여야 함)와 LZW로 인코딩된 데이터를 포함하는 일련의 하위 블록으로 구성된다.
확장 블록(87a 사양에 이미 정의된 메커니즘을 통해 87a 정의를 "확장"하는 블록)은 감시자, 확장 유형을 지정하는 추가 바이트 및 확장 데이터가 있는 일련의 하위 블록으로 구성된다. 이미지 수정 확장 블록 (선택적 애니메이션 지연 시간과 선택적 투명 배경색을 지정하는 그래픽 제어 확장 등)은 참조하는 이미지의 세그먼트 바로 앞에 있어야 한다.
각 하위 블록은 하위 블록의 후속 데이터 바이트 수를 제공하는 바이트 (1에서 255)로 시작한다. 일련의 하위 블록은 빈 하위 블록(0 바이트)으로 종료된다.
이 구조를 통해 모든 부분을 이해하지 못하더라도 파일을 구문 분석할 수 있다. 87a로 표시된 GIF는 확장 블록을 포함할 수 있는데, 이는 디코더가 이해하지 못하는 확장 기능 없이 파일을 읽고 표시할 수 있도록 하기 위함이다.
파일 형식의 전체 세부 사항은 GIF 사양에 나와 있다.
다음 표는 GIF 이미지 값의 예시를 나타낸다. 표의 16진수 숫자는 리틀 엔디언 바이트 순서이다.
| 바이트 # (16진수) | 16진수 | 텍스트 또는 값 | 의미 | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | 헤더 | |||||||
| 논리적 화면 설명자 | ||||||||||
| 6 | 03 00 | 3 | 논리적 화면 너비 | |||||||
| 8 | 05 00 | 5 | 논리적 화면 높이 | |||||||
| A | F7 | GCT는 해상도 38비트/기본 색상으로 256색을 따르며, 최하위 3비트는 비트 깊이에서 1을 뺀 값을 나타내고, 가장 높은 참 비트는 GCT가 있음을 의미 | ||||||||
| B | 00 | 0 | 배경색: 인덱스 #0; #000000 검은색 | |||||||
| C | 00 | 0 | 기본 픽셀 종횡비, 0:0 | |||||||
| 전역 색상표 | ||||||||||
| D | 00 00 00 | |||||||||
| R (빨강) | G (녹색) | B (파랑) |
|---|---|---|
| 0 | 0 | 0 |
| R (빨강) | G (녹색) | B (파랑) |
|---|---|---|
| 128 | 0 | 0 |
| R (빨강) | G (녹색) | B (파랑) |
|---|---|---|
| 255 | 255 | 255 |
'!''!'로 도입)','','로 도입, 0x2C)';'';')이미지 픽셀 데이터는 왼쪽 위에서 가로로 스캔하여 LZW 인코딩을 통해 코드로 변환되며, 이 코드는 파일에 저장하기 위해 바이트로 매핑된다. 픽셀 코드는 일반적으로 바이트의 8비트 크기와 일치하지 않으므로, 코드는 "리틀 엔디안" 방식을 사용하여 바이트로 묶는다.
이 바이트 스트림은 "서브 블록" 시리즈로 파일에 저장된다. 각 서브 블록은 최대 길이가 255바이트이며 서브 블록의 데이터 바이트 수를 나타내는 바이트가 앞에 붙는다. 서브 블록 시리즈는 빈 서브 블록(0 데이터 바이트가 있는 서브 블록을 나타내는 단일 0 바이트)으로 종료된다.
3.1. 팔레트
GIF는 팔레트 기반 형식으로, 파일 내 이미지(프레임)에 사용되는 색상은 최대 256개의 항목을 담을 수 있는 팔레트 테이블에 RGB 값으로 정의된다. 이미지 데이터는 이 팔레트 테이블의 색상(0–255)을 인덱스로 참조한다. 팔레트의 색상 정의는 수백만 가지 색상(각 기본 색상당 8비트, 224 색상)에서 가져올 수 있지만, 프레임이 사용할 수 있는 최대 색상 수는 256개이다. GIF 개발 당시에는 256개 이상의 색상을 동시에 표시할 수 있는 하드웨어가 드물었기 때문에 이 제한은 합리적이었다. 단순한 그래픽, 선 그림, 만화 및 회색조 사진은 일반적으로 256개 미만의 색상이 필요하다.
각 프레임은 하나의 인덱스를 "투명 배경색"으로 지정할 수 있다. 이 인덱스가 할당된 모든 픽셀은 배경의 동일한 위치에 있는 픽셀의 색상을 띄게 되며, 이는 이전 애니메이션 프레임에 의해 결정되었을 수 있다.
디더링은 두 개 이상의 색상 픽셀을 사용하여 중간 색상을 근사함으로써 작은 색상 팔레트로 더 넓은 범위의 색상을 표현하는 기술이다. 이러한 기술은 더 깊은 색상 해상도를 근사하기 위해 공간 해상도를 희생한다. GIF 사양의 일부는 아니지만, 디더링은 GIF 이미지로 인코딩된 이미지에 사용할 수 있다. 그러나 디더링은 공간 해상도의 손실로 인해 이미지의 화면이 흐릿해 보이고, 디더링 패턴이 이미지 데이터의 압축 가능성을 방해하여 GIF의 주요 목적에 반하는 경우가 많다.
초창기 그래픽 웹 브라우저에서는 8비트 버퍼(256색만 허용)를 가진 그래픽 카드가 일반적이었고, 웹 안전 색상을 사용하여 GIF 이미지를 만드는 것이 일반적이었다. 24비트 색상이 표준이 되면서 팔레트는 개별 이미지에 최적의 색상으로 채워질 수 있게 되었다.
작은 색상 테이블은 작은 이미지에 충분할 수 있으며, 색상 테이블을 작게 유지하면 파일을 더 빠르게 다운로드할 수 있다. 87a 및 89a 사양 모두 1에서 8까지의 모든 n에 대해 2n 개의 색상으로 구성된 색상 테이블을 허용한다. 대부분의 그래픽 응용 프로그램은 이러한 테이블 크기 중 하나로 GIF 이미지를 읽고 표시하지만, 일부는 이미지를 생성할 때 모든 크기를 지원하지 않는다. 2, 16 및 256색 테이블이 널리 지원된다.
3.2. 트루 컬러
GIF는 트루 컬러 이미지를 표현할 수 있다. GIF 이미지는 각각 자체 256색 팔레트를 가질 수 있는 여러 이미지 블록을 포함할 수 있으며, 이 블록들을 타일처럼 배열하거나 겹쳐서(레이어링) 완전한 이미지를 만들 수 있다. GIF89a 사양은 각 이미지 블록이 255개의 가시적인 색상과 하나의 투명 색상을 가질 수 있도록 "투명" 색상 개념을 도입했다. 따라서 각 레이어의 보이는 부분이 위에 있는 레이어의 투명한 부분을 통해 보이도록 이미지 블록을 겹쳐서 완전한 이미지를 만들 수 있다.
트루 컬러 이미지를 GIF로 만들기 위해서는 원본 이미지를 255개 또는 256개 이하의 서로 다른 색상을 가진 더 작은 영역으로 나누어야 한다. 그런 다음 각 영역은 자체 로컬 팔레트를 사용하여 별도의 이미지 블록으로 저장되며, 이미지 블록을 함께 표시하면(타일링 또는 부분적으로 투명한 이미지 블록을 레이어링하여) 완전한 풀 컬러 이미지가 나타난다. 예를 들어, 이미지를 16 x 16 픽셀 (총 256 픽셀) 타일로 나누면, 더 큰 타일을 사용할 수도 있지만, 타일이 로컬 팔레트 제한인 256색을 초과하지 않도록 보장할 수 있다.
하지만 각 이미지 블록은 자체 로컬 색상표를 가질 수 있기 때문에, 많은 이미지 블록을 가진 GIF 파일은 매우 커질 수 있다. 또한, 모든 GIF 렌더링 프로그램이 타일 또는 레이어 이미지를 올바르게 처리하는 것은 아니다. 많은 프로그램은 타일이나 레이어를 애니메이션 프레임으로 해석하고 0.1초 이상의 지연 시간으로 프레임을 순차적으로 표시하며, 대부분의 웹 브라우저가 자동으로 프레임을 표시한다.
3.3. 인터레이싱
GIF 명세는 GIF 파일의 논리적 화면 내 각 이미지에 대해 인터레이스 여부를 지정할 수 있도록 허용한다. 인터레이싱을 사용하면 전체 이미지가 그려지기 전에 이미지를 부분적으로 표시하여 인식할 수 있다.
인터레이스 이미지는 위에서 아래로 8픽셀 높이의 스트립으로 나뉘며, 이미지의 행은 다음 순서로 표시된다.
* 패스 1: 각 스트립의 라인 0 (가장 위쪽 라인).
* 패스 2: 각 스트립의 라인 4.
* 패스 3: 각 스트립의 라인 2 및 6.
* 패스 4: 각 스트립의 라인 1, 3, 5, 7.
각 라인 내의 픽셀은 인터레이스되지 않고 왼쪽에서 오른쪽으로 연속적으로 표시된다. 인터레이스되지 않은 이미지와 마찬가지로 한 라인의 데이터와 다음 라인의 데이터 사이에는 중단이 없다. 이미지가 인터레이스되었음을 나타내는 지표는 해당 이미지 설명자 블록에 설정된 비트이다.
4. 압축
GIF는 LZW 데이터 압축을 사용한다. 이는 PCX와 MacPaint에서 사용된 런-렝스 인코딩보다 효율적이어서, 느린 모뎀에서도 상당히 큰 이미지를 비교적 빠르게 다운로드할 수 있었다.
GIF는 256색 이하의 이미지를 다룰 수 있는 무손실 압축 형식의 파일 포맷이다. 압축 이미지 파일 포맷 중 역사가 긴 것 중 하나이며, 웹 브라우저에서는 JPEG와 함께 표준적으로 지원된다. 압축 형식의 특성상, 동일 색상이 연속되는 이미지의 압축률이 높아지기 때문에, 일러스트나 버튼 이미지 등, 사용 색상 수가 적은 이미지에 사용하기 적합하다.
GIF 파일은 LZW 압축을 통해 픽셀 데이터를 코드로 변환하여 파일 크기를 줄인다. 다음 표는 GIF 파일에 사용된 가변 길이 LZW 압축을 설명하기 위해 하나의 색을 가진 커다란 그림의 예를 나타낸다.
| 코드 | 픽셀 | 비고 | |||
|---|---|---|---|---|---|
| 번호 Ni | 값 Ni + 256 | 길이 (비트) | 이 코드 Ni | 누적 | Ni를 사용한 관계는 코딩 테이블이 가득 찰 때까지 동일한 색상의 픽셀에만 적용됨 |
| 0 | 100h | 9 | 코드 테이블 초기화 | ||
| 1 | FFh | 1 | 1 | 256색 팔레트의 가장 높은 인덱스로 선택된 왼쪽 상단 픽셀 색상 | |
| 2 | 102h | 2 | 3 | ||
| 3 ⋮ 255 | 103h ⋮ 1FFh | 3 ⋮ 255 | 6 ⋮ 32640 | 마지막 9비트 코드 | |
| 256 ⋮ 767 | 200h ⋮ 3FFh | 10 | 256 ⋮ 767 | 32896 ⋮ 294528 | 마지막 10비트 코드 |
| 768 ⋮ 1791 | 400h ⋮ 7FFh | 11 | 768 ⋮ 1791 | 295296 ⋮ 1604736 | 마지막 11비트 코드 |
| 1792 ⋮ 3839 | 800h ⋮ FFFh | 12 | 1792 ⋮ 3839 | 1606528 ⋮ 7370880 | 코드 테이블이 꽉 참 |
| ⋮ | FFFh | 3839 | 최대 코드는 동일한 색상의 픽셀에 대해 반복될 수 있음. | ||
| 101h | 이미지 데이터 종료 | ||||
이미지 픽셀 데이터는 왼쪽 위에서 가로로 스캔하여 LZW 인코딩을 통해 코드로 변환되며, 이 코드는 파일에 저장하기 위해 바이트로 매핑된다.
5. 애니메이션 GIF
GIF89a 사양은 파일의 이미지(프레임)를 시간 지연과 함께 표시하여 비디오 클립을 만들 수 있도록 그래픽 제어 확장(GCE)을 추가했다. 애니메이션 GIF의 각 프레임은 프레임을 그린 후 대기할 시간 지연을 지정하는 자체 GCE로 시작한다. 파일 시작 부분의 전역 정보는 기본적으로 모든 프레임에 적용된다. 데이터는 스트림 지향적이므로 각 GCE 시작의 파일 오프셋은 앞선 데이터의 길이에 따라 달라진다. 각 프레임 내에서 LZW 코딩된 이미지 데이터는 최대 255바이트의 하위 블록으로 배열되며, 각 하위 블록의 크기는 그 앞에 오는 바이트로 선언된다.
기본적으로 애니메이션은 마지막 프레임이 표시될 때까지 한 번만 프레임 시퀀스를 표시하고 중지한다. 애니메이션을 반복하기 위해 1990년대 넷스케이프는 응용 프로그램 확장 블록(NAB)을 구현했다. 이 블록은 애니메이션 프레임 시퀀스 바로 앞에 배치되어 프레임 시퀀스가 재생되어야 하는 횟수(1~65535회) 또는 계속 반복되어야 하는지(0은 영원히 루프를 나타냄)를 지정한다. 이러한 반복 애니메이션에 대한 지원은 처음 넷스케이프 네비게이터 버전 2.0에 나타난 다음 다른 브라우저로 확산되었다.
애니메이션 GIF를 지원하지 않는 브라우저 또는 기타 디스플레이는 일반적으로 첫 번째 프레임만 표시한다.
다음은 애니메이션 파일 Rotating earth (large).gif의 구조를 나타낸 표이다.
| 바이트 # (16진수) | | 텍스트 또는 값 || 의미 | ||
|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | 논리적 화면 설명자 |
| 6 | 90 01 | 400 | 픽셀 너비 |
| 8 | 90 01 | 400 | 픽셀 높이 |
| A | F7 | GCT는 256색에 대해 38비트/기본 해상도로 따름 | |
| B | 00 | 0 | 배경색: #000000, 검정색 |
| C | 00 | 0 | 기본 픽셀 종횡비, 0:0 |
| D | 00 | 전역 색상표 | |
| ⋮ | |||
| 30D | 21 | '!' | 확장 블록(ASCII 느낌표 '!'로 시작) |
| 30E | FF | 응용 프로그램 확장 | |
| 30F | 0B | 11 | 응용 프로그램 이름 및 확인 바이트를 포함한 블록 크기(항상 11) |
| 310 | 4E 45 54 53 43 41 50 45 32 2E 30 | NETSCAPE2.0 | 8바이트 응용 프로그램 이름 및 3바이트 확인 |
| 31B | 03 | 3 | 다음 하위 블록의 바이트 수 |
| 31C | 01 | 1 | 현재 데이터 하위 블록의 인덱스 (NETSCAPE 블록의 경우 항상 1) |
| 31D | FF FF | 65535 | 반복 부호 없는 숫자 |
| 31F | 00 | 응용 프로그램 확장 블록에 대한 하위 블록 체인의 끝 | |
| 320 | 21 | '!' | 확장 블록(ASCII 느낌표 '!'로 시작) |
| 321 | F9 | 프레임 #1에 대한 그래픽 제어 확장 | |
| 322 | 04 | 4 | 현재 하위 블록의 바이트 수(4) |
| 323 | 04 | ||
| 324 | 09 00 | 9 | 프레임 지연: 다음 프레임을 그리기 전 0.09초 지연 |
| 326 | FF | 투명 색상 인덱스 (이 프레임에서는 사용되지 않음) | |
| 327 | 00 | 그래픽 제어 확장 블록에 대한 하위 블록 체인의 끝 | |
| 328 | 2C | ',' | 이미지 설명자(16진수 0x2C, ASCII 쉼표 ','로 시작) |
| 329 | 00 00 00 00 | (0, 0) | 논리적 화면에서 이미지의 북서쪽 모서리 위치: (0, 0) |
| 32D | 90 01 90 01 | (400, 400) | 프레임 너비 및 높이: 400x400 픽셀 |
| 331 | 00 | 0 | 로컬 색상표: 0은 없음 & 인터레이싱 없음 |
| 332 | 08 | 8 | 프레임 #1의 이미지 데이터에 대한 최소 LZW 코드 크기 |
| 333 | FF | 255 | 다음 하위 블록의 LZW 이미지 데이터의 바이트 수: 255바이트 |
| 334 | ... | 이미지 데이터, 255바이트 | |
| 433 | FF | 255 | 다음 하위 블록의 LZW 이미지 데이터의 바이트 수, 255바이트 |
| 434 | ... | 이미지 데이터, 255바이트 | |
| ⋮ | 다음 블록에 대해 반복 | ||
| 92C0 | 00 | 이 프레임에 대한 하위 블록 체인의 끝 | |
| 92C1 | 21 | '!' | 확장 블록(ASCII 느낌표 '!'로 시작) |
| 92C2 | F9 | 프레임 #2에 대한 그래픽 제어 확장 | |
| ⋮ | 다음 프레임에 대해 반복 | ||
| EDABD | 21 | '!' | 확장 블록(ASCII 느낌표 '!'로 시작) |
| EDABE | F9 | 프레임 #44에 대한 그래픽 제어 확장 | |
| ⋮ | 프레임 #44에 대한 이미지 정보 및 데이터 | ||
| F48F5 | 3B | 트레일러: 파일의 마지막 바이트, EOF 신호 |
2010년대 이후에는 SNS(소셜 네트워킹 서비스) 등에서 간편한 이미지 리플라이 게시 수단으로 GIF 애니메이션이 널리 사용되면서, 'GIF'라는 단어가 애니메이션 이미지의 대명사로 정착되었다.
6. 대안
PNG는 GIF를 대체하기 위해 설계되었으며, 이는 LZW 압축 기술에 대한 유니시스의 특허 침해를 피하기 위한 것이었다. PNG는 GIF보다 더 나은 압축과 더 많은 기능을 제공하며, 유일하게 애니메이션 기능이 없다. PNG는 트루 컬러 이미지와 알파 투명도가 필요한 경우 GIF보다 더 적합하다.
PNG 형식 지원이 늦게 이루어졌지만, 새로운 웹 브라우저는 PNG를 지원한다. 이전 버전의 인터넷 익스플로러는 PNG의 모든 기능을 지원하지 않았다. 버전 6 이하에서는 마이크로소프트 특정 HTML 확장을 사용하지 않고는 알파 채널 투명도를 지원하지 않았다. PNG 이미지의 감마 보정은 버전 8 이전에는 지원되지 않았으며, 이전 버전에서 이러한 이미지를 표시하면 색상이 잘못 나타날 수 있다.
동일한 8비트(또는 그 이하) 이미지 데이터의 경우, PNG 파일은 PNG 인코딩에 사용되는 더 효율적인 압축 기술로 인해 일반적으로 해당 GIF보다 작다. GIF에 대한 완벽한 지원은 주로 허용되는 복잡한 캔버스 구조로 인해 복잡해지지만, 이는 컴팩트한 애니메이션 기능을 가능하게 한다.
GIF의 애니메이션 기능을 대체하기 위한 다양한 형식들이 제안되었지만, GIF 애니메이션이 계속 사용되었다.
* MNG("Multiple-image Network Graphics")는 원래 애니메이션을 위한 PNG 기반 솔루션으로 개발되었다. MNG는 2001년에 버전 1.0에 도달했지만, 이를 지원하는 애플리케이션은 거의 없다.
* APNG("Animated Portable Network Graphics")는 2006년에 모질라에 의해 제안되었다. APNG는 MNG 형식의 대안으로 PNG 형식의 확장이다. APNG는 2019년 현재 대부분의 브라우저에서 지원된다. APNG는 애니메이션 청크를 이해할 수 없는 디코더에서 이전 버전과의 호환성을 유지하면서 PNG 파일을 애니메이션할 수 있는 기능을 제공한다(MNG와는 다름). 이전 디코더는 단순히 애니메이션의 첫 번째 프레임을 렌더링한다.
: PNG 그룹은 2007년 4월 20일에 APNG를 공식 확장으로 공식적으로 거부했다.
: 여러 가지 다른 접근 방식을 사용하여 PNG를 기반으로 하는 간단한 애니메이션 그래픽 형식에 대한 여러 후속 제안이 있었다. 그럼에도 불구하고 APNG는 여전히 모질라에서 개발 중이며 파이어폭스 3.0에서 지원되는 반면 MNG 지원은 중단되었다. APNG는 현재 크롬(59.0 버전부터), 오페라, 파이어폭스, 엣지를 포함한 모든 주요 웹 브라우저에서 지원된다.
* 내장된 어도비 플래시 객체와 MPEG 파일은 일부 웹사이트에서 간단한 비디오를 표시하는 데 사용되었지만 추가 브라우저 플러그인을 사용해야 했다.
* WebM과 WebP는 개발 중이며 일부 웹 브라우저에서 지원된다.
* 웹 애니메이션을 위한 다른 옵션으로는 AJAX를 사용하여 개별 프레임을 제공하거나, 자바스크립트 또는 SMIL("Synchronized Multimedia Integration Language")을 사용하여 SVG("Scalable vector graphics") 이미지를 애니메이션하는 것이 있다.
* 대부분의 웹 브라우저에서 HTML 비디오 태그에 대한 광범위한 지원이 도입되면서 일부 웹사이트는 자바스크립트 함수로 생성된 비디오 태그의 반복 버전을 사용한다. 이렇게 하면 GIF와 유사하게 보이지만 압축된 비디오의 크기와 속도 이점을 누릴 수 있다.
: 주목할 만한 예로는 Gfycat 및 Imgur와 해당 GIFV 메타 형식이 있는데, 이는 실제로 반복되는 MP4 또는 WebM 압축 비디오를 재생하는 비디오 태그이다.
* HEIF("High Efficiency Image File Format")는 2015년에 완성된 이미지 파일 형식으로, HEVC 비디오 형식을 기반으로 하는 이산 코사인 변환(DCT) 손실 압축 알고리즘을 사용하며, JPEG 이미지 형식과 관련이 있다. JPEG와 달리 HEIF는 애니메이션을 지원한다.
: DCT 압축이 없는 GIF 형식과 비교하여 HEIF는 훨씬 더 효율적인 압축을 허용한다. HEIF는 더 많은 정보를 저장하고 동등한 GIF 크기의 작은 부분으로 더 높은 품질의 애니메이션 이미지를 생성한다.
* VP9은 4:2:0 색상 서브샘플링을 사용한 알파 합산만 지원하므로, 세밀한 색상 세부 정보가 있는 래스터화된 벡터 그래픽과 투명도를 결합하는 GIF에는 적합하지 않을 수 있다.
* AV1 비디오 코덱 또는 AVIF는 비디오 또는 시퀀스 이미지로 사용할 수도 있다.
7. 같이 보기
* PNG
* GIF 애니메이션