GIF
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
GIF는 1987년 CompuServe가 파일 다운로드를 위해 도입한 컬러 이미지 형식이다. LZW 압축 방식을 사용하여 흑백 런-렝스 인코딩 형식을 대체했으며, 1989년 애니메이션, 투명 배경색, 메타데이터 저장 기능이 추가된 89a 버전이 출시되었다. GIF는 LZW 알고리즘 특허 문제로 인해 PNG가 대체재로 개발되었으나, 2004년 특허 만료 이후에도 애니메이션 기능과 간편한 이미지 공유로 널리 사용된다. GIF는 팔레트 기반 형식으로, 최대 256색을 지원하며, 인터레이싱 기능을 통해 이미지를 부분적으로 표시할 수 있다. 애니메이션 GIF는 여러 프레임을 시간 지연과 함께 표시하며, 소셜 미디어 등에서 이미지 리플라이 게시 수단으로 널리 사용된다.
더 읽어볼만한 페이지
- 그래픽 파일 포맷 - JPEG
JPEG은 정지 화상의 디지털 압축 및 코딩을 위한 국제 표준이자 이를 만든 위원회의 이름으로, 1992년 최초 표준 발표 이후 웹 환경에서 널리 사용되는 이미지 형식이 되었다. - 그래픽 파일 포맷 - BMP 파일 포맷
BMP 파일 포맷은 마이크로소프트에서 정의한 다양한 색상 깊이를 가진 컬러 비트맵 표현 방식으로, 장치 독립 비트맵이라고도 불리며, BMP 헤더, 비트맵 정보, 색 팔레트, 비트맵 데이터 등으로 구성되어 높은 호환성을 가지지만 압축을 거의 하지 않아 파일 크기가 큰 편이다. - 오픈 포맷 - HTML
HTML은 웹 페이지 제작을 위한 표준 마크업 언어로서, 팀 버너스리가 제안하고 구현한 후 인터넷 발전과 함께 널리 사용되며, SGML에 기반하여 하이퍼텍스트 기능으로 다양한 콘텐츠를 표현하고 연결하며, W3C와 WHATWG에서 표준화를 진행하고 최신 버전은 HTML Living Standard이다. - 오픈 포맷 - 오픈 소스
오픈 소스는 제품 설계 및 재배포를 장려하는 모델로, 소프트웨어 개발에서 시작하여 개방형 협업을 장려하며 다양한 분야에서 활용되고 있고 오픈 소스 이니셔티브와 같은 단체가 운동을 지원한다.
| GIF - [IT 관련 정보]에 관한 문서 | |
|---|---|
| 파일 정보 | |
 | |
