GIF
.gif?lang=ko) | |
| 파일 확장자 | .gif |
|---|---|
| 인터넷 미디어 타입 |
image/gif |
| 개발 | 컴퓨서브 |
| 포맷 종류 | 래스터 이미지 |
그래픽스 인터체인지 포맷(영어: Graphics Interchange Format, GIF)은 미국의 컴퓨터 과학자 스티브 윌하이트가 이끄는 온라인 서비스 제공업체 컴퓨서브의 팀이 개발하여 1987년 6월 15일에 출시한 비트맵 이미지 형식이다.[1]
이 형식은 픽셀당 8비트까지 포함할 수 있어 단일 이미지가 24비트 RGB 색 공간에서 선택된 최대 256가지의 다른 색상 팔레트를 참조할 수 있다. 또한 파일에 여러 이미지를 나타낼 수 있으며, 이는 애니메이션에 사용될 수 있고, 각 프레임에 최대 256가지 색상의 별도 팔레트를 허용한다. 이러한 팔레트 제한 때문에 GIF는 컬러 사진 및 기타 색상 그레이디언트가 있는 이미지를 재현하는 데는 덜 적합하지만, 단색 영역이 있는 그래픽이나 로고와 같은 간단한 이미지에는 매우 적합하다.
GIF 이미지는 렘펠-지브-웰치(LZW) 비손실 데이터 압축 기술을 사용하여 시각적 품질을 저하시키지 않으면서 파일 크기를 줄인다.
월드 와이드 웹에서 광범위하게 구현되고 응용 프로그램 및 운영 체제 간에 이식성이 뛰어나 한때 널리 사용되었지만, 공간 및 품질 문제로 인해 사용이 줄어들었으며, 종종 정적 이미지에는 PNG, 비디오에는 MP4와 같은 최신 형식으로 대체되고 있다. 이러한 맥락에서 짧은 비디오 클립은 원래 파일 형식과는 무관함에도 불구하고 때때로 "GIF"라고 불린다.[2]
역사
[편집]
컴퓨서브는 파일 다운로드 영역에 컬러 이미지 형식을 제공하기 위해 1987년 6월 15일 GIF를 도입했다. 이는 흑백 전용이었던 기존의 런 길이 인코딩 형식을 대체했다. GIF는 렘펠-지브-웰치 데이터 압축을 사용했기 때문에 인기를 얻었다. 이는 PCX 및 MacPaint에 사용된 런 길이 인코딩보다 효율적이었기 때문에 느린 모뎀으로도 상당히 큰 이미지를 합리적으로 빠르게 다운로드할 수 있었다.
GIF의 원본 버전은 87a라고 불렸다.[1] 이 버전은 이미 스트림에서 여러 이미지를 지원했다.
1989년, 컴퓨서브는 89a라고 불리는 향상된 버전을 출시했다.[3] 이 버전은 다음을 추가했다:
- 애니메이션 지연 지원
- 투명 배경색
- 응용 프로그램별 메타데이터 저장
- 텍스트 레이블을 텍스트로 허용(그래픽 데이터에 포함하지 않음). 그러나 이 기능은 거의 사용되지 않는다. 최신 브라우저는 이를 지원하지 않으며 글꼴 및 스타일링에 대한 제어가 거의 없다.
두 버전은 파일의 처음 6 바이트( "매직 넘버" 또는 서명)를 보면 구별할 수 있는데, ASCII로 해석하면 각각 "GIF87a" 또는 "GIF89a"로 읽힌다.
컴퓨서브는 많은 컴퓨터에 대한 다운로드 가능한 변환 유틸리티를 제공함으로써 GIF의 채택을 장려했다. 예를 들어, 1987년 12월까지 애플 IIGS 사용자는 아타리 ST 또는 코모도르 64에서 생성된 그림을 볼 수 있었다.[4] GIF는 웹사이트에서 일반적으로 사용되는 처음 두 가지 이미지 형식 중 하나였으며, 다른 하나는 흑백 XBM이었다.[5]
1995년 9월 넷스케이프 내비게이터 2.0은 애니메이션 GIF를 반복하는 기능을 추가했다.
GIF는 컴퓨서브에 의해 개발되었지만, 유니시스가 1985년에 특허를 낸 렘펠-지브-웰치(LZW) 비손실 데이터 압축 알고리즘을 사용했다. 1994년 유니시스와 컴퓨서브 간의 라이선스 계약을 둘러싼 논란은 포터블 네트워크 그래픽스 (PNG) 표준 개발을 촉발시켰다. 2004년에 GIF에 사용된 독점 압축과 관련된 모든 특허가 만료되었다.
제어 데이터와 함께 한 파일에 여러 이미지를 저장하는 기능은 간단한 컴퓨터 애니메이션을 생성하기 위해 웹에서 광범위하게 사용된다.
선택적 인터레이싱 기능은 이미지 스캔 라인을 순서대로 저장하여 부분적으로 다운로드된 이미지도 어느 정도 인식할 수 있도록 하는 방식으로 GIF의 인기에 기여했다.[6] 사용자가 원하지 않는 경우 다운로드를 중단할 수 있었기 때문이다.
2015년 5월 페이스북은 GIF 지원을 추가했다.[7][8] 2014년에는 트위터도 GIF를 지원했으며, 2018년에는 인스타그램도 마찬가지였다.[9]
2016년, 인터넷 아카이브는 Geocities 아카이브에서 검색 가능한 GIF 라이브러리를 공개했다.[10][11]
용어
[편집]명사로서 GIF라는 단어는 많은 사전의 최신판에서 찾아볼 수 있다. 2012년, 옥스퍼드 대학교 출판부의 미국 지부는 GIF를 "GIF 파일을 생성하다"라는 의미의 동사로도 인정했는데, 예를 들어 "GIFing은 하계 올림픽 장면을 공유하는 데 완벽한 매체였다"와 같이 사용된다. 출판사의 사전 편집자들은 GIF를 "연구와 저널리즘을 포함한 심각한 응용 프로그램을 위한 도구"로 진화했다고 말하며 올해의 단어로 선정했다.[12][13]
발음
[편집]
이 부분의 본문은 GIF의 발음입니다.
GIF의 첫 글자 발음은 1990년대부터 논란이 되어왔다. 영어에서 가장 흔한 발음은 
i/dʒɪf/ (gin처럼 부드러운 g)와 i/ɡɪf/ (gift처럼 센 g)로, 문자 G가 나타내는 음소가 다르다. 형식의 개발자들은 GIF를 /dʒɪf/로 발음했는데, 부드러운 g로 발음했다. 윌하이트는 발음이 미국 땅콩버터 브랜드 Jif를 의도적으로 반영하기를 원했으며, 컴퓨서브 직원들은 종종 Jif의 텔레비전 광고를 패러디하여 "까다로운 개발자는 GIF를 선택한다"고 농담을 하곤 했다.[14] 그러나 이 단어는 /ɡɪf/로 널리 발음되는데, 센 g로 발음되며,[15] 여론 조사는 일반적으로 이러한 센 g 발음이 더 우세하다는 것을 보여준다.[16][17]
Dictionary.com[18]은 두 발음 모두를 인용하며, /dʒɪf/를 주된 발음으로 나타내고, 반면 Cambridge Dictionary of American English[19]는 센 g 발음만을 제공한다. 메리엄-웹스터 대학 사전[20]과 Oxford Dictionaries는 두 발음 모두를 인용하지만, 센 g를 먼저 배치한다: /ɡɪf,
발음 논쟁은 인터넷에서 뜨거운 논쟁으로 이어졌다. 2013년 웹비 어워드 시상식에서 평생 공로상을 받은 자리에서 윌하이트는 센 g 발음을 공개적으로 거부했다.[15][27][28] 그의 연설은 트위터에 17,000개 이상의 게시물과 수십 개의 뉴스 기사를 불러왔다.[29] 백악관[15]과 TV 프로그램 제퍼디!도 2013년에 이 논쟁에 참여했다.[28] 2020년 2월, Jif 브랜드 소유주인 The J.M. Smucker Company는 애니메이션 이미지 데이터베이스 및 검색 엔진인 Giphy와 협력하여 한정판 "Jif vs. GIF" (해시태그 #JIFvsGIF) 땅콩 버터 병을 출시했다. 이 병의 라벨에는 부드러운 g 발음은 땅콩 버터에만 해당되고, GIF는 센 g 발음으로만 발음되어야 한다는 유머러스한 내용이 적혀 있었다.[30]
사용법
[편집]GIF는 로고와 같이 색상 수가 제한된 선명한 가장자리를 가진 선화에 적합하다. 이는 형식이 잘 정의된 가장자리를 가진 단색의 평평한 영역을 선호하는 비손실 압축의 이점을 활용한다.[31] 또한 게임을 위한 저해상도 스프라이트 데이터를 저장하는 데도 사용될 수 있다.[32] GIF는 작은 애니메이션과 저해상도 비디오 클립에 사용될 수 있으며, 온라인 메시징에서 단어 대신 감정을 전달하기 위한 반응으로도 사용된다. 텀블러,[33] 페이스북, 트위터와 같은 소셜 미디어 플랫폼에서 인기가 많다.[34]
파일 형식
[편집]개념적으로, GIF 파일은 고정된 크기의 그래픽 영역("논리적 화면")을 설명하며, 이 영역에는 0개 이상의 "이미지"가 채워져 있다. 많은 GIF 파일은 전체 논리적 화면을 채우는 단일 이미지를 가지고 있다. 다른 파일들은 논리적 화면을 별도의 하위 이미지로 나눈다. 이미지는 애니메이션 GIF 파일에서 애니메이션 프레임으로도 작동할 수 있지만, 이 역시 전체 논리적 화면을 채울 필요는 없다.
GIF 파일은 버전을 나타내는 고정 길이 헤더("GIF87a" 또는 "GIF89a")로 시작하며, 이어서 논리적 화면의 픽셀 크기 및 기타 특성을 나타내는 고정 길이 논리적 화면 디스크립터가 온다. 화면 디스크립터는 또한 전역 색상 테이블(GCT)의 존재 여부와 크기를 지정할 수 있으며, 존재하는 경우 그 다음에 온다.
그 후 파일은 1바이트의 센티넬로 시작하는 다음과 같은 유형의 세그먼트로 나뉜다:
- 이미지 (0x2C, ASCII 쉼표
','로 시작) - 확장 블록 (0x21, ASCII 느낌표
'!'로 시작) - 트레일러 (0x3B 값의 단일 바이트, ASCII 세미콜론
';'), 이는 파일의 마지막 바이트여야 한다.
이미지는 고정 길이 이미지 디스크립터로 시작하며, 이는 로컬 색상 테이블(존재하는 경우 그 다음에 옴)의 존재 여부와 크기를 지정할 수 있다. 이미지 데이터가 그 뒤를 따른다: 인코딩되지 않은 심볼의 비트 너비를 나타내는 1바이트(이진 이미지의 경우에도 최소 2비트 너비여야 함), 그 다음 LZW로 인코딩된 데이터를 포함하는 일련의 서브 블록.
확장 블록(87a 사양에 이미 정의된 메커니즘을 통해 87a 정의를 "확장"하는 블록)은 센티넬, 확장 유형을 지정하는 추가 바이트, 그리고 확장 데이터를 포함하는 일련의 서브 블록으로 구성된다. 이미지를 수정하는 확장 블록(예: 선택적 애니메이션 지연 시간 및 선택적 투명 배경색을 지정하는 그래픽 제어 확장)은 해당 이미지가 있는 세그먼트 바로 앞에 와야 한다.
각 서브 블록은 서브 블록의 다음 데이터 바이트 수(1에서 255)를 나타내는 바이트로 시작한다. 서브 블록의 시리즈는 빈 서브 블록(0 바이트)으로 종료된다.
이러한 구조는 모든 부분이 이해되지 않더라도 파일을 구문 분석할 수 있도록 한다. 87a로 표시된 GIF는 확장 블록을 포함할 수 있다. 의도는 디코더가 이해하지 못하는 확장 기능 없이 파일을 읽고 표시할 수 있도록 하는 것이다.
파일 형식의 전체 세부 사항은 GIF 사양에 설명되어 있다.[3]
팔레트
[편집]
GIF는 팔레트 기반이다: 파일 내 이미지(프레임)에 사용된 색상은 최대 256개 항목을 담을 수 있는 팔레트 테이블에 RGB 값이 정의되어 있으며, 이미지 데이터는 팔레트 테이블의 인덱스(0–255)로 색상을 참조한다. 팔레트의 색상 정의는 수백만 색조(각 주색당 8비트, 224 색조)의 색상 공간에서 가져올 수 있지만, 프레임이 사용할 수 있는 최대 색상 수는 256개이다. 이 제한은 GIF가 개발될 당시 256개 이상의 색상을 동시에 표시할 수 있는 하드웨어가 드물었기 때문에 합리적이었다. 단순한 그래픽, 선 그림, 만화, 회색조 사진은 일반적으로 256개 미만의 색상이 필요하다.
각 프레임은 하나의 인덱스를 "투명 배경색"으로 지정할 수 있다: 이 인덱스에 할당된 모든 픽셀은 배경의 동일한 위치에 있는 픽셀의 색상을 취하며, 이는 이전 애니메이션 프레임에 의해 결정되었을 수 있다.
디더링이라고 총칭되는 많은 기술들이 두 가지 이상의 색상 픽셀을 사용하여 중간 색상을 근사화함으로써 작은 색상 팔레트로 더 넓은 범위의 색상을 근사화하기 위해 개발되었다. 이러한 기술들은 더 깊은 색상 해상도를 근사화하기 위해 공간 해상도를 희생한다. GIF 사양의 일부는 아니지만, 디더링은 나중에 GIF 이미지로 인코딩된 이미지에 사용될 수 있다. 이는 일반적으로 GIF 이미지에 이상적인 해결책이 아닌데, 공간 해상도의 손실이 일반적으로 화면에서 이미지를 흐릿하게 보이게 하고, 디더링 패턴이 이미지 데이터의 압축성에 방해가 되어 GIF의 주요 목적에 반하기 때문이다.
초창기 그래픽 웹 브라우저에서는 8비트 버퍼(256가지 색상만 허용)를 가진 그래픽 카드가 흔했으며, 웹 안전 팔레트를 사용하여 GIF 이미지를 만드는 것이 매우 흔했다. 이는 예측 가능한 디스플레이를 보장했지만, 색상 선택을 심각하게 제한했다. 24비트 색상이 표준이 되면서 팔레트는 개별 이미지에 최적의 색상으로 채워질 수 있었다.
작은 이미지에는 작은 색상 테이블로도 충분하며, 색상 테이블을 작게 유지하면 파일을 더 빠르게 다운로드할 수 있다. 87a 및 89a 사양 모두 n이 1에서 8까지인 모든 2n 색상의 색상 테이블을 허용한다. 대부분의 그래픽 응용 프로그램은 이러한 테이블 크기를 가진 GIF 이미지를 읽고 표시하지만, 이미지를 생성할 때는 모든 크기를 지원하지 않는 경우도 있다. 2, 16, 256 색상 테이블은 널리 지원된다.
트루컬러
[편집]GIF는 트루컬러 이미지에 거의 사용되지 않지만, 그렇게 하는 것이 가능하다.[35][36] GIF 이미지에는 여러 이미지 블록이 포함될 수 있으며, 각 블록은 자체 256색 팔레트를 가질 수 있고, 이 블록들을 타일링하여 완전한 이미지를 만들 수 있다. 또는 GIF89a 사양은 "투명" 색상의 개념을 도입하여 각 이미지 블록이 자체 255개의 보이는 색상 팔레트와 하나의 투명 색상을 포함할 수 있도록 했다. 완전한 이미지는 이미지 블록을 겹쳐서 만들 수 있으며, 각 레이어의 보이는 부분이 위 레이어의 투명 부분을 통해 표시된다.
풀 컬러 이미지를 GIF로 렌더링하려면 원본 이미지를 255개 또는 256개 이하의 다른 색상을 가진 작은 영역으로 분할해야 한다. 그런 다음 각 영역은 자체 로컬 팔레트가 있는 별도의 이미지 블록으로 저장되며, 이미지 블록이 함께 표시될 때(타일링 또는 부분적으로 투명한 이미지 블록을 겹침으로써) 완전한 풀 컬러 이미지가 나타난다. 예를 들어, 이미지를 16x16픽셀(총 256픽셀) 타일로 분할하면 어떤 타일도 로컬 팔레트 제한인 256색 이상을 가지지 않도록 보장하지만, 더 큰 타일을 사용할 수 있고 유사한 색상이 병합되어 일부 색상 정보가 손실될 수 있다.[35]
각 이미지 블록은 자체 로컬 색상 테이블을 가질 수 있으므로, 많은 이미지 블록을 가진 GIF 파일은 매우 커질 수 있어 풀 컬러 GIF의 유용성을 제한한다.[36] 또한, 모든 GIF 렌더링 프로그램이 타일링되거나 레이어링된 이미지를 올바르게 처리하는 것은 아니다. 많은 렌더링 프로그램은 타일 또는 레이어를 애니메이션 프레임으로 해석하고 애니메이션으로 순서대로 표시하며[35] 대부분의 웹 브라우저는 프레임을 0.1초 이상의 지연 시간으로 자동으로 표시한다.[37][38][더 나은 출처 필요]
GIF 파일 예시
[편집]| 마이크로소프트 그림판은 작은 흑백 이미지를 다음 GIF 파일로 저장한다(확대하여 설명). 그림판은 GIF를 최적으로 사용하지 않는다; 불필요하게 큰 색상 테이블(사용된 2색 대신 전체 256색 저장)과 심볼 너비 때문에 이 GIF 파일은 15픽셀 이미지의 효율적인 표현이 아니다. 그래픽 제어 확장 블록은 색상 인덱스 16(16진수 10)을 투명하다고 선언하지만, 이 인덱스는 이미지에서 사용되지 않는다. 이미지 데이터에 나타나는 유일한 색상 인덱스는 십진수 40과 255이며, 이는 전역 색상 테이블에서 각각 검정색과 흰색에 매핑된다. |
 샘플 이미지 (확대), 실제 크기 가로 3픽셀, 세로 5픽셀 |
다음 표의 16진수는 형식 사양에 따라 리틀 엔디언 바이트 순서이다.
| 바이트 # (16진수) | 16진수 | 텍스트 또는 값 | 의미 | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | 헤더 | |||||||
| 논리적 화면 디스크립터 | ||||||||||
| 6 | 03 00 | 3 | 논리적 화면 너비 | |||||||
| 8 | 05 00 | 5 | 논리적 화면 높이 | |||||||
| A | F7 | GCT는 해상도 3 × 8비트/기본색에 대해 256색을 따르며, 가장 낮은 3비트는 비트 깊이에서 1을 뺀 값을 나타내고, 가장 높은 참 비트는 GCT가 존재함을 의미한다 | ||||||||
| B | 00 | 0 | 배경색: 인덱스 #0; #000000 검정 | |||||||
| C | 00 | 0 | 기본 픽셀 가로세로 비율, 0:0 | |||||||
| 전역 색상 테이블 | ||||||||||
| D | 00 00 00 |
|
전역 색상 테이블, 색상 #0: #000000, 검정 |  | ||||||
| 10 | 80 00 00 |
|
전역 색상 테이블, 색상 #1: 투명 비트, 이미지에서 사용되지 않음 | |||||||
| ... | ... | ... | 전역 색상 테이블은 30A까지 확장된다 | |||||||
| 30A | FF FF FF |
|
전역 색상 테이블, 색상 #255: #ffffff, 흰색 | |||||||
| 그래픽 제어 확장 | ||||||||||
| 30D | 21 | '!' |
확장 블록 (ASCII 느낌표 '!'로 시작)
| |||||||
| 30E | F9 | 그래픽 제어 확장 | ||||||||
| 30F | 04 | 4 | GCE 데이터 양, 4바이트 | |||||||
| 310 | 01 | 투명 배경색; 이는 비트 필드이며, 가장 낮은 비트가 투명도를 나타낸다 | ||||||||
| 311 | 00 00 | 애니메이션 지연 (1/100초 단위); 사용되지 않음 | ||||||||
| 313 | 10 | 16 | GCT 내 투명 픽셀의 색상 번호 | |||||||
| 314 | 00 | GCE 블록의 끝 | ||||||||
| 이미지 디스크립터 | ||||||||||
| 315 | 2C | ',' |
이미지 디스크립터 (0x2C, ASCII 쉼표 ','로 시작)
| |||||||
| 316 | 00 00 00 00 | (0, 0) | 논리적 화면 내 이미지의 북서쪽 코너 위치 | |||||||
| 31A | 03 00 05 00 | (3, 5) | 픽셀 단위 이미지 너비 및 높이 | |||||||
| 31E | 00 | 0 | 로컬 색상 테이블 비트, 0은 없음 | |||||||
| 이미지 데이터 | ||||||||||
| 31F | 08 | 8 | 이미지 시작, LZW 최소 코드 크기 | |||||||
| 320 | 0B | 11 | 첫 번째 데이터 하위 블록의 시작, 11바이트의 인코딩된 데이터가 뒤따름을 지정 | |||||||
| 321 | 00 51 FC 1B 28 70 A0 C1 83 01 01 | <이미지 데이터> | 11바이트의 이미지 데이터, 필드 320 참조 | |||||||
| 32C | 00 | 0 | 데이터 하위 블록 종료, 뒤따르는 데이터 바이트 없음 (및 이미지 종료) | |||||||
| 트레일러 | ||||||||||
| 32D | 3B | ';' |
파일 종료 블록 표시기 (ASCII 세미콜론 ';')
| |||||||
이미지 코딩
[편집]왼쪽 상단에서 수평으로 스캔된 이미지 픽셀 데이터는 LZW 인코딩에 의해 코드로 변환된 후 파일에 저장하기 위해 바이트로 매핑된다. 픽셀 코드는 일반적으로 바이트의 8비트 크기와 일치하지 않으므로, 코드는 "리틀 엔디언" 방식에 의해 바이트로 압축된다: 첫 번째 코드의 최하위 비트는 첫 번째 바이트의 최하위 비트에 저장되고, 코드의 상위 비트는 바이트의 상위 비트에 저장되며, 필요한 경우 다음 바이트의 최하위 비트로 넘어간다. 각 후속 코드는 아직 사용되지 않은 최하위 비트에서 시작하여 저장된다.
이 바이트 스트림은 파일에 일련의 "서브 블록"으로 저장된다. 각 서브 블록은 최대 길이 255바이트를 가지며, 서브 블록의 데이터 바이트 수를 나타내는 바이트가 앞에 붙는다. 서브 블록의 시리즈는 빈 서브 블록(단일 0 바이트, 0 데이터 바이트를 가진 서브 블록을 나타냄)으로 종료된다.
위 샘플 이미지의 경우 9비트 코드와 바이트 간의 가역 매핑은 다음과 같다.
| 9비트 코드 | 바이트 | ||
|---|---|---|---|
| 16진수 | 이진수 | 이진수 | 16진수 |
| 100 | 1 00000000 | 00000000 | 00 |
| 028 | 00 0101000 | 0101000 1 | 51 |
| 0FF | 011 111111 | 111111 00 | FC |
| 103 | 1000 00011 | 00011 011 | 1B |
| 102 | 10000 0010 | 0010 1000 | 28 |
| 103 | 100000 011 | 011 10000 | 70 |
| 106 | 1000001 10 | 10 100000 | A0 |
| 107 | 10000011 1 | 1 1000001 | C1 |
| 10000011 | 83 | ||
| 101 | 1 00000001 | 00000001 | 01 |
| 0000000 1 | 01 | ||
약간의 압축이 분명하다: 처음 15바이트로 정의된 픽셀 색상이 제어 코드를 포함하여 12바이트의 코드로 정확하게 표현된다. 9비트 코드를 생성하는 인코딩 프로세스는 아래와 같다. 로컬 문자열은 팔레트에서 픽셀 색상 번호를 누적하며, 로컬 문자열이 코드 테이블에서 발견되는 한 출력 동작은 없다. 테이블이 초기 크기에서 문자열 추가로 커지기 전에 도착하는 처음 두 픽셀은 특별히 처리된다. 각 출력 코드 후에 로컬 문자열은 최신 픽셀 색상(출력 코드에 포함될 수 없었던)으로 초기화된다.
Table 9-bit
string --> code code Action
#0 | 000h Initialize root table of 9-bit codes
palette | :
colors | :
#255 | 0FFh
clr | 100h
end | 101h
| 100h Clear
Pixel Local |
color Palette string |
BLACK #40 28 | 028h 1st pixel always to output
WHITE #255 FF | String found in table
28 FF | 102h Always add 1st string to table
FF | Initialize local string
WHITE #255 FF FF | String not found in table
| 0FFh - output code for previous string
FF FF | 103h - add latest string to table
FF | - initialize local string
WHITE #255 FF FF | String found in table
BLACK #40 FF FF 28 | String not found in table
| 103h - output code for previous string
FF FF 28 | 104h - add latest string to table
28 | - initialize local string
WHITE #255 28 FF | String found in table
WHITE #255 28 FF FF | String not found in table
| 102h - output code for previous string
28 FF FF | 105h - add latest string to table
FF | - initialize local string
WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF | String not found in table
| 103h - output code for previous string
FF FF FF | 106h - add latest string to table
FF | - initialize local string
WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF | String found in table
WHITE #255 FF FF FF FF | String not found in table
| 106h - output code for previous string
FF FF FF FF| 107h - add latest string to table
FF | - initialize local string
WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF | String found in table
WHITE #255 FF FF FF FF | String found in table
No more pixels
107h - output code for last string
101h End
명확성을 위해 위 표는 길이가 증가하는 문자열로 구성된 것으로 나타난다. 이 방식은 작동할 수 있지만 테이블이 예측할 수 없는 양의 메모리를 소비한다. 실제로 각 새로운 문자열이 이전에 저장된 문자열에 하나의 문자가 추가된 형태로 구성된다는 점에 주목하여 메모리를 절약할 수 있다. 각 주소에 기존 주소와 하나의 문자만 저장하는 것이 경제적이다.
LZW 알고리즘은 각 픽셀에 대해 테이블을 검색해야 한다. 최대 4096개 주소를 선형 검색하면 코딩이 느려진다. 실제로 코드는 숫자 값 순서로 저장할 수 있다. 이렇게 하면 각 검색이 SAR(Successive Approximation Register, 일부 ADC에서 사용됨)에 의해 단 12개의 크기 비교만으로 수행될 수 있다. 이러한 효율성을 위해 코드와 실제 메모리 주소 간의 변환을 위한 추가 테이블이 필요하다. 추가 테이블 유지는 픽셀 속도보다 훨씬 적은 빈도로 새 코드가 저장될 때만 필요하다.
압축되지 않은 GIF
[편집] 46x46 압축되지 않은 GIF, 7비트 심볼 (128색, 8비트 코드). |
GIF 인코딩 프로세스는 LZW 압축 없이도 GIF 이미지로 볼 수 있는 파일을 생성하도록 수정될 수 있다. 이 기술은 원래 특허 침해를 피하는 방법으로 도입되었다. 압축되지 않은 GIF는 개별 픽셀을 읽거나 그릴 수 있기 때문에 그래픽 프로그래머에게 유용한 중간 형식일 수도 있다. 압축되지 않은 GIF 파일은 이미지 편집기를 통해 단순히 통과시키는 것만으로 일반 GIF 파일로 변환될 수 있다.
수정된 인코딩 방식은 LZW 테이블 구축을 무시하고 루트 팔레트 코드와 CLEAR 및 STOP 코드를 내보낸다. 이는 더 간단한 인코딩(코드 값과 팔레트 코드 간의 1대1 대응)을 제공하지만, 모든 압축을 희생한다: 이미지의 각 픽셀은 해당 색상 인덱스를 나타내는 출력 코드를 생성한다. 압축되지 않은 GIF를 처리할 때, 표준 GIF 디코더는 문자열을 사전 테이블에 쓰는 것을 막지 않지만, 코드 너비는 절대 증가해서는 안 된다. 이는 비트와 바이트의 다른 패킹을 유발하기 때문이다.
심볼 너비가 n이면, 너비가 n+1인 코드는 자연스럽게 두 블록으로 나뉜다: 단일 심볼을 코딩하기 위한 2n개의 하위 블록 코드와 길이가 1보다 큰 시퀀스에 대해 디코더가 사용할 2n개의 상위 블록 코드. 이 상위 블록 중 처음 두 코드는 이미 사용 중이다: CLEAR의 경우 2n이고, STOP의 경우 2n + 1이다. 디코더는 상위 블록의 마지막 코드인 2n+1 − 1도 사용하지 못하게 해야 한다. 디코더가 해당 슬롯을 채우면 코드 너비가 증가하기 때문이다. 따라서 상위 블록에는 코드 너비 증가를 유발하지 않는 2n − 3개의 코드가 디코더에서 사용 가능하다. 디코더는 항상 테이블 유지에서 한 단계 뒤처져 있으므로 인코더로부터 첫 번째 코드를 받을 때 테이블 항목을 생성하지 않지만, 각 후속 코드에 대해 테이블 항목을 생성한다. 따라서 인코더는 코드 너비 증가를 유발하지 않고 2n − 2개의 코드를 생성할 수 있다. 그러므로 인코더는 디코더가 코딩 사전을 재설정하도록 2n − 2개의 코드 또는 그 이하의 간격으로 추가 CLEAR 코드를 내보내야 한다. GIF 표준은 이러한 추가 CLEAR 코드를 이미지 데이터에 언제든지 삽입할 수 있도록 허용한다. 복합 데이터 스트림은 각 1에서 255바이트를 포함하는 서브 블록으로 분할된다.
위 샘플 3x5 이미지의 경우, 다음 9비트 코드는 "지우기"(100) 뒤에 스캔 순서대로 이미지 픽셀 및 "정지"(101)를 나타낸다.
100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
위 코드가 바이트로 매핑되면 압축되지 않은 파일은 압축된 파일과 다음과 같이 달라진다.
| 바이트 # (16진수) | 16진수 | 텍스트 또는 값 | 의미 |
|---|---|---|---|
| 320 | 14 | 20 | 20바이트 압축되지 않은 이미지 데이터가 뒤따름 |
| 321 | 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01 | ||
| 335 | 00 | 0 | 이미지 데이터 끝 |
압축 예시
[편집]단색의 큰 이미지라는 사소한 예시는 GIF 파일에 사용되는 가변 길이 LZW 압축을 보여준다.
| 코드 | 픽셀 | 참고 사항 | |||
|---|---|---|---|---|---|
| 번호Ni | 값Ni + 256 | 길이(비트) | 이 코드Ni | 누적Ni(Ni + 1)/2 | Ni만 사용하는 관계는 코딩 테이블이 가득 찰 때까지 동일 색상 픽셀에만 적용된다. |
| 0 | 100h | 9 | 코드 테이블 지우기 | ||
| 1 | FFh | 1 | 1 | 256색 팔레트의 가장 높은 인덱스로 선택된 왼쪽 상단 픽셀 색상 | |
| 2 | 102h | 2 | 3 | ||
| 3⋮255 | 103h⋮ | 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 | 최대 코드는 더 많은 동일 색상 픽셀에 대해 반복될 수 있다.전반적인 데이터 압축은 점근적으로 3839 × 8/12 = 2559+1/3에 접근한다. | ||
| 101h | 이미지 데이터 끝 | ||||
표시된 코드 값은 바이트로 압축된 다음 최대 255바이트 블록으로 압축된다. 이미지 데이터 블록은 뒤따르는 바이트 수를 선언하는 바이트로 시작한다. 이미지의 마지막 데이터 블록은 0 블록 길이 바이트로 표시된다.
인터레이싱
[편집]GIF 사양은 GIF 파일의 논리적 화면 내 각 이미지가 인터레이스되어 있음을 지정할 수 있도록 허용한다. 즉, 데이터 블록의 래스터 라인 순서가 순차적이지 않음을 의미한다. 이를 통해 전체 이미지가 그려지기 전에 인식될 수 있는 이미지의 부분적인 표시가 가능하다.
인터레이스된 이미지는 위에서 아래로 8픽셀 높이의 스트립으로 나뉘며, 이미지의 행은 다음 순서로 표시된다:
- 1단계: 각 스트립에서 0번째 줄 (가장 상단 줄).
- 2단계: 각 스트립에서 4번째 줄.
- 3단계: 각 스트립에서 2번째 및 6번째 줄.
- 4단계: 각 스트립에서 1, 3, 5, 7번째 줄.
각 줄 내의 픽셀은 인터레이스되지 않고 왼쪽에서 오른쪽으로 연속적으로 표시된다. 비인터레이스 이미지와 마찬가지로 한 줄의 데이터와 다음 줄의 데이터 사이에 끊김이 없다. 이미지가 인터레이스되었음을 나타내는 것은 해당 이미지 디스크립터 블록에 설정된 비트이다.
애니메이션 GIF
[편집]
GIF는 애니메이션 매체로 설계되지는 않았지만, 하나의 파일에 여러 이미지를 저장하는 기능은 자연스럽게 애니메이션 시퀀스의 프레임을 저장하는 데 이 형식을 사용하도록 제안되었다. 애니메이션 표시를 용이하게 하기 위해 GIF89a 사양은 파일의 이미지(프레임)를 시간 지연과 함께 그려서 비디오 클립을 형성할 수 있는 그래픽 제어 확장(GCE)을 추가했다. 애니메이션 GIF의 각 프레임은 프레임이 그려진 후 기다릴 시간 지연을 지정하는 자체 GCE로 시작된다. 파일 시작 부분의 전역 정보는 기본적으로 모든 프레임에 적용된다. 데이터는 스트림 지향적이므로 각 GCE의 시작 파일 오프셋은 이전 데이터의 길이에 따라 달라진다. 각 프레임 내에서 LZW로 코딩된 이미지 데이터는 최대 255바이트의 서브 블록으로 배열되며, 각 서브 블록의 크기는 그 앞에 오는 바이트로 선언된다.
기본적으로 애니메이션은 프레임 시퀀스를 한 번만 표시하고 마지막 프레임이 표시되면 멈춘다. 애니메이션을 반복할 수 있도록, 1990년대 넷스케이프는 애플리케이션 확장 블록(벤더가 GIF 파일에 응용 프로그램별 정보를 추가할 수 있도록 의도됨)을 사용하여 넷스케이프 애플리케이션 블록(NAB)을 구현했다.[39] 이 블록은 애니메이션 프레임 시퀀스 바로 앞에 배치되며, 프레임 시퀀스를 재생할 횟수(1에서 65535회) 또는 연속적으로 반복해야 하는지(0은 영원히 반복을 나타냄)를 지정한다. 이러한 반복 애니메이션에 대한 지원은 넷스케이프 내비게이터 버전 2.0에서 처음 등장했으며, 이후 다른 브라우저로 확산되었다.[40] 대부분의 브라우저는 이제 NAB를 인식하고 지원하지만, 이는 GIF89a 사양의 엄격한 부분은 아니다.
다음 예시는 문서 정보 상자에 미리보기 이미지로 표시된 Rotating earth (large).gif 애니메이션 파일의 구조를 보여준다.
| 바이트 # (16진수) | 16진수 | 텍스트 또는 값 | 의미 |
|---|---|---|---|
| 0 | 47 49 46 38 39 61 | GIF89a | 논리적 화면 디스크립터 |
| 6 | 90 01 | 400 | 픽셀 단위 너비 |
| 8 | 90 01 | 400 | 픽셀 단위 높이 |
| A | F7 | 해상도 3 × 8비트/기본에 대해 256색 GCT가 뒤따름 | |
| 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 | 000.....
...001..
......0.
.......0
|
예약됨, 하위 5비트는 비트 필드 처리 방법 1: 폐기하지 않음 사용자 입력 없음 투명 색상, 0은 주어지지 않음을 의미 |
| 324 | 09 00 | 9 | 프레임 지연: 다음 프레임을 그리기 전 0.09초 지연 |
| 326 | FF | 투명 색상 인덱스 (이 프레임에서는 사용되지 않음) | |
| 327 | 00 | 그래픽 제어 확장 블록의 서브 블록 체인 끝 | |
| 328 | 2C | ',' |
이미지 디스크립터 (0x2C, ASCII 쉼표 ','로 시작)
|
| 329 | 00 00 00 00 | (0, 0) | 논리적 화면 내 이미지의 북서쪽 코너 위치: (0, 0) |
| 32D | 90 01 90 01 | (400, 400) | 프레임 너비 및 높이: 400 × 400 픽셀 |
| 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 신호 |
각 프레임의 애니메이션 지연은 GCE에 1/100초 단위로 지정된다. 프레임이 디스플레이의 일부 픽셀만 다시 그리면 되는 경우 데이터 절약이 가능하며, 이는 이미지 디스크립터가 전체 이미지가 아닌 다시 스캔될 작은 사각형을 정의할 수 있기 때문이다. 애니메이션 GIF를 지원하지 않는 브라우저 또는 다른 디스플레이는 일반적으로 첫 번째 프레임만 표시한다.
애니메이션 GIF 파일의 크기와 색상 품질은 파일을 생성하는 데 사용된 응용 프로그램에 따라 크게 달라질 수 있다. 파일 크기를 최소화하는 전략에는 모든 프레임에 공통 전역 색상 테이블을 사용하는 것(각 프레임에 완전한 로컬 색상 테이블을 사용하는 대신)과 연속 프레임에서 덮는 픽셀 수를 최소화하는 것(따라서 한 프레임에서 다음 프레임으로 변경되는 픽셀만 나중 프레임에 포함되도록)이 포함된다. 더 고급 기술은 기존 LZW 사전에 더 잘 맞도록 색상 시퀀스를 수정하는 것을 포함하며, 이는 손실 압축의 한 형태이다. 단순히 일련의 독립적인 프레임 이미지를 복합 애니메이션으로 압축하는 것은 큰 파일 크기를 초래하는 경향이 있다. 기존 GIF의 파일 크기를 최소화하는 도구를 사용할 수 있다.
메타데이터
[편집]메타데이터는 GIF 파일에 주석 블록, 일반 텍스트 블록 또는 애플리케이션별 애플리케이션 확장 블록으로 저장될 수 있다. 여러 그래픽 편집기는 이미지 생성에 사용된 데이터를 포함하기 위해 비공식 애플리케이션 확장 블록을 사용하여 추가 편집을 위해 데이터를 복구할 수 있도록 한다.
이러한 모든 방법은 기술적으로 메타데이터를 하위 블록으로 분할해야 하므로 애플리케이션은 내부 구조를 알지 않고도 메타데이터 블록을 탐색할 수 있다.
XMP 메타데이터 표준은 GIF 파일에 XMP 데이터를 포함하기 위한 비공식적이지만 현재 널리 사용되는 "XMP Data" 애플리케이션 확장 블록을 도입했다.[41] XMP 데이터는 NUL 문자가 없는 UTF-8로 인코딩되므로 데이터에 0 바이트가 없다. 데이터를 공식적인 하위 블록으로 분할하는 대신, 확장 블록은 데이터를 하위 블록으로 처리하는 모든 애플리케이션을 하위 블록 체인을 종료하는 최종 0 바이트로 라우팅하는 "매직 트레일러"로 종료된다.
유니시스 및 LZW 특허 시행
[편집]1977년과 1978년, 야콥 지브와 아브라함 렘펠은 새로운 종류의 비손실 데이터 압축 알고리즘에 대한 논문 두 편을 발표했는데, 현재는 총칭하여 LZ77 및 LZ78이라고 불린다. 1983년, 테리 웰치는 LZ78의 빠른 변형을 개발했으며, 이는 렘펠-지브-웰치(LZW)로 명명되었다.[42][43]
웰치는 1983년 6월 LZW 방식에 대한 특허 출원을 제출했다. 그 결과 1985년 12월에 부여된 특허 US4558302[44]는 스페리 코퍼레이션에 할당되었고, 스페리는 이후 1986년에 버로스 코퍼레이션과 합병하여 유니시스를 설립했다.[42] 추가 특허는 영국, 프랑스, 독일, 이탈리아, 일본, 캐나다에서 취득되었다.
위의 특허 외에도, 웰치의 1983년 특허는 또한 그것에 영향을 미친 몇 가지 다른 특허를 인용하고 있다:
- NEC의 카나쓰 준의 1980년 일본 특허 두 개,[45][46]
- 미국 특허 4,021,782 (1974) 존 S. 회르닝,
- 미국 특허 4,366,551 (1977) 클라우스 E. 홀츠, 그리고
- 칼 에크하르트 하인츠의 1981년 독일 특허.[47][48]
1984년 6월, 웰치의 논문이 IEEE 잡지에 실리면서 LZW 기술이 처음으로 공개적으로 설명되었다.[49] LZW는 인기 있는 데이터 압축 기술이 되었고, 특허가 부여되자 유니시스는 백 개 이상의 회사와 라이선스 계약을 체결했다.[42][50]
LZW의 인기로 인해 컴퓨서브는 1987년에 개발한 GIF 버전에 이를 압축 기술로 선택했다. 당시 컴퓨서브는 특허의 존재를 알지 못했다.[42] 유니시스는 GIF 버전이 LZW 압축 기술을 사용한다는 사실을 알게 되었고 1993년 1월 컴퓨서브와 라이선스 협상을 시작했다. 그 후의 계약은 1994년 12월 24일에 발표되었다.[43] 유니시스는 LZW 특허를 사용하는 모든 주요 상업 온라인 정보 서비스 회사가 유니시스로부터 합리적인 요율로 기술 라이선스를 받을 것으로 예상했지만, 온라인 서비스에 사용되는 비상업적, 비영리 GIF 기반 애플리케이션에 대해서는 라이선스 또는 수수료를 요구하지 않을 것이라고 밝혔다.[50]
이 발표 이후 컴퓨서브와 유니시스에 대한 광범위한 비난이 있었고, 많은 소프트웨어 개발자들이 GIF 사용을 중단하겠다고 위협했다. 포터블 네트워크 그래픽스 (PNG) 형식(아래 참조)은 이를 대체하기 위해 1995년에 개발되었다.[42][43][49] 그러나 PNG 형식에 대한 웹 브라우저 및 기타 소프트웨어 제작사의 지원을 얻는 것은 어려웠고, PNG의 인기가 점차 증가했음에도 불구하고 GIF를 대체하는 것은 불가능했다.[42] 따라서 LZW 압축이 없는 GIF 변형이 개발되었다. 예를 들어, 에릭 레이먼드의 giflib을 기반으로 하는 libungif 라이브러리는 데이터 형식을 따르지만 압축 기능을 피하여 유니시스 LZW 특허 사용을 피하는 GIF 생성을 허용한다.[51] 2001년 닥터 돕스 기사는 LZW 호환 인코딩을 특허 침해 없이 달성하는 방법을 설명했다.[52]
1999년 8월, 유니시스는 라이선스 관행의 세부 사항을 변경하여 특정 비상업적 및 개인 웹사이트 소유자가 5000달러 또는 7500달러의 일회성 라이선스 비용을 지불하고 라이선스를 얻을 수 있는 옵션을 발표했다.[53] 이러한 라이선스는 라이선스 소프트웨어를 사용하여 GIF를 생성한 웹사이트 소유자 또는 기타 GIF 사용자에게는 필요하지 않았다. 그럼에도 불구하고, 유니시스는 웹사이트에 GIF를 사용하면 5000달러를 청구하거나 고소당할 것이라고 믿는 사용자들로부터 수천 건의 온라인 공격과 모욕적인 이메일을 받았다.[54] 유니시스는 수백 개의 비영리 단체, 학교 및 정부에 무료 라이선스를 제공했음에도 불구하고 어떠한 좋은 홍보도 얻지 못했으며, 1999년에 "모든 GIF 태워버리기" 캠페인을 시작한 League for Programming Freedom과 같은 개인 및 단체로부터 계속해서 비난을 받았다.[55][56]
미국의 LZW 특허는 2003년 6월 20일에 만료되었다.[57] 영국, 프랑스, 독일, 이탈리아의 대응 특허는 2004년 6월 18일에, 일본 특허는 2004년 6월 20일에, 캐나다 특허는 2004년 7월 7일에 만료되었다.[57] 따라서 유니시스는 LZW 기술 개선과 관련된 추가 특허 및 특허 출원을 가지고 있지만,[57] LZW 자체(및 결과적으로 GIF)는 2004년 7월부터 자유롭게 사용할 수 있게 되었다.[58]
대안
[편집]PNG
[편집]포터블 네트워크 그래픽스 (PNG)는 유니시스의 LZW 압축 기술에 대한 특허 침해를 피하기 위해 GIF의 대체제로 설계되었다.[42] PNG는 GIF보다 더 나은 압축과 더 많은 기능을 제공하며,[59] 애니메이션만이 유일한 중요한 예외이다. PNG는 트루컬러 이미징과 알파 투명도가 필요한 경우 GIF보다 더 적합하다.
PNG 형식 지원은 천천히 이루어졌지만, 새로운 웹 브라우저는 PNG를 지원한다. 인터넷 익스플로러의 이전 버전은 PNG의 모든 기능을 지원하지 않는다. 버전 6 이하에서는 마이크로소프트 특정 HTML 확장을 사용하지 않으면 알파 채널 투명도를 지원하지 않는다.[60] PNG 이미지의 감마 보정은 버전 8 이전에는 지원되지 않았으며, 이전 버전에서 이러한 이미지를 표시하면 잘못된 색조를 가질 수 있었다.[61]
동일한 8비트(또는 그 이하) 이미지 데이터의 경우, PNG 인코딩에 사용되는 더 효율적인 압축 기술 덕분에 PNG 파일은 일반적으로 해당 GIF보다 작다.[62] GIF에 대한 완전한 지원은 주로 허용하는 복잡한 캔버스 구조로 인해 복잡하지만, 이것이 바로 컴팩트한 애니메이션 기능을 가능하게 하는 요인이다.
애니메이션 형식
[편집]비디오는 웹에서 흔히 사용되는 GIF가 가진 많은 문제를 해결한다. 여기에는 현저히 작은 파일 크기, 8비트 컬러 제한을 초과하는 능력, 프레임 간 코딩을 통한 더 나은 프레임 처리 및 압축이 포함된다. 웹 브라우저에서 GIF 형식에 대한 거의 보편적인 지원과 HTML 표준에서 비디오에 대한 공식 지원 부족으로 인해 GIF는 웹에서 짧은 비디오와 같은 파일을 표시하는 목적으로 부상했다.
- MNG ("멀티플 이미지 네트워크 그래픽스")는 원래 애니메이션을 위한 PNG 기반 솔루션으로 개발되었다. MNG는 2001년에 버전 1.0에 도달했지만, 이를 지원하는 애플리케이션은 거의 없다.
- APNG ("애니메이티드 포터블 네트워크 그래픽스")는 모질라가 2006년에 제안했다. APNG는 MNG 형식을 대체하는 PNG 형식의 확장이다. APNG는 2019년 기준으로 대부분의 브라우저에서 지원된다.[63] APNG는 애니메이션 청크를 이해할 수 없는 디코더에서 역호환성을 유지하면서(MNG와 달리) PNG 파일을 애니메이션화하는 기능을 제공한다. 이전 디코더는 단순히 애니메이션의 첫 번째 프레임을 렌더링한다.
- PNG 그룹은 2007년 4월 20일 APNG를 공식 확장으로 공식적으로 거부했다.[64]
- PNG를 기반으로 하는 단순 애니메이션 그래픽 형식에 대해 여러 가지 다른 접근 방식을 사용하는 후속 제안이 있었다.[65] 그럼에도 불구하고 APNG는 모질라에서 여전히 개발 중이며 파이어폭스 3.0에서 지원되며,[66][67] MNG 지원은 중단되었다.[68][69] APNG는 현재 크롬(버전 59.0부터), 오페라, 파이어폭스, 엣지를 포함한 모든 주요 웹 브라우저에서 지원된다.
- 내장된 어도비 플래시 객체와 MPEG 파일은 일부 웹사이트에서 간단한 비디오를 표시하는 데 사용되었지만, 추가 브라우저 플러그인이 필요했다.
- WebM과 WebP는 개발 중이며 일부 웹 브라우저에서 지원된다.[70]
- 웹 애니메이션의 다른 옵션으로는 AJAX를 사용하여 개별 프레임을 제공하거나 SVG ("확장 가능 벡터 그래픽") 이미지를 자바스크립트 또는 SMIL ("동기화된 멀티미디어 통합 언어")을 사용하여 애니메이션화하는 것이 포함된다.[71]
- 대부분의 웹 브라우저에서 HTML 비디오 (
<video>) 태그에 대한 광범위한 지원이 도입되면서 일부 웹사이트는 생성된 비디오 태그의 반복 버전을 사용한다. 이는 GIF와 같은 모양을 제공하지만, 압축된 비디오의 크기 및 속도 이점을 가진다.
- HEIF ("고효율 이미지 파일 포맷")는 2015년에 최종화된 이미지 파일 형식으로, HEVC 비디오 형식을 기반으로 하며 JPEG 이미지 형식과 관련된 이산 코사인 변환(DCT) 손실 압축 알고리즘을 사용한다. JPEG와 달리 HEIF는 애니메이션을 지원한다.[73]
- DCT 압축이 없는 GIF 형식에 비해 HEIF는 훨씬 더 효율적인 압축을 허용한다. HEIF는 더 많은 정보를 저장하고 동등한 GIF 크기의 작은 부분으로 고품질 애니메이션 이미지를 생성한다.[74]
- VP9는 4:2:0 크로마 서브샘플링과 알파 컴포지팅만 지원하며,[75] 이는 투명도와 미세한 색상 디테일을 가진 래스터화된 벡터 그래픽스를 결합한 GIF에는 적합하지 않을 수 있다.
- AV1 비디오 코덱 또는 AVIF는 비디오 또는 시퀀스 이미지로도 사용될 수 있다.
사용
[편집]2014년 4월, 4chan은 크기가 3MB 미만이고 길이가 2분인 무음 WebM 비디오를 지원하기 시작했으며,[76][77] 2014년 10월에는 Imgur가 사이트에 업로드된 모든 GIF 파일을 H.264 비디오로 변환하고 HTML 플레이어 링크에 .gifv 확장자를 가진 실제 파일처럼 보이도록 제공하기 시작했다.[78][79]
2016년 1월, 텔레그램은 모든 GIF를 MPEG-4 비디오로 다시 인코딩하기 시작했는데, 이는 "동일한 이미지 품질에 대해 최대 95% 적은 디스크 공간을 필요로 한다."[80]
같이 보기
[편집]각주
[편집]- ↑ 가 나 “Graphics Interchange Format, Version 87a”. W3C. 1987년 6월 15일. 2018년 12월 22일에 원본 문서에서 보존된 문서. 2012년 10월 13일에 확인함.
- ↑ Tiffany, Kaitlyn (2022년 10월 7일). “The GIF Is on Its Deathbed”. 디 애틀랜틱. 2023년 10월 21일에 확인함.
- ↑ 가 나 “Graphics Interchange Format, Version 89a”. W3C. 1990년 7월 31일. 2018년 12월 22일에 원본 문서에서 보존된 문서. 2009년 3월 6일에 확인함.
- ↑ “Online Art”. 《Compute!'s Apple Applications》. December 1987. 10면. 2016년 9월 14일에 확인함.
- ↑ Holdener III, Anthony (2008). 《Ajax: The Definitive Guide: Interactive Applications for the Web》. O'Reilly Media. ISBN 978-0596528386.
- ↑ Furht, Borko (2008). 《Encyclopedia of Multimedia》. Springer. ISBN 978-0387747248.
- ↑ McHugh, Molly (2015년 5월 29일). “You Can Finally, Actually, Really, Truly Post GIFs on Facebook”. 《와이어드》. 2015년 5월 30일에 원본 문서에서 보존된 문서. 2015년 5월 29일에 확인함.
- ↑ Perez, Sarah (2015년 5월 29일). “Facebook Confirms It Will Officially Support GIFs”. 테크크런치. 2015년 5월 30일에 원본 문서에서 보존된 문서. 2015년 5월 29일에 확인함.
- ↑ “Introducing GIF Stickers”. 《Instagram》 (미국 영어). 2018년 1월 23일. 2019년 12월 12일에 원본 문서에서 보존된 문서. 2019년 9월 19일에 확인함.
- ↑ Ghoshal, Abhimanyu (2016년 10월 28일). “Enjoy 1.6 million gloriously old-school GIFs from the GeoCities era”. 《TNW | Shareables》 (영어). 2024년 11월 4일에 확인함.
- ↑ “GifCities”. 《gifcities.org》. 2024년 11월 4일에 확인함.
- ↑ “Oxford Dictionaries USA Word of the Year 2012”. 《OxfordWords blog》. Oxford American Dictionaries. 2012년 11월 13일. 2014년 8월 3일에 원본 문서에서 보존된 문서. 2013년 5월 1일에 확인함.
- ↑ Flood, Alison (2013년 4월 27일). “Gif is America's word of the year? Now that's what I call an omnishambles”. Books blog. 《가디언》 (London). 2016년 12월 1일에 원본 문서에서 보존된 문서. 2013년 5월 1일에 확인함.
- ↑ Olsen, Steve. “The GIF Pronunciation Page”. 2009년 2월 25일에 원본 문서에서 보존된 문서. 2009년 3월 6일에 확인함.
- ↑ 가 나 다 “Gif's inventor says ignore dictionaries and say 'Jif'”. 《BBC News》. 2013년 5월 22일. 2018년 6월 27일에 원본 문서에서 보존된 문서. 2013년 5월 22일에 확인함.
- ↑ Buck, Stephanie (2014년 10월 21일). “70 percent of people worldwide pronounce GIF with a hard g”. 《매셔블》. 2021년 12월 23일에 원본 문서에서 보존된 문서. 2021년 12월 24일에 확인함.
- ↑ van der Meulen, Marten (2019년 5월 22일). 《Obama, SCUBA or gift?: Authority and argumentation in online discussion on the pronunciation of GIF》. 《English Today》 36. 45–50쪽. 2022년 5월 24일에 원본 문서에서 보존된 문서. 2022년 5월 22일에 확인함.
- ↑ “GIF”. 《The American Heritage Abbreviations Dictionary, Third Edition》. Houghton Mifflin Company. 2005. 2011년 9월 3일에 원본 문서에서 보존된 문서. 2007년 4월 15일에 확인함.
- ↑ “GIF”. 《The Cambridge Dictionary of American English》. Cambridge University Press. 2014년 2월 27일에 원본 문서에서 보존된 문서. 2014년 2월 19일에 확인함.
- ↑ “Gif - Definition from the Merriam-Webster Dictionary”. 《Merriam-Webster Dictionary》. Merriam-Webster, Incorporated. 2013년 10월 22일에 원본 문서에서 보존된 문서. 2013년 6월 6일에 확인함.
- ↑ “GIF”. 《Oxford Dictionaries Online》. Oxford University Press. 2014년 10월 12일에 원본 문서에서 보존된 문서. 2014년 10월 7일에 확인함.
- ↑ “gif noun - Definition, pictures, pronunciation and usage notes | Oxford Advanced Learner's Dictionary”. 《Oxford Learner's Dictionaries》. 2020년 11월 24일에 원본 문서에서 보존된 문서. 2021년 2월 6일에 확인함.
- ↑ “GIF | Definition of GIF by Oxford Dictionary”. 《Lexico》 (영어). 2021년 2월 13일에 원본 문서에서 보존된 문서. 2021년 2월 6일에 확인함.
- ↑ Stevenson, Angus, 편집. (2010). 《Oxford Dictionary of English》 3판. Oxford University Press. ISBN 9780199571123. OCLC 729551189. 2022년 8월 23일에 원본 문서에서 보존된 문서. 2021년 2월 6일에 확인함.
- ↑ 《The New Oxford American Dictionary》 2판. Oxford University Press. 2005. 711쪽.
- ↑ 《The New Oxford American Dictionary》 3판. 2012. (part of the Macintosh built-in dictionaries).
- ↑ O'Leary, Amy (2013년 5월 21일). “An Honor for the Creator of the GIF”. 《더 뉴욕 타임스》. 2013년 5월 22일에 원본 문서에서 보존된 문서. 2013년 5월 22일에 확인함.
- ↑ 가 나 Rothberg, Daniel (2013년 12월 4일). “'Jeopardy' wades into 'GIF' pronunciation battle”. 《로스앤젤레스 타임스》. 2013년 12월 6일에 원본 문서에서 보존된 문서. 2013년 12월 4일에 확인함.
- ↑ O'Leary, Amy (2013년 5월 23일). “Battle Over 'GIF' Pronunciation Erupts”. 《더 뉴욕 타임스》. 2013년 12월 16일에 원본 문서에서 보존된 문서. 2013년 12월 5일에 확인함.
- ↑ Valinsky, Jordan (February 25, 2020). “Jif settles the great debate with a GIF peanut butter jar”. 《CNN》. February 25, 2020에 원본 문서에서 보존된 문서. February 25, 2020에 확인함.
- ↑ Marur, D.R.; Bhaskar, V. (March 2012). 〈2012 International Conference on Devices, Circuits and Systems (ICDCS)〉. 《Devices, Circuits and Systems (ICDCS)》. International Conference on Devices, Circuits and Systems (ICDCS). Karunya University; Coimbatore, India: IEEE. 297–301쪽. doi:10.1109/ICDCSyst.2012.6188724. ISBN 9781457715457. 2017년 7월 2일에 원본 문서에서 보존된 문서. 2015년 3월 11일에 확인함.
- ↑ S. Chin; D. Iverson; O. Campesato; P. Trani (2011). 《Pro Android Flash》 (PDF). New York: Apress. 350쪽. ISBN 9781430232315. 2015년 4월 2일에 원본 문서 (PDF)에서 보존된 문서. 2015년 3월 11일에 확인함.
- ↑ Bakhshi, Saeideh; Shamma, David A.; Kennedy, Lyndon; Song, Yale; de Juan, Paloma; Kaye, Joseph "Jofish" (2016년 5월 7일). 〈Fast, Cheap, and Good: Why Animated GIFs Engage Us〉. 《Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems》. 575–586쪽. doi:10.1145/2858036.2858532. ISBN 9781450333627. S2CID 7417853. 2022년 8월 17일에 확인함.
- ↑ Highfield, Tim; Leaver, Tama (2016). 《Instagrammatics and digital methods: studying visual social media, from selfies and GIFs to memes and emoji》. 《Communication Research and Practice》 2. 47–62쪽. doi:10.1080/22041451.2016.1155332. hdl:20.500.11937/36939. S2CID 148538216. 2022년 8월 17일에 확인함.
- ↑ 가 나 다 Andreas Kleinert (2007). “GIF 24 Bit (truecolor) extensions”. 2012년 3월 16일에 원본 문서에서 보존된 문서. 2012년 3월 23일에 확인함.
- ↑ 가 나 Philip Howard. “True-Color GIF Example”. 2015년 2월 22일에 원본 문서에서 보존된 문서. 2012년 3월 23일에 확인함.
- ↑ “Nullsleep - Jeremiah Johnson - Animated GIF Minimum Frame Delay Browser Compatibility Study”. 2014년 10월 10일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ “They're different! How to match the animation rate of gif files accross [sic] browsers”. 《Developer's Blog》. 2012년 2월 14일. 2017년 2월 1일에 원본 문서에서 보존된 문서. 2017년 6월 15일에 확인함.
- ↑ Royal Frazier. “All About GIF89a”. 1999년 4월 18일에 원본 문서에서 보존된 문서. 2013년 1월 7일에 확인함.
- ↑ Scott Walter (1996). 《Web Scripting Secret Weapons》. Que Publishing. ISBN 0-7897-0947-3.
- ↑ “XMP Specification Part 3: Storage in Files” (PDF). Adobe. 2016. 11–12쪽. 2018년 2월 25일에 원본 문서 (PDF)에서 보존된 문서. 2018년 8월 16일에 확인함.
- ↑ 가 나 다 라 마 바 사 Greg Roelofs. “History of the Portable Network Graphics (PNG) Format”. 2012년 3월 7일에 원본 문서에서 보존된 문서. 2012년 3월 23일에 확인함.
- ↑ 가 나 다 Stuart Caie. “Sad day... GIF patent dead at 20”. 2012년 2월 10일에 원본 문서에서 보존된 문서. 2012년 3월 23일에 확인함.
- ↑ US 4558302, Welch, Terry A., published 1985-12-10, assigned to Sperry Corp.
- ↑ JP patent S5719857A, Kanatsu, Jiyun, "Data compression storage device", published 1982-02-02, assigned to 일본전기
- ↑ JP patent S57101937A, Kanatsu, Jiyun, "Data storage device", published 1986-20-24, assigned to 일본전기
- ↑ DE patent 3118676, Eckhart, Heinz Karl, "Verfahren zur Kompression redundanter Folgen serieller Datenelemente [Method for compressing redundant sequences of serial data elements]", published 1982-12-02
- ↑ 미국 특허 4,558,302
- ↑ 가 나 “The GIF Controversy: A Software Developer's Perspective”. 1995년 1월 27일. 2016년 8월 23일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ 가 나 “Unisys Clarifies Policy Regarding Patent Use in On-Line Service Offerings”. 2007년 2월 7일에 원본 문서에서 보존된 문서. – archived by League for Programming Freedom
- ↑ “Libungif”. 2015년 4월 13일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ Cargill, Tom (2001년 10월 1일). “Replacing a Dictionary with a Square Root”. 《닥터 돕스 저널》. 2017년 6월 28일에 원본 문서에서 보존된 문서. 2017년 1월 20일에 확인함.
- ↑ “LZW Software and Patent Information”. 2009년 6월 8일에 원본 문서에서 보존된 문서. 2007년 1월 31일에 확인함. – clarification of 2 September 1999
- ↑ 유니시스, GIF 사용 웹마스터 대부분을 고소하지 않음 보관됨 10 5월 2017 - 웨이백 머신 – 슬래시닷의 논란 조사
- ↑ “Burn All GIFs Day”. 1999년 10월 13일에 원본 문서에서 보존된 문서.
- ↑ Burn All GIFs 보관됨 3 2월 2007 - 웨이백 머신 – League for Programming Freedom의 프로젝트 (최신 버전)
- ↑ 가 나 다 “License Information on GIF and Other LZW-based Technologies”. 2009년 6월 2일에 원본 문서에서 보존된 문서. 2005년 4월 26일에 확인함.
- ↑ “Why There Are No GIF Files on GNU Web Pages”. Free Software Foundation. 2012년 5월 19일에 원본 문서에서 보존된 문서. 2012년 5월 19일에 확인함.
- ↑ “PNG versus GIF Compression”. 2007년 3월 31일. 2009년 7월 15일에 원본 문서에서 보존된 문서. 2009년 6월 8일에 확인함.
- ↑ “AlphaImageLoader Filter”. Microsoft. 2012년 9월 4일. 2014년 10월 3일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ “What's New in Internet Explorer 7”. 《MSDN》. 2009년 3월 1일에 원본 문서에서 보존된 문서. 2009년 3월 6일에 확인함.
- ↑ “PNG Image File Format”. 2009년 6월 14일에 원본 문서에서 보존된 문서. 2009년 6월 8일에 확인함.
- ↑ “Can I use... Support tables for HTML5, CSS3, etc”. 《caniuse.com》. 2018년 2월 19일에 원본 문서에서 보존된 문서. 2020년 4월 10일에 확인함.
- ↑ “VOTE FAILED: APNG 20070405a”. 소스포지 메일링 리스트. 2007년 4월 20일. 2013년 2월 13일에 원본 문서에서 보존된 문서. 2013년 7월 14일에 확인함.
- ↑ “Discussion for a simple "animated" PNG format”. 2009년 2월 26일에 원본 문서에서 보존된 문서. 2011년 7월 12일에 확인함.
- ↑ “APNG Specification”. 2010년 7월 5일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ “Mozilla Labs » Blog Archive » Better animations in Firefox 3”. 2007년 8월 13일. 2016년 3월 7일에 원본 문서에서 보존된 문서. 2016년 2월 3일에 확인함.
- ↑ “195280 – Removal of MNG/JNG support”. 2021년 2월 25일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ “18574 – (mng) restore support for MNG animation format and JNG image format”. 2021년 3월 17일에 원본 문서에서 보존된 문서. 2015년 5월 26일에 확인함.
- ↑ “Chromium Blog: Chrome 32 Beta: Animated WebP images and faster Chrome for Android touch input”. Blog.chromium.org. 2013년 11월 21일. 2018년 7월 17일에 원본 문서에서 보존된 문서. 2014년 2월 1일에 확인함.
- ↑ Calou, Juan. “SVG Animation - A Guide”. 《Toptal》. 2024년 3월 15일에 확인함.
- ↑ “Introducing GIFV - Imgur Blog”. imgur.com. 2014년 10월 9일. 2014년 12월 14일에 원본 문서에서 보존된 문서. 2014년 12월 14일에 확인함.
- ↑ Thomson, Gavin; Shah, Athar (2017). “Introducing HEIF and HEVC” (PDF). 애플. 2020년 1월 19일에 원본 문서 (PDF)에서 보존된 문서. 2019년 8월 5일에 확인함.
- ↑ “HEIF Comparison - High Efficiency Image File Format”. Nokia Technologies. 2019년 7월 25일에 원본 문서에서 보존된 문서. 2019년 8월 5일에 확인함.
- ↑ “#3271 (Allow using additional pixel formats with libvpx-vp9) – FFmpeg”. 《trac.ffmpeg.org》. 2020년 6월 16일에 원본 문서에서 보존된 문서. 2020년 4월 10일에 확인함.
- ↑ Dewey, Caitlin. “Meet the technology that could make GIFs obsolete”. 《워싱턴 포스트》. 2015년 5월 11일에 원본 문서에서 보존된 문서. 2015년 2월 4일에 확인함.
- ↑ “WebM support on 4chan”. 4chan Blog. 2014년 4월 6일에 원본 문서에서 보존된 문서. 2015년 2월 4일에 확인함.
- ↑ “Introducing GIFV”. Imgur. 2014년 8월 9일. 2020년 5월 5일에 원본 문서에서 보존된 문서. 2016년 7월 21일에 확인함.
- ↑ Allan, Patrick (2014년 10월 9일). “Imgur Revamps GIFs for Faster Speeds and Higher Quality with GIFV”. 라이프해커. 2015년 2월 3일에 원본 문서에서 보존된 문서. 2015년 2월 4일에 확인함.
- ↑ “GIF Revolution”. 《Official Telegram Blog》. 2016년 1월 4일. 2016년 1월 10일에 원본 문서에서 보존된 문서. 2016년 1월 4일에 확인함.
외부 링크
[편집]- GIF89a 규격
- GIF 특허
- Burn All GIFs
- GNU 웹 페이지에 GIF 파일을 사용하지 않는 이유
- The GIF Controversy: A Software Developer's Perspective (Michael C. Battilana)
- The GIF situation (League of Programming Freedom)
| 래스터 |
|
|---|---|
| Raw | |
| 벡터 | |
| 복합 | |
| 관련 항목 | |