| 파일 확장자 | .gif |
| MIME 형식 | image/gif |
| 타입 코드 | GIFf |
| 균일 타입 | com.compuserve.gif |
| 매직 넘버 | GIF87a/GIF89a |
| 일반 정보 | |
| 이름 | Graphics Interchange Format (그래픽 교환 형식) |
| 개발사 | 컴퓨서브 |
| 장르 | 무손실 압축 비트맵 이미지 포맷 |
| 발표일 | 1987년 6월 15일 |
| 최신 버전 발표일 | 1989년 |
| URL | 그래픽 교환 형식, 버전 89a |
| 기타 | |
| 발음 | /ɡɪf/ /dʒɪf/ |
| 관련 항목 | 발음 |
| 기타 정보 | 스ティー브 윌하이트 |
2. 역사
컴퓨서브는 1987년 6월 15일 파일 다운로드 영역을 위한 컬러 이미지 형식으로 GIF를 도입했다. 이는 이전에 사용하던 흑백 런-렝스 인코딩 형식을 대체한 것이다. GIF는 LZW 데이터 압축을 사용했기 때문에 인기를 얻었다. 이는 PCX와 MacPaint에서 사용된 런-렝스 인코딩보다 효율적이어서, 느린 모뎀에서도 상당히 큰 이미지를 비교적 빠르게 다운로드할 수 있었다.
GIF의 초기 버전은 87a로 불렸다.[1] 1989년, 컴퓨서브는 89a라는 향상된 버전을 출시했다.[2] 89a 버전에는 애니메이션 지연, 투명 배경 색상, 애플리케이션별 메타데이터 저장 등의 기능이 추가되었다. 두 버전은 파일의 처음 6바이트 ("매직 넘버" 또는 시그니처)를 보고 구별할 수 있으며, 이는 ASCII로 해석될 때 각각 "GIF87a" 또는 "GIF89a"로 읽힌다.
CompuServe는 많은 컴퓨터용 변환 유틸리티를 제공하여 GIF 채택을 장려했다. 예를 들어, 1987년 12월까지 Apple IIGS 사용자는 Atari ST 또는 Commodore 64에서 생성된 그림을 볼 수 있었다.[4] GIF는 웹 사이트에서 일반적으로 사용된 최초의 두 가지 이미지 형식 중 하나였으며, 다른 하나는 흑백 XBM이었다.[5]
1995년 9월, 넷스케이프 네비게이터 2.0은 애니메이션 GIF가 반복될 수 있는 기능을 추가했다.
이미지 스캔 라인을 순서대로 저장하는 선택적 인터레이싱 기능은 GIF의 인기에 도움이 되었다.[6] 사용자는 필요하지 않은 경우 다운로드를 중단할 수 있었다.
2015년 5월 페이스북은 GIF 지원을 추가했다.[7][8] 2018년 1월 인스타그램은 스토리 모드에 GIF 스티커를 추가했다.[9]
2016년 인터넷 아카이브는 지오시티 아카이브에서 GIF의 검색 가능한 라이브러리를 출시했다.[10][11]
2. 1. 유니시스와 LZW 특허 문제
GIF는 1985년 유니시스가 특허를 낸 LZW 압축 알고리즘을 사용했다.[89] 1994년 유니시스와 컴퓨서브 간의 라이선스 계약 논란은 PNG 표준 개발을 촉진했다.[43][49] 유니시스는 GIF 사용에 대한 특허료를 요구하여 많은 반발을 불러일으켰다.유니시스의 LZW 알고리즘 특허는 2003년 6월 20일에 만료되었고, 유럽, 일본, 캐나다에서의 특허는 각각 2004년 6월 18일, 6월 20일, 7월 7일에 만료되었다.[89] 이로써 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 사양에 나와 있다.[2]
다음 표는 GIF 이미지 값의 예시를 나타낸다. 표의 16진수 숫자는 리틀 엔디언 바이트 순서이다.
{| class="wikitable"
|+ GIF 이미지 값의 예시 테이블
! 바이트 # (16진수) !! 16진수 !! 텍스트 또는 값 !! colspan=2 | 의미
|-
| 0 || 47 49 46 38 39 61 || GIF89a || colspan=2 | 헤더
|-
! colspan=5 | 논리적 화면 설명자
|-
| 6 || 03 00 || 3 || colspan=2 | 논리적 화면 너비
|-
| 8 || 05 00 || 5 || colspan=2 | 논리적 화면 높이
|-
| A || F7 || || colspan=2 | GCT는 해상도 38비트/기본 색상으로 256색을 따르며, 최하위 3비트는 비트 깊이에서 1을 뺀 값을 나타내고, 가장 높은 참 비트는 GCT가 있음을 의미
|-
| B || 00 || 0 || colspan=2 | 배경색: 인덱스 #0; #000000 검은색
|-
| C || 00 || 0 || colspan=2 | 기본 픽셀 종횡비, 0:0
|-
! colspan=5 | 전역 색상표
|-
| D || 00 00 00 ||
| R (빨강) | G (녹색) | B (파랑) |
|---|---|---|
| 0 | 0 | 0 |
|| 전역 색상표, 색상 #0: #000000, 검은색 || rowspan=4 width=220px | 
|-
| 10 || 80 00 00 ||
| R (빨강) | G (녹색) | B (파랑) |
|---|---|---|
| 128 | 0 | 0 |
|| 전역 색상표, 색상 #1: 투명 비트, 이미지에 사용되지 않음
|-
| ... || ... || ... || 전역 색상표는 30A까지 확장
|-
| 30A || FF FF FF ||
| R (빨강) | G (녹색) | B (파랑) |
|---|---|---|
| 255 | 255 | 255 |
|| 전역 색상표, 색상 #255: #ffffff, 흰색
|-
! colspan=5 | 그래픽 제어 확장
|-
| 30D || 21 || '!' || colspan=2 | 확장 블록(ASCII 느낌표 '!'로 도입)
|-
| 30E || F9 || || colspan=2 | 그래픽 제어 확장
|-
| 30F || 04 || 4 || colspan=2 | GCE 데이터 양, 4 바이트
|-
| 310 || 01 || || colspan=2 | 투명 배경색; 이것은 비트 필드이며, 최하위 비트는 투명도를 나타냄
|-
| 311 || 00 00 || || colspan=2 | 1/100초 단위의 애니메이션 지연; '''사용되지 않음'''
|-
| 313 || 10 || 16 || colspan=2 | GCT의 투명 픽셀의 색상 번호
|-
| 314 || 00 || || colspan=2 | GCE 블록 종료
|-
! colspan=5 | 이미지 설명자
|-
| 315 || 2C || ','|| colspan=2 | 이미지 설명자(ASCII 쉼표 ','로 도입, 0x2C)
|-
| 316 || 00 00 00 00 || (0, 0) || colspan=2 | 논리적 화면에서 이미지의 북서쪽 모서리 위치
|-
| 31A || 03 00 05 00 || (3, 5) || colspan=2 | 픽셀 단위의 이미지 너비 및 높이
|-
| 31E || 00 || 0 || colspan=2 | 로컬 색상표 비트, 0은 없음 의미
|-
! colspan=5 | 이미지 데이터
|-
| 31F || 08 || 8 || colspan=2 | 이미지 시작, LZW 최소 코드 크기
|-
| 320 || 0B || 11 || colspan=2 | 처음 데이터 하위 블록 시작, 11 바이트의 인코딩된 데이터를 지정
|-
| 321 || 00 51 FC 1B 28 70 A0 C1 83 01 01 || || colspan=2 | 11 바이트의 이미지 데이터, 필드 320 참조
|-
| 32C || 00 || 0 || colspan=2 | 종료 데이터 하위 블록, 후속 데이터 바이트 없음(및 이미지 종료)을 지정
|-
! colspan=5 | 트레일러
|-
| 32D || 3B || ';' || colspan=2 | 파일 종료 블록 표시기(ASCII 세미콜론 ';')
|}
이미지 픽셀 데이터는 왼쪽 위에서 가로로 스캔하여 LZW 인코딩을 통해 코드로 변환되며, 이 코드는 파일에 저장하기 위해 바이트로 매핑된다. 픽셀 코드는 일반적으로 바이트의 8비트 크기와 일치하지 않으므로, 코드는 "리틀 엔디안" 방식을 사용하여 바이트로 묶는다.
이 바이트 스트림은 "서브 블록" 시리즈로 파일에 저장된다. 각 서브 블록은 최대 길이가 255바이트이며 서브 블록의 데이터 바이트 수를 나타내는 바이트가 앞에 붙는다. 서브 블록 시리즈는 빈 서브 블록(0 데이터 바이트가 있는 서브 블록을 나타내는 단일 0 바이트)으로 종료된다.
3. 1. 팔레트
GIF는 팔레트 기반 형식으로, 파일 내 이미지(프레임)에 사용되는 색상은 최대 256개의 항목을 담을 수 있는 팔레트 테이블에 RGB 값으로 정의된다.[2] 이미지 데이터는 이 팔레트 테이블의 색상(0–255)을 인덱스로 참조한다. 팔레트의 색상 정의는 수백만 가지 색상(각 기본 색상당 8비트, 224 색상)에서 가져올 수 있지만, 프레임이 사용할 수 있는 최대 색상 수는 256개이다.[2] GIF 개발 당시에는 256개 이상의 색상을 동시에 표시할 수 있는 하드웨어가 드물었기 때문에 이 제한은 합리적이었다. 단순한 그래픽, 선 그림, 만화 및 회색조 사진은 일반적으로 256개 미만의 색상이 필요하다.각 프레임은 하나의 인덱스를 "투명 배경색"으로 지정할 수 있다.[2] 이 인덱스가 할당된 모든 픽셀은 배경의 동일한 위치에 있는 픽셀의 색상을 띄게 되며, 이는 이전 애니메이션 프레임에 의해 결정되었을 수 있다.
디더링은 두 개 이상의 색상 픽셀을 사용하여 중간 색상을 근사함으로써 작은 색상 팔레트로 더 넓은 범위의 색상을 표현하는 기술이다.[2] 이러한 기술은 더 깊은 색상 해상도를 근사하기 위해 공간 해상도를 희생한다. GIF 사양의 일부는 아니지만, 디더링은 GIF 이미지로 인코딩된 이미지에 사용할 수 있다. 그러나 디더링은 공간 해상도의 손실로 인해 이미지의 화면이 흐릿해 보이고, 디더링 패턴이 이미지 데이터의 압축 가능성을 방해하여 GIF의 주요 목적에 반하는 경우가 많다.
초창기 그래픽 웹 브라우저에서는 8비트 버퍼(256색만 허용)를 가진 그래픽 카드가 일반적이었고, 웹 안전 색상을 사용하여 GIF 이미지를 만드는 것이 일반적이었다. 24비트 색상이 표준이 되면서 팔레트는 개별 이미지에 최적의 색상으로 채워질 수 있게 되었다.
작은 색상 테이블은 작은 이미지에 충분할 수 있으며, 색상 테이블을 작게 유지하면 파일을 더 빠르게 다운로드할 수 있다.[2] 87a 및 89a 사양 모두 1에서 8까지의 모든 ''n''에 대해 2''n'' 개의 색상으로 구성된 색상 테이블을 허용한다. 대부분의 그래픽 응용 프로그램은 이러한 테이블 크기 중 하나로 GIF 이미지를 읽고 표시하지만, 일부는 이미지를 ''생성''할 때 모든 크기를 지원하지 않는다. 2, 16 및 256색 테이블이 널리 지원된다.
3. 2. 트루 컬러
GIF는 트루 컬러 이미지를 표현할 수 있다.[35][36] GIF 이미지는 각각 자체 256색 팔레트를 가질 수 있는 여러 이미지 블록을 포함할 수 있으며, 이 블록들을 타일처럼 배열하거나 겹쳐서(레이어링) 완전한 이미지를 만들 수 있다. GIF89a 사양은 각 이미지 블록이 255개의 가시적인 색상과 하나의 투명 색상을 가질 수 있도록 "투명" 색상 개념을 도입했다. 따라서 각 레이어의 보이는 부분이 위에 있는 레이어의 투명한 부분을 통해 보이도록 이미지 블록을 겹쳐서 완전한 이미지를 만들 수 있다.[35]
트루 컬러 이미지를 GIF로 만들기 위해서는 원본 이미지를 255개 또는 256개 이하의 서로 다른 색상을 가진 더 작은 영역으로 나누어야 한다. 그런 다음 각 영역은 자체 로컬 팔레트를 사용하여 별도의 이미지 블록으로 저장되며, 이미지 블록을 함께 표시하면(타일링 또는 부분적으로 투명한 이미지 블록을 레이어링하여) 완전한 풀 컬러 이미지가 나타난다. 예를 들어, 이미지를 16 x 16 픽셀 (총 256 픽셀) 타일로 나누면, 더 큰 타일을 사용할 수도 있지만, 타일이 로컬 팔레트 제한인 256색을 초과하지 않도록 보장할 수 있다.[35]
하지만 각 이미지 블록은 자체 로컬 색상표를 가질 수 있기 때문에, 많은 이미지 블록을 가진 GIF 파일은 매우 커질 수 있다.[36] 또한, 모든 GIF 렌더링 프로그램이 타일 또는 레이어 이미지를 올바르게 처리하는 것은 아니다. 많은 프로그램은 타일이나 레이어를 애니메이션 프레임으로 해석하고 0.1초 이상의 지연 시간으로 프레임을 순차적으로 표시하며, 대부분의 웹 브라우저가 자동으로 프레임을 표시한다.[37][38]
3. 3. 인터레이싱
GIF 명세는 GIF 파일의 논리적 화면 내 각 이미지에 대해 인터레이스 여부를 지정할 수 있도록 허용한다. 인터레이싱을 사용하면 전체 이미지가 그려지기 전에 이미지를 부분적으로 표시하여 인식할 수 있다.[6]인터레이스 이미지는 위에서 아래로 8픽셀 높이의 스트립으로 나뉘며, 이미지의 행은 다음 순서로 표시된다.
- 패스 1: 각 스트립의 라인 0 (가장 위쪽 라인).
- 패스 2: 각 스트립의 라인 4.
- 패스 3: 각 스트립의 라인 2 및 6.
- 패스 4: 각 스트립의 라인 1, 3, 5, 7.
각 라인 내의 픽셀은 인터레이스되지 않고 왼쪽에서 오른쪽으로 연속적으로 표시된다. 인터레이스되지 않은 이미지와 마찬가지로 한 라인의 데이터와 다음 라인의 데이터 사이에는 중단이 없다. 이미지가 인터레이스되었음을 나타내는 지표는 해당 이미지 설명자 블록에 설정된 비트이다.
4. 압축
Ni
Ni + 256
(비트)
Ni
⋮
255
⋮
1FFh
⋮
255
⋮
32640
⋮
767
⋮
3FFh
⋮
767
⋮
294528
⋮
1791
⋮
7FFh
⋮
1791
⋮
1604736
⋮
3839
⋮
FFFh
⋮
3839
⋮
7370880