GIF

GIF
기타 용도는 GIF(동음이의)를 참조하십시오.
GIF
회전하는 지구의 애니메이션 GIF
파일 확장자
.gif
인터넷 매체 유형
image/gif
타입코드GIFf
UTI(Uniform Type Identifier)com.compuserv.gif
매직넘버GIF87a/GIF89a
개발자 :컴퓨서브
초기출시1987년 6월 15일; 36년 전 (1987-06-15)[1]
최신판
89a
1989;34년전(1989)[2]
형식 유형무손실의 비트맵 이미지 형식
웹사이트www.w3.org/Graphics/GIF/spec-gif89a.txt

그래픽스 인터체인지 포맷(GIF; / ɡɪf/ GHIF 또는 /d ʒɪf/ JIF, 발음 참조)은 미국의 컴퓨터 과학자 스티브 윌하이트가 이끄는 온라인 서비스 제공업체 CompuServe의 한 팀이 개발하여 1987년 6월 15일에 출시한 비트맵 이미지 포맷입니다.응용 프로그램과 운영 체제 간의 광범위한 지원과 휴대성으로 인해 월드 와이드 웹에서 널리 사용되고 있습니다.

이 형식은 각 이미지에 대해 픽셀당 최대 8비트를 지원하므로 단일 이미지에서 24비트 RGB 색 공간에서 선택한 최대 256가지 색상의 팔레트를 참조할 수 있습니다.또한 애니메이션을 지원하며 프레임별로 최대 256가지 색상의 팔레트를 별도로 사용할 수 있습니다.이러한 팔레트 제한으로 인해 GIF는 색상 그라디언트를 사용하여 색상 사진 및 기타 이미지를 재생하는 데 적합하지 않지만 그래픽이나 색상이 단색인 로고와 같은 단순한 이미지에는 적합합니다.

GIF 이미지는 LZW(Lempel-Ziv-Welch) 무손실 데이터 압축 기법을 사용하여 압축되어 화질 저하 없이 파일 크기를 줄입니다.

역사

상세 정보 : § 유니시스 및 LZW 특허 집행

1987년 6월 15일, 컴퓨서브는 GIF를 도입하여 파일 다운로드 영역에 컬러 이미지 형식을 제공했습니다.이것은 흑백만 있었던 이전의 실행 길이 인코딩 형식을 대체했습니다.GIF는 렘펠-지브-웰치 데이터 압축을 사용했기 때문에 인기를 끌었습니다.이것은 PCX와 MacPaint에서 사용하는 실행 길이 인코딩보다 더 효율적이었기 때문에 꽤 큰 이미지를 느린 모뎀에서도 비교적 빠르게 다운로드할 수 있었습니다.

GIF의 원래 버전은 87a라고 불렸습니다.[1]이 버전은 이미 스트림에서 여러 이미지를 지원했습니다.

1989년에 CompuServe는 89a라고 불리는 향상된 버전을 출시했습니다.[2] 이 버전은 다음과 같이 덧붙였습니다.

  • 애니메이션 지연 지원
  • 투명한 배경색
  • 애플리케이션별 메타데이터 저장
  • 텍스트 레이블을 텍스트로 허용합니다(그래픽 데이터에 포함하지 않음).그러나 디스플레이 글꼴에 대한 제어가 거의 없기 때문에 이 기능은 거의 사용되지 않습니다.

두 버전은 파일의 처음 6바이트("마법의 숫자" 또는 서명)를 보고 구별할 수 있으며, ASCII로 해석하면 "GIF87a" 또는 "GIF89a"라고 각각 읽습니다.

CompuServe는 많은 컴퓨터에 다운로드 가능한 변환 유틸리티를 제공함으로써 GIF의 채택을 장려했습니다.예를 들어, 1987년 12월까지 Apple IIGS 사용자는 Atari ST 또는 Commodore 64에서 만든 사진을 볼 수 있었습니다.[3]GIF는 웹 사이트에서 일반적으로 사용되는 두 개의 이미지 형식 중 하나였으며, 다른 하나는 흑백 XBM이었습니다.[4]

1995년 9월 넷스케이프 내비게이터 2.0은 애니메이션 GIF의 루프 기능을 추가했습니다.

GIF는 CompuServe가 개발했지만 1985년 유니시스가 특허를 낸 LZW(Lempel-Ziv-Welch) 무손실 데이터 압축 알고리즘을 사용했습니다.1994년 유니시스와 컴푸서브 간의 라이선스 계약에 대한 논란은 포터블 네트워크 그래픽스(PNG) 표준의 개발을 촉진시켰습니다.2004년에 GIF에 사용된 독점 압축과 관련된 모든 특허가 만료되었습니다.

여러 이미지를 하나의 파일에 저장하고 제어 데이터를 동반하는 기능은 단순한 애니메이션을 제작하기 위해 웹에서 광범위하게 사용됩니다.

부분적으로 다운로드된 이미지도 어느 정도 인식이 가능할 정도로 이미지 스캔 라인을 정상적으로 저장하는 옵션 인터레이싱 기능도 GIF의 인기에 도움이 되었습니다.[5]

2015년 5월 페이스북은 GIF에 대한 지원을 추가했습니다.[6][7]2018년 1월 인스타그램은 스토리 모드에 GIF 스티커를 추가하기도 했습니다.[8]

용어.

명사로서 GIF라는 단어는 많은 사전의 최신판에서 볼 수 있습니다.2012년 옥스퍼드 대학교 출판부의 아메리칸 윙은 GIF를 동사로 인정했는데, 이는 "GIF는 하계 올림픽 장면을 공유하는 데 완벽한 매체였다"는 것과 같습니다.언론 사전 편찬자들은 GIF가 "연구와 저널리즘을 포함한 심각한 응용 프로그램을 가진 도구"로 발전했다고 말하면서 올해의 단어로 투표했습니다.[9][10]

발음

주요 기사 : GIF 발음
백악관 텀블러 계정 출시를 알리는 익살스러운 이미지는 GIF를 딱딱한 g로 발음하는 것을 제안합니다.

GIF의 첫 글자의 발음은 1990년대부터 논란이 되어 왔습니다.영어에서 가장 일반적인 발음은 /d ʒɪf/ (부드러운 기스가 있는)와 / ɡɪf/ (부드러운 기스가 있는)이며, 문자 G로 표현되는 음소에 차이가 있습니다.이 포맷을 만든 사람들은 GIF라는 두문자를 /d ʒɪf/로 발음하고 부드러운 g를 붙였는데, 윌하이트는 이 발음이 미국 땅콩 버터 브랜드인 지프를 의도적으로 따라하도록 의도했다고 말했으며, 컴푸서브 직원들은 지프의 텔레비전 광고를 패러디한 "신선한 개발자들이 GIF를 선택한다"는 말을 자주 꺼내기도 했습니다.그러나, 그 단어는 / ɡɪf/로 널리 발음되고, 딱딱한 g와 함께, 여론조사는 일반적으로 이 딱딱한 g 발음이 더 널리 사용된다는 것을 보여주었습니다.

Dictionary.com 에서는 두 발음을 모두 인용하여 /d ʒɪf/를 주요 발음으로 표기하고 있으며, 미국 영어 캠브리지 사전에서는 어려운 g 발음만을 제공하고 있습니다.메리엄-웹스터의 대학 사전과 옥스퍼드 사전은 두 가지 발음을 모두 인용하지만 / ɡɪf, d ʒɪf/를 어려운 g를 우선으로 합니다.New Oxford American Dictionary에서는 2판에서 /d ʒɪf/만 부여했지만 3판에서는 /d ʒɪf, ɡɪf/로 업데이트했습니다.

발음에 대한 의견 차이로 인해 인터넷 토론이 가열되고 있습니다.2013년 웹비 어워드 시상식에서 평생 공로상을 받은 것을 계기로 윌하이트는 어려운 발음을 공개적으로 거부했습니다.[12][24][25] 그의 연설은 트위터에 17,000개 이상의 게시물과 수십 개의 뉴스 기사로 이어졌습니다.[26]백악관과[12] TV 프로그램인 Jeopardy!도 2013년에 토론에 참여했습니다.[25]2020년 2월, Jif 브랜드의 소유주인 J.M. Smucker Company는 애니메이션 이미지 데이터베이스 및 검색 엔진 Giphy와 제휴하여 한정판 "Jif vs. GIF" (해시태그 #J)를 출시했습니다.IFvsGIF) 땅콩버터 전용으로 soft-g 발음을 유머러스하게 선언하는 라벨을 가진 땅콩버터 항아리, GIF는 hard-g 발음으로 독점적으로 발음됩니다.[27]

사용.

GIF는 로고와 같이 색상 수가 제한된 날카로운 끝의 라인 아트에 적합합니다.이는 가장자리가 잘 정의된 균일한 색상의 평평한 영역을 선호하는 무손실 압축 형식의 장점을 활용합니다.[28]또한 게임을 위한 저색 스프라이트 데이터를 저장하는 데도 사용할 수 있습니다.[29]GIF는 작은 애니메이션이나 저해상도 비디오 클립에 사용되거나 온라인 메시지에서 단어를 사용하는 대신 감정과 느낌을 전달하는 반응으로 사용될 수 있습니다.그들은 텀블러,[30] 페이스북, 트위터와 같은 소셜 미디어 플랫폼에서 인기가 많습니다.[31]

파일형식

개념적으로 GIF 파일은 0개 이상의 "이미지"로 채워진 고정된 크기의 그래픽 영역("논리 화면")을 설명합니다.많은 GIF 파일에는 전체 논리 화면을 채우는 단일 이미지가 있습니다.논리적 화면을 별도의 하위 이미지로 구분하기도 합니다.이미지는 애니메이션 GIF 파일에서 애니메이션 프레임으로 기능할 수도 있지만 전체 논리 화면을 채울 필요는 없습니다.

GIF 파일은 버전을 제공하는 고정 길이 헤더("GIF87a" 또는 "GIF89a")로 시작하여 픽셀 치수 및 논리 화면의 기타 특성을 제공하는 고정 길이 논리 화면 설명자로 시작합니다.또한 화면 설명자는 GCT(Global Color Table)의 존재 여부와 크기를 지정할 수 있으며, GCT(Global Color Table)가 있으면 그 다음에 표시됩니다.

그 후 파일은 세그먼트로 분할되며, 각 세그먼트는 1바이트의 센티넬에 의해 도입됩니다.

  • 이미지(0x2C, ASCII 쉼표에서 도입됨)',')
  • 확장 블록(0x21, ASCII 느낌표에 의해 도입됨)'!')
  • 트레일러(값 0x3B의 단일 바이트, ASCII 세미콜론)';'), 파일의 마지막 바이트여야 합니다.

영상은 고정 길이의 Image Descriptor(이미지 디스크립터)로 시작하며, 로컬 색상 테이블의 존재 및 크기를 지정할 수 있습니다(있는 경우 다음에 나타남).영상 데이터는 다음과 같습니다. 하나의 바이트는 인코딩되지 않은 심볼의 비트 폭을 제공하며(2비트 이상이어야 함, 바이컬러 영상의 경우에도 최소 2비트 폭이어야 함) LZW 인코딩 데이터가 포함된 하위 블록의 링크된 목록입니다.

확장 블록(87a 사양에서 이미 정의된 메커니즘을 통해 87a 정의를 "확장"하는 블록)은 보초, 확장 유형을 지정하는 추가 바이트 및 확장 데이터가 있는 하위 블록의 링크된 목록으로 구성됩니다.이미지를 수정하는 확장 블록(예: 선택적 애니메이션 지연 시간 및 선택적 투명 배경색을 지정하는 그래픽 제어 확장)은 세그먼트 앞에 참조하는 이미지가 있어야 합니다.

영상 데이터 및 확장 블록에 의해 사용되는 연결된 목록은 일련의 서브 블록으로 구성되며, 각 서브 블록은 서브 블록의 후속 데이터 바이트 수(1 ~ 255)를 나타내는 바이트로 시작합니다.일련의 서브블록은 빈 서브블록(0바이트)으로 종료됩니다.

이 구조는 모든 부분이 이해되지 않더라도 파일을 구문 분석할 수 있게 해줍니다.87a로 표시된 GIF에는 확장 블록이 포함되어 있을 수 있습니다. 디코더가 이해할 수 없는 확장 기능을 사용하지 않고 파일을 읽고 표시할 수 있습니다.

파일 형식에 대한 자세한 내용은 GIF 규격에서 다룹니다.[2]

팔레트

웹 안전 팔레트로 저장하고 Floyd-Steinberg 방법을 사용하여 건조한 GIF 이미지의 예입니다.이미지의 색상 수가 감소하여 이미지의 대비 및 색상이 현저히 떨어집니다.

GIF는 팔레트 기반입니다. 파일의 이미지(프레임)에 사용되는 색상은 최대 256개의 항목을 저장할 수 있는 팔레트 테이블에 해당 RGB 값이 정의되어 있으며, 이미지의 데이터는 팔레트 테이블의 인덱스(0-255)별 색상을 나타냅니다.팔레트의 색상 정의는 수백만 개의 음영(각 주별로 2개의24 음영, 8비트)의 색 공간에서 그릴 수 있지만, 프레임에서 사용할 수 있는 최대 색상 수는 256개입니다.GIF가 개발되었을 때 이 제한은 합리적인 것처럼 보였습니다. 동시에 더 많은 색상을 표시할 수 있는 하드웨어를 구입할 수 있는 사람이 거의 없었기 때문입니다.단순한 그래픽, 선 그리기, 만화 및 그레이 스케일 사진은 일반적으로 256색 미만의 색상이 필요합니다.

각 프레임은 하나의 인덱스를 "투명 배경색"으로 지정할 수 있습니다. 이 인덱스가 할당된 픽셀은 배경에서 동일한 위치에 있는 픽셀의 색을 띠며, 이전 애니메이션 프레임에 의해 결정되었을 수 있습니다.

디더링(detering)이라고 하는 많은 기술은 두 가지 이상의 색상의 픽셀을 사용하여 그 사이의 색상을 근사화함으로써 작은 색상 팔레트로 더 넓은 범위의 색상을 근사화하기 위해 개발되었습니다.이러한 기술은 공간 해상도를 희생하여 더 깊은 색상 해상도를 근사화합니다.GIF 사양에는 포함되지 않지만 이후 GIF 이미지로 인코딩된 이미지에서는 디더링을 사용할 수 있습니다.공간 해상도의 손실로 인해 일반적으로 화면에서 이미지가 흐릿하게 보이기 때문에, 그리고 디더링 패턴이 종종 이미지 데이터의 압축성을 방해하여 GIF의 주요 목적에 반하는 일을 하기 때문에, 이것은 종종 GIF 이미지에 대한 이상적인 해결책이 아닙니다.

그래픽 웹 브라우저[when?] 초기에는 8비트 버퍼(256가지 색상만 허용)가 포함된 그래픽 카드가 일반적이었고 웹세이프 팔레트를 사용하여 GIF 이미지를 만드는 것이 상당히 일반적이었습니다.[according to whom?]이로 인해 예측 가능한 디스플레이가 보장되었지만 색상 선택에 심각한 제약이 있었습니다.24비트 컬러가 일반적인 것이 되었을 때, 팔레트는 대신 개별 이미지에 최적의 컬러로 채워질 수 있었습니다.

작은 이미지에는 작은 컬러 테이블로 충분할 수 있으며, 컬러 테이블을 작게 유지하면 파일을 더 빨리 다운로드할 수 있습니다.87a 및 89a 사양 모두 1부터 8까지의 n에 대해 2가지n 색상의 색상 테이블을 허용합니다.대부분의 그래픽 응용프로그램은 이러한 테이블 크기의 GIF 이미지를 읽고 표시합니다. 그러나 일부는 이미지를 만들 때 일부 크기를 지원하지 않습니다.2, 16, 256 색상의 테이블이 널리 지원됩니다.

진색

GIF는 실제 색상 이미지에 거의 사용되지 않지만 가능합니다.[32][33]GIF 이미지에는 여러 개의 이미지 블록이 포함될 수 있으며, 각 블록에는 고유한 256색 팔레트가 있으며, 블록을 타일로 붙여 완전한 이미지를 만들 수 있습니다.또는 GIF89a 사양에서는 각 이미지 블록이 255개의 가시색과 하나의 투명색으로 이루어진 자체 팔레트를 포함할 수 있는 "투명" 색상 아이디어를 소개했습니다.각 레이어의 가시적인 부분이 상기 레이어의 투명한 부분들을 통해 나타나는 이미지 블록들을 레이어링함으로써 완전한 이미지가 생성될 수 있습니다.

일반적인 256색 이상의 색상을 표시하는 방법을 설명하기 위한 애니메이션 GIF

풀 컬러 이미지를 GIF로 렌더링하려면 원래 이미지를 255개 또는 256개 이하의 다른 색을 가진 작은 영역으로 분해해야 합니다.그런 다음 각 영역은 자체 로컬 팔레트가 있는 별도의 이미지 블록으로 저장되며 이미지 블록이 함께 표시되면(타일링 또는 부분 투명 이미지 블록 레이어를 통해) 완전한 풀 컬러 이미지가 나타납니다.예를 들어 이미지를 16x16 픽셀(총 256 픽셀)의 타일로 분할하면 더 큰 타일이 사용되고 유사한 색상이 병합되어 색상 정보가 일부 손실될 수 있지만 로컬 팔레트 한계인 256 색상을 초과하는 타일이 없습니다.[32]

각 이미지 블록은 고유의 로컬 컬러 테이블을 가질 수 있기 때문에 이미지 블록이 많은 GIF 파일은 매우 클 수 있어 풀 컬러 GIF의 유용성을 제한합니다.[33]또한 모든 GIF 렌더링 프로그램이 타일 또는 레이어 이미지를 올바르게 처리하는 것은 아닙니다.대부분의 렌더링 프로그램은 타일 또는 레이어를 애니메이션 프레임으로 해석하여 순차적으로[32] 표시하며, 대부분의 웹 브라우저는 0.1초 이상의 지연 시간으로 프레임을 자동으로 표시합니다.[34][35][better source needed]

예제 GIF 파일

Microsoft Paint는 작은 흑백 이미지를 다음 GIF 파일(확대 표시)로 저장합니다.
페인트는 GIF를 최적으로 사용하지 않습니다. 불필요하게 큰 색상 테이블(사용한 2색이 아닌 256색 전체를 저장)과 기호 폭으로 인해 이 GIF 파일은 15픽셀 이미지를 효율적으로 표현하지 못합니다.
그래픽 컨트롤 확장 블록이 색상 색인 16(16진수 10)을 투명으로 선언하지만 해당 색인은 이미지에 사용되지 않습니다.이미지 데이터에 나타나는 색상 인덱스는 10진수 40과 255뿐이며, 이는 글로벌 색상 테이블이 각각 흑백으로 매핑합니다.

샘플 이미지(확대), 실제 크기는 가로 3픽셀, 세로 5픽셀

다음 표의 16진수는 형식 명세가 명시한 대로 리틀 엔디언 바이트 순서입니다.

GIF 이미지 값 예시 표
바이트 # (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
R(빨간색) G(녹색) B(파란색)
0 0 0
글로벌 컬러 테이블, 컬러 #0: #000000, 블랙
예제에서 D부터h 30C까지의h 바이트는 256가지 색상의 팔레트를 정의합니다.
10 80 00 00
R(빨간색) G(녹색) B(파란색)
128 0 0
Global Color Table, color #1 : 투명비트, 이미지에 사용 안 함
... ... ... 전역 컬러 테이블은 30A까지 확장됩니다.
30A FF FF FF
R(빨간색) G(녹색) B(파란색)
255 255 255
글로벌 컬러 테이블, 컬러 #255: #fffff, 화이트
그래픽 컨트롤 확장
30D 21 '!' 확장 블록(ASCII 제외점에 의해 도입됨)'!')
30E F9 그래픽 컨트롤 확장
30층 04 4 GCE 데이터 양(4바이트)
310 01 투명 배경색. 비트 필드이며, 가장 낮은 비트는 투명도를 나타냅니다.
311 00 00 애니메이션에 대한 지연(100분의 1초), 사용되지 않음
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은 없음을 의미합니다.
이미지 데이터
31층 08 8 이미지 시작, LZW 최소 코드 크기
320 0B 11 첫 번째 데이터 하위 블록의 시작, 따를 11바이트의 인코딩된 데이터를 지정
321 0051 FC 1B 2870 A0 C1 83101 <이미지 데이터> 11바이트의 이미지 데이터(필드 320 참조)
32C 00 0 데이터 하위 블록 종료, 다음 데이터 바이트 없음 지정(및 이미지 끝)
트레일러
32D 3B ';' 파일 종료 블록 지시자(ASCII 세미콜론)';')

이미지코딩

왼쪽 위에서 수평으로 스캔된 영상 픽셀 데이터는 LZW 인코딩을 통해 코드로 변환된 다음 파일에 저장하기 위해 바이트로 매핑됩니다.픽셀 코드는 일반적으로 바이트의 8비트 크기와 일치하지 않으므로 코드는 "little-Endian" 방식으로 바이트로 패킹됩니다. 첫 번째 코드의 최하위 비트는 첫 번째 바이트의 최하위 비트에 저장되고, 코드의 상위 비트는 바이트의 상위 비트에 저장됩니다.필요에 따라 다음 바이트의 하위 비트에 쏟습니다.각 후속 코드는 아직 사용되지 않은 최소 유효 비트에서 시작하여 저장됩니다.

이 바이트 스트림은 일련의 "하위 블록"으로 파일에 저장됩니다.각 하위 블록의 최대 길이는 255바이트이며 하위 블록의 데이터 바이트 수를 나타내는 바이트 앞에 붙습니다.일련의 서브 블록은 빈 서브 블록(단일 0 바이트로 데이터 바이트가 0인 서브 블록을 나타냄)에 의해 종료됩니다.

위 샘플 이미지의 경우 9비트 코드와 바이트 간의 가역적 매핑이 아래에 나와 있습니다.

가역 매핑
9비트 코드 바이트
십육진법 이진법 이진법 십육진법
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비트 코드를 생성하는 인코딩 과정은 아래와 같습니다.로컬 문자열은 팔레트에서 픽셀 색상 번호를 누적하며, 로컬 문자열을 코드 테이블에서 찾을 수 있는 한 출력 작업이 없습니다.문자열을 추가하여 테이블이 초기 크기에서 커지기 전에 도착하는 처음 두 픽셀에 대한 특별한 처리가 있습니다.각 출력 코드가 끝나면 로컬 문자열이 최신 픽셀 색상으로 초기화됩니다(출력 코드에 포함할 수 없음).

테이블 9비트 문자열 --> code code Action #00000h 9비트 코드 팔레트의 루트 테이블 초기화 : 색상 : #255FFh clr 100h 끝 101h 100h 클리어 픽셀 로컬 색상 팔레트 문자열 BLACK #40 28 028h 첫 번째 픽셀 항상 테이블에 있는 WHITE #255 FF 문자열 항상 테이블에 1번째 문자열 추가 FF 초기화 로컬 문자열 WHITE #255 FF 문자열표 0FFh에서 찾을 수 없음 - 이전 문자열 FF FF 103h의 출력 코드 - 표 FF에 최신 문자열 추가 - 표 FF에 로컬 문자열 WHITE #255 FF 문자열 초기화 BLACK #40 FF FF 28 문자열을 테이블 103h에서 찾을 수 없음 - 이전 문자열 FF FF 28 104h의 출력 코드 - 표 28에 최신 문자열 추가 - 로컬 문자열 WHITE #255 28 FF 문자열 푸 초기화nd in table WHITE #255 28 FF String을 테이블 102h에 찾을 수 없음 - 이전 문자열 28 FF FF 105h에 대한 출력 코드 - 테이블 FF에 최신 문자열 추가 - 로컬 문자열 WHITE #255 FF String을 테이블 FF에 초기화 - 이전 문자열 FF FF FF 106h에 대한 출력 코드 - 테이블 FF에 최신 문자열 추가 - 초기화e 로컬 문자열 WHITE #255 FF 문자열 테이블에 발견됨 WHITE #255 FF FF 문자열 테이블에 발견됨 WHITE #255 FF FF FF 문자열 - 이전 문자열 FF FF FF FF FF FF 107h 출력 코드 - 테이블 FF에 최신 문자열 추가 - 테이블 FF에 초기화 로컬 문자열 WHITE #255 FF 문자열 테이블에 발견됨 WHITE #255 FF FF 문자열표에 FF FF FF FF 문자열 발견 픽셀 107h 더 이상 없음 - 마지막 문자열 101h End에 대한 출력 코드

명확한 설명을 위해 테이블은 길이가 증가하는 문자열로 구성된 것으로 위에 표시됩니다.이 방식은 작동할 수 있지만 테이블은 예측할 수 없는 양의 메모리를 소비합니다.저장할 각 새 문자열이 하나의 문자로 증강된 이전에 저장된 문자열로 구성된다는 점에 주목하여 실제로 메모리를 저장할 수 있습니다.각 주소에 기존 주소와 문자 한 개의 두 단어만 저장하는 것이 경제적입니다.

LZW 알고리즘은 각 픽셀에 대해 테이블을 검색해야 합니다.최대 4096개의 주소를 통해 선형 검색하면 코딩 속도가 느려집니다.실제로 코드는 수치 순서대로 저장할 수 있으며, 이를 통해 SAR(일부 ADC에서 사용되는 것과 같은 연속 근사 레지스터)로 각 검색을 수행할 수 있으며, 크기 비교는 12개뿐입니다.이러한 효율성을 위해 코드와 실제 메모리 주소 사이를 변환하기 위해 추가 테이블이 필요합니다. 픽셀 속도보다 훨씬 낮은 새 코드가 저장된 경우에만 추가 테이블 유지가 필요합니다.

영상복호화

디코딩은 저장된 바이트를 9비트 코드로 다시 매핑하여 시작합니다.아래와 같이 픽셀 색상을 복구하기 위해 디코딩됩니다.인코더에서 사용되는 테이블과 동일한 테이블은 다음 규칙에 따라 문자열을 추가하여 작성됩니다.

수신 코드가 테이블에 있습니까?
네. 로컬 코드에 문자열을 추가하고 들어오는 코드에 대한 문자열의 첫 번째 바이트를 추가합니다.
아니요. 로컬 코드에 대한 문자열을 추가한 다음 고유의 첫 번째 바이트 복사본
shift 9비트 ----> 로컬 테이블 픽셀 코드 코드 코드 --> 문자열 Palette color Action 100h 000h #0 9비트 코드의 루트 테이블 초기화 : palette : color 0FFh #255 100h clr 101h end 028h #40 BLACK 디코딩 첫 번째 픽셀 0FFh 028h 테이블 #255 WHITE - 테이블 102h 28FF의 출력 문자열 - 테이블 103h에 추가 0FFh 수신 코드 103h FF - 테이블에 추가 - 테이블 #255 WHITE #255 WHITE 102h 103h 수신 코드 - 테이블 #40의 출력 문자열BLACK #255 WHITE 104h FF FF 28 - 테이블에 103h 102h 수신 코드가 있음 - 테이블에 있는 출력 문자열 #255 WHITE #255 WHITE 105h 28 FF - 테이블에 있는 출력 문자열 106h 103h 수신 코드가 테이블에 없는 경우 - 테이블에 있는 출력 문자열 #255 WHITE #255 WHITE #255 WHITE 107h 106h 수신 코드가 테이블 107h FF에 없는 경우FF FF - 테이블에 추가 - 테이블의 출력 문자열 #255 WHITE #255 WHITE #255 WHITE #255 WHITE 101h 끝

LZW 코드 길이

예제에서 256색보다 작은 팔레트의 경우 더 짧은 코드 길이를 사용할 수 있습니다.팔레트의 색상이 64개뿐인 경우(색상 인덱스가 6비트 너비), 기호의 범위는 0에서 63까지이며, 코드는 7비트로 시작하여 6비트까지 사용할 수 있습니다.실제로 디코딩된 값이 팔레트의 색상 수보다 항상 작은 한, 기호는 2에서 8까지의 임의의 폭이 될 수 있으며 팔레트 크기는 2에서 256까지의 임의의 검정력이 될 수 있습니다.예를 들어 팔레트의 처음 4가지 색상(값 0~3)만 사용하는 경우 기호를 2비트 너비로 설정하고 3비트에서 시작하는 코드를 사용할 수 있습니다.

반대로 값 0과 1만 사용해도 심볼 폭을 8로 설정할 수 있습니다. 이러한 데이터에는 2색 테이블만 필요합니다.파일을 그런 식으로 인코딩하는 것은 의미가 없지만, 바이컬러 이미지의 경우에도 일반적으로 유사한 일이 발생합니다. 즉, 값 0과 1만 사용하더라도 최소 심볼 폭이 2입니다.

코드 테이블에는 처음에 두 개의 특수 코드 clr과 end 및 프로세스 중에 추가되는 문자열에 대한 코드를 수용하기 위해 심볼 크기보다 한 비트 더 긴 코드가 포함됩니다.테이블이 가득 차면 코드 길이가 증가하여 최대 코드 4095 = FFF(hex)까지 더 많은 문자열을 저장할 수 있습니다.디코더가 테이블을 만들 때 코드 길이의 증가를 추적하고 그에 따라 들어오는 바이트를 풀 수 있습니다.

압축되지 않은 GIF

7비트 기호(128색, 8비트 코드)가 포함된 46x46 비압축 GIF.
코드에 대한 설명을 보려면 이미지를 클릭합니다.

GIF 인코딩 프로세스를 수정하여 여전히 GIF 이미지로 볼 수 있는 LZW 압축 없이 파일을 생성할 수 있습니다.이 기술은 원래 특허 침해를 피하기 위한 방법으로 도입되었습니다.압축되지 않은 GIF는 개별 픽셀을 읽거나 그림을 그릴 수 있기 때문에 그래픽 프로그래머에게 유용한 중간 형식이 될 수도 있습니다.압축되지 않은 GIF 파일은 이미지 편집기를 통과하기만 하면 일반 GIF 파일로 변환할 수 있습니다.

수정된 인코딩 방법은 LZW 테이블 구축을 무시하고 루트 팔레트 코드와 CLEAR 및 STOP에 대한 코드만 출력합니다.이렇게 하면 더 간단한 인코딩(코드 값과 팔레트 코드 간의 1 대 1 대응)을 얻을 수 있지만 모든 압축을 희생합니다. 이미지의 각 픽셀은 컬러 인덱스를 나타내는 출력 코드를 생성합니다.압축되지 않은 GIF를 처리할 때 표준 GIF 디코더가 해당 사전 테이블에 문자열을 쓰는 것을 막을 수는 없지만, 비트에서 바이트까지 다른 패킹을 트리거하므로 코드 폭이 늘지 않아야 합니다.

심볼 폭이 n이면 너비 n+1의 코드는 두 개의 블록으로 자연스럽게 떨어집니다. 즉, 단일 심볼을 코딩하는 2개n 코드의 하위 블록과 1보다 큰 길이의 시퀀스에 대해 디코더가 사용할 2개n 코드의 상위 블록입니다.해당 상위 블록 중 처음 두 개의 코드(CLEAR의 경우 2n, STOP의 경우 2n + 1)가 이미 사용되고 있습니다.디코더가 해당 슬롯을 채울 때 코드 폭이 증가하기 때문에 디코더는 상단 블록의 마지막 코드인n+1 2 - 1을 사용하지 못하도록 해야 합니다.따라서 상위 블록에는 디코더에서 사용할 수 있는 코드가n 2 - 3개 있으며 코드 폭의 증가를 유발하지 않습니다.디코더는 항상 테이블을 유지하는 데 한 단계 뒤쳐지기 때문에 인코더로부터 첫 번째 코드를 수신할 때 테이블 엔트리를 생성하지 않고, 이어지는 코드마다 하나씩 생성합니다.따라서 인코더는 코드 폭의 증가를 유발하지 않고 2n - 2개의 코드를 생성할 수 있습니다.따라서, 디코더가 코딩 사전을 재설정하도록 하려면 인코더는 2 - 2 코드n 이하의 간격으로 추가 CLEAR 코드를 방출해야 합니다.GIF 표준은 이러한 추가 CLEAR 코드를 이미지 데이터에 언제든지 삽입할 수 있도록 합니다.복합 데이터 스트림은 각각 1-255바이트의 하위 블록으로 분할됩니다.

위의 샘플 3×5 이미지의 경우, 다음의 9비트 코드는 "맑음"(100)을 나타내고, 스캔 순서에 따라 이미지 픽셀을 나타내고 "정지"(101)를 나타냅니다.

1000 28 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

위의 코드를 바이트로 매핑한 후 압축되지 않은 파일은 압축된 파일과 다릅니다.

바이트 # (16진수) 십육진법 텍스트 또는 값 의미.
320 14 20 압축되지 않은 이미지 데이터가 20바이트 이어짐
321 0051 FC FB F70F C5 BF 7F FF FD FB F7 EFD BF 7F 0101
335 00 0 이미지 데이터의 끝

압축 예제

단색의 큰 이미지의 사소한 예는 GIF 파일에 사용되는 가변 길이의 LZW 압축을 보여줍니다.

GIF 파일의 샘플 압축
코드 픽셀 메모들
아니요.
ㄴi 		가치
Ni + 256		 길이
(비트)		 이코드
ㄴi 		누계
Ni(Ni + 1)/2 		N을i 사용하는 관계는 코딩 테이블이 가득 찰 때까지 동일한 색의 픽셀에만 적용됩니다.
0 백시 9 코드 테이블 지우기
1 FFh 1 1 256색 팔레트의 가장 높은 인덱스로 선택된 왼쪽 상단 픽셀 색상
2 102시간 2 3
3
⋮
255 		103h
⋮
1FFh		 3
⋮
255 		6
⋮
32640 		마지막 9비트 코드
256
⋮
767 		200시간
⋮
3FFh		 10 256
⋮
767 		32896
⋮
294528 		마지막 10비트 코드
768
⋮
1791 		400시간
⋮
7FFh		 11 768
⋮
1791 		295296
⋮
1604736 		마지막 11비트 코드
1792
⋮
3839 		800시간
⋮
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번 선.

각 선 내의 픽셀은 서로 맞물리지 않고 왼쪽에서 오른쪽으로 연속적으로 표시됩니다.인터레이스가 아닌 영상의 경우와 마찬가지로 한 선에 대한 데이터와 다음 선에 대한 데이터 사이에 끊김이 없습니다.영상이 인터레이스되는 표시기는 해당 Image Descriptor 블록에 설정된 비트입니다.

애니메이션 GIF

GIF는 뉴턴의 요람 이미지와 같이 애니메이션을 표시하는 데 사용할 수 있습니다.

GIF는 애니메이션 매체로 설계되지는 않았지만, 여러 이미지를 하나의 파일에 저장할 수 있는 기능은 자연스럽게 애니메이션 시퀀스의 프레임을 저장하는 형식을 사용하는 것으로 제안되었습니다.GIF89a 사양은 애니메이션을 쉽게 표시하기 위해 파일의 이미지(프레임)를 시간 지연으로 칠하여 비디오 클립을 형성할 수 있는 그래픽 제어 확장(GCE)을 추가했습니다.애니메이션 GIF의 각 프레임은 프레임이 그려진 후 대기할 시간 지연을 지정하는 자체 GCE에 의해 도입됩니다.파일을 시작할 때의 전역 정보는 기본적으로 모든 프레임에 적용됩니다.데이터는 스트림 중심이므로 각 GCE 시작의 파일 오프셋은 이전 데이터의 길이에 따라 달라집니다.각 프레임 내에서 LZW 부호화된 이미지 데이터는 최대 255바이트의 서브 블록으로 배열됩니다. 각 서브 블록의 크기는 이전의 바이트로 선언됩니다.

기본적으로 애니메이션은 프레임 시퀀스를 한 번만 표시하고 마지막 프레임이 표시될 때 중지합니다.1990년대에 Netscape는 애니메이션이 루프를 이루도록 하기 위해 응용 프로그램 확장 블록(벤더가 응용 프로그램별 정보를 GIF 파일에 추가할 수 있도록 함)을 사용하여 NAB(Netscape Application Block)를 구현했습니다.[36]애니메이션 프레임 시퀀스 바로 앞에 있는 이 블록은 프레임 시퀀스를 재생해야 하는 횟수(1~65535회) 또는 연속적으로 반복해야 하는 횟수(0은 영원히 루프를 나타냅니다)를 지정합니다.이러한 반복 애니메이션 지원은 넷스케이프 네비게이터 버전 2.0에서 처음 등장한 후 다른 브라우저로 확산되었습니다.[37]대부분의 브라우저는 현재 NAB를 인식하고 지원하지만 GIF89a 사양의 일부는 아닙니다.

다음 예제에서는 문서의 정보 상자에 표시된 Rotating earth(large).gif 애니메이션 파일의 구조를 보여 줍니다.

GIF의 구조
바이트 # (16진수) 십육진법 텍스트 또는 값 의미.
0 47 49 46 38 39 61 GIF89a 논리 화면 설명자
6 90 01 400 너비(픽셀)
8 90 01 400 높이(픽셀)
A F7 GCT는 해상도 3×8비트/프라이머리의 256가지 색상을 따릅니다.
B 00 0 배경색 : #000000, 검정
C 00 0 기본 픽셀 종횡비, 0:0
D 00 전역 색상표
⋮
30D 21 '!' 확장 블록(ASCII 제외점에 의해 도입됨)'!')
30E FF 응용프로그램 확장
30층 0B 11 응용프로그램 이름 및 검증 바이트를 포함한 블록 크기(항상 11)
310 4E 45 54 53 43 41 50 45 32 E 30 넷스케이프 2.0 8바이트 응용프로그램 이름과 3개의 검증 바이트
31B 03 3 다음 하위 블록의 바이트 수
31C 01 1 현재 데이터 하위 블록 인덱스(NETSCAPE 블록의 경우 항상 1)
31D FFFF 65535 비부호반복 횟수
31층 00 Application Extension 블록의 하위 블록 체인 끝
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) 프레임 폭 및 높이 : 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 그래픽 제어 확장
⋮ 다음 프레임에 대해 반복
에다바드 21 '!' 확장 블록(ASCII 제외점에 의해 도입됨)'!')
에다베 F9 프레임#44 그래픽 컨트롤 확장
⋮ 프레임#44의 이미지 정보 및 데이터
F48F5 3B 트레일러: 파일의 마지막 바이트로 EOF를 나타냅니다.

각 프레임의 애니메이션 지연은 100분의 1초 단위로 GCE에 지정됩니다.이미지 설명자는 전체 이미지 대신 다시 검색할 더 작은 직사각형을 정의할 수 있기 때문에 프레임이 디스플레이의 픽셀 일부만 다시 쓸 필요가 있는 경우 데이터의 일부 경제성이 가능합니다.애니메이션 GIF를 지원하지 않는 브라우저나 기타 디스플레이는 일반적으로 첫 번째 프레임만 표시합니다.

애니메이션 GIF 파일의 크기와 색상 품질은 해당 파일을 만드는 데 사용되는 응용 프로그램에 따라 크게 달라질 수 있습니다.파일 크기를 최소화하기 위한 전략에는 모든 프레임에 대해 공통 글로벌 컬러 테이블을 사용하는 것과 연속 프레임에서 커버되는 픽셀 수를 최소화하는 것이 포함됩니다(한 프레임에서 다음 프레임으로 변경되는 픽셀만 후자의 프레임에 포함되도록).보다 고급화된 기술은 손실 압축의 한 형태인 기존 LZW 사전과 더 잘 일치하도록 색상 시퀀스를 수정하는 것입니다.단순히 일련의 독립적인 프레임 이미지를 복합 애니메이션으로 포장하면 파일 크기가 커집니다.기존 GIF에서 파일 크기를 최소화하는 도구를 사용할 수 있습니다.

메타데이터

메타데이터는 주석 블록, 일반 텍스트 블록 또는 응용프로그램별 응용프로그램 확장 블록으로 GIF 파일에 저장할 수 있습니다.여러 그래픽 편집기에서 비공식 응용 프로그램 확장 블록을 사용하여 이미지를 생성하는 데 사용되는 데이터를 포함하므로 추가 편집을 위해 이미지를 복구할 수 있습니다.

이 모든 방법은 메타데이터를 하위 블록으로 분할하여 애플리케이션이 내부 구조를 알지 못한 채 메타데이터 블록을 탐색할 수 있도록 기술적으로 요구합니다.

XMP(Extensible Metadata Platform) 메타데이터 표준은 GIF 파일에 XMP 데이터를 포함시키기 위해 비공식적이지만 현재는 널리 퍼져있는 "XMP 데이터" 애플리케이션 확장 블록을 도입했습니다.[38]XMP 데이터는 NUL 문자가 없는 UTF-8을 사용하여 인코딩되므로 데이터에 0바이트가 없습니다.확장 블록은 데이터를 형식적인 서브 블록으로 분할하는 것이 아니라 데이터를 서브 블록으로 처리하는 애플리케이션을 서브 블록 체인을 종료하는 최종 0바이트로 라우팅하는 "매직 트레일러"로 종료합니다.

유니시스와 LZW 특허 집행

1977년과 1978년에 Jacob Ziv와 Abraham Lempel은 현재 LZ77과 LZ78로 통칭되는 새로운 종류의 무손실 데이터 압축 알고리즘에 대한 한 쌍의 논문을 발표했습니다.1983년에 테리 웰치는 LZ78의 빠른 변종인 LZ78을 개발했으며, 이 이름은 LZW(Lempel-Ziv-Welch)입니다.[39][40]

Welch는 1983년 6월에 LZW 방식에 대한 특허 출원을 했습니다.1985년 12월에 부여된 [41]특허 US4558302는 이후 1986년에 Burroughs Corporation과 합병하여 Unisys를 형성한 Sperry Corporation에 할당되었습니다.[39]영국, 프랑스, 독일, 이탈리아, 일본, 캐나다에서 추가 특허를 취득했습니다.

Welch의 1983년 특허에는 위 특허 외에도 다음과 같은 여러 다른 특허에 대한 인용도 포함되어 있습니다.

1984년 6월, 처음으로 LZW 기법을 공개적으로 설명한 Welch의 기사가 IEEE 잡지에 실렸습니다.[46]LZW는 대중적인 데이터 압축 기술이 되었고, 특허가 주어졌을 때, Unisys는 백 개 이상의 회사들과 라이선스 계약을 맺었습니다.[39][47]

LZW의 인기로 CompuServe는 1987년에 개발된 GIF 버전의 압축 기법으로 이를 선택하게 되었습니다.그 당시에, CompuServe는 그 특허에 대해 알지 못했습니다.[39]유니시스는 GIF 버전이 LZW 압축 기법을 사용한다는 것을 알게 되었고 1993년 1월 CompuServe와 라이선스 협상을 시작했습니다.이후의 합의는 1994년 12월 24일에 발표되었습니다.[40]Unisys는 LZW 특허를 사용하는 모든 주요 상용 온라인 정보 서비스 회사들이 합리적인 속도로 Unisys로부터 기술을 라이선스 받기를 기대하고 있지만, 온라인 서비스에서 사용하기 위한 것을 포함하여 비상업적이고 비영리적인 GIF 기반 응용 프로그램에 대한 라이선스 또는 수수료를 지불할 필요는 없을 것이라고 말했습니다.[47]

이 발표 이후, CompuServe와 Unisys에 대한 비난이 확산되었고, 많은 소프트웨어 개발자들은 GIF 사용을 중단하겠다고 위협했습니다.PNG 포맷(아래 참조)은 1995년에 의도된 대체품으로 개발되었습니다.[39][40][46]그러나 PNG 형식에 대한 웹 브라우저 및 기타 소프트웨어 제조업체의 지원을 받는 것은 어려웠고 PNG의 인기가 점차 높아졌지만 GIF를 대체하는 것은 불가능했습니다.[39]따라서 LZW 압축이 없는 GIF 변형을 개발하였습니다.예를 들어, 에릭 S를 기반으로 한 libungif 라이브러리. Raymond의 Giflib은 데이터 형식을 따르되 압축 기능을 방지하는 GIF를 생성할 수 있으므로 Unisys LZW 특허 사용을 피할 수 있습니다.[48]2001년 Dobb 박사의 기사는 특허를 침해하지 않고 LZW 호환 인코딩을 달성하는 방법을 설명했습니다.[49]

1999년 8월, 유니시스는 라이선스 관행의 세부 사항을 변경하여 특정한 비상업적이고 사적인 웹 사이트의 소유자가 5,000달러 또는 7,500달러의 일회성 라이선스 비용을 지불하면 라이선스를 획득할 수 있는 옵션을 발표했습니다.[50]이러한 라이센스는 웹 사이트 소유자나 GIF를 생성하기 위해 라이센스가 부여된 소프트웨어를 사용한 다른 GIF 사용자에게는 필요하지 않았습니다.그럼에도 불구하고, 유니시스는 그들의 웹사이트에서 GIF를 사용한 것에 대해 5천 달러의 요금이 부과되거나 고소될 것이라고 믿는 사용자들로부터 수천 건의 온라인 공격과 욕설 이메일을 받았습니다.[51]수백 개의 비영리 단체, 학교 및 정부에 무료 라이센스를 제공했음에도 불구하고 Unisys는 좋은 홍보를 전혀 할 수 없었고 1999년에 "모든 GIF를 불태우세요" 캠페인을 시작한 프로그래밍 자유 연맹과 같은 개인 및 단체로부터 계속 비난을 받았습니다.[52][53]

미국 LZW 특허는 2003년 6월 20일에 만료되었습니다.[54]영국, 프랑스, 독일, 이탈리아의 상대 특허는 2004년 6월 18일에 만료되었고, 일본 특허는 2004년 6월 20일에 만료되었고, 캐나다 특허는 2004년 7월 7일에 만료되었습니다.[54]따라서 Unisys는 LZW 기법의 개선과 관련된 추가 특허 및 특허 출원을 가지고 있지만,[54] LZW 자체(그리고 결과적으로 GIF)는 2004년 7월부터 자유롭게 사용할 수 있습니다.[55]

대안

PNG

휴대용 네트워크 그래픽스(Portable Network Graphics, PNG)는 유니시스의 LZW 압축 기술에 대한 특허 침해를 방지하기 위해 GIF를 대체하기 위해 개발되었습니다.[39]PNG는 GIF보다 더 나은 압축과 더 많은 기능을 제공하며,[56] 애니메이션만이 유일한 중요한 예외입니다.PNG는 진색 영상 및 알파 투명도가 필요한 경우 GIF보다 더 적합합니다.

PNG 포맷 지원은 더디게 이루어졌지만, 새로운 웹 브라우저는 PNG를 지원합니다.이전 버전의 Internet Explorer(인터넷 익스플로러)는 PNG의 일부 기능을 지원하지는 않습니다. 6 이전 버전에서는 Microsoft 전용 HTML 확장을 사용하지 않는 알파 채널 투명성을 지원하지 않습니다.[57]버전 8 이전에는 PNG 이미지의 감마 보정이 지원되지 않았으며 이전 버전에서는 이러한 이미지의 표시에 잘못된 틴트가 있을 수 있습니다.[58]

동일한 8비트(또는 그 이하) 이미지 데이터의 경우, PNG 인코딩에서 사용되는 보다 효율적인 압축 기술로 인해 PNG 파일은 일반적으로 동등한 GIF보다 작습니다.[59]GIF의 완전한 지원은 주로 복잡한 캔버스 구조에 의해 복잡하지만, 이것이 컴팩트한 애니메이션 기능을 가능하게 합니다.

애니메이션 형식

동영상은 GIF가 웹에서 일반적으로 사용하는 방식을 통해 제시하는 많은 문제를 해결합니다.파일 크기가 대폭 줄어들고, 8비트 색상 제한을 능가할 수 있으며 코덱을 통한 프레임 처리 및 압축이 개선됩니다.웹 브라우저에서 GIF 형식에 대한 사실상 보편적인 지원과 HTML 표준의 비디오에 대한 공식 지원 부족으로 인해 짧은 비디오와 같은 파일을 웹에 표시하기 위한 목적으로 GIF가 두각을 나타내게 되었습니다.

  • MNG("Multiple-image Network Graphics")는 원래 애니메이션을 위한 PNG 기반 솔루션으로 개발되었습니다.MNG는 2001년 버전 1.0에 도달했지만 지원하는 애플리케이션은 거의 없습니다.
  • APNG ("애니메이션 포터블 네트워크 그래픽스")는 2006년 모질라에 의해 제안되었습니다.APNG는 MNG 형식을 대체하는 PNG 형식의 확장입니다.APNG는 2019년 현재 대부분의 브라우저에서 지원됩니다.[60]APNG는 MNG와는 달리 애니메이션 청크를 이해할 수 없는 디코더에서 하위 호환성을 유지하면서 PNG 파일을 애니메이션화할 수 있는 기능을 제공합니다.오래된 디코더는 애니메이션의 첫 번째 프레임을 간단히 렌더링합니다.
PNG 그룹은 2007년 4월 20일 공식적으로 APNG를 공식적으로 거부했습니다.[61]
PNG를 기반으로 한 단순한 애니메이션 그래픽 포맷에 대한 여러 후속 제안들이 있었습니다.[62]그럼에도 불구하고 APNG는 여전히 Mozilla에서 개발 중이며 Firefox 3.0에서[63][64] 지원되는 반면 MNG 지원은 중단되었습니다.[65][66]APNG는 현재 Chrome(버전 59.0 이후), Opera, Firefox, Edge를 포함한 모든 주요 웹 브라우저에서 지원됩니다.
  • 내장된 Adobe Flash 개체 및
  • MPEG 파일은 간단한 비디오를 표시하기 위해 일부 웹 사이트에서 사용되었지만 추가 브라우저 플러그인을 사용해야 했습니다.
  • WebM과 WebP는 개발 중이며 일부 웹 브라우저에서 지원됩니다.[67]
  • 웹 애니메이션의 다른 옵션으로는 AJAX를 사용하여 개별 프레임을 제공하는 것, 또는
  • 자바스크립트 또는 SMIL (Synchronized Multimedia Integration Language)[citation needed]을 사용하여 SVG (Scalable vector graphics) 이미지를 애니메이션화하는 방법.
  • HTML5 동영상에 대한 광범위한 지원이 도입됨에 따라 (<video>대부분의 웹 브라우저에서 일부 웹 사이트는 자바스크립트 함수에 의해 생성된 비디오 태그의 루프 버전을 사용합니다.이렇게 하면 GIF처럼 보이지만 압축 비디오의 크기와 속도의 장점이 있습니다.
주목할 만한 예로는 Gfycat과 Imgur 및 GIFV 메타포맷이 있으며, 이는 실제로 루프된 MP4 또는 WebM 압축 비디오를 재생하는 비디오 태그입니다.[68]
  • HEIF("High Efficiency Image File Format")는 2015년에 완성된 이미지 파일 형식으로, HEVC 비디오 형식을 기반으로 하는 이산 코사인 변환(DCT) 손실 압축 알고리즘을 사용하며 JPEG 이미지 형식과 관련이 있습니다.JPEG와 달리 HEIF는 애니메이션을 지원합니다.[69]
DCT 압축이 부족한 GIF 형식에 비해 HEIF는 훨씬 더 효율적인 압축을 허용합니다.HEIF는 더 많은 정보를 저장하고 동등한 GIF 크기의 작은 부분으로 고품질 애니메이션 이미지를 생성합니다.[70]
  • AV1 비디오 코덱 또는 AVIF는 비디오 또는 시퀀스 이미지로도 사용할 수 있습니다.

사용하다

2014년 4월, 4chan은 크기가 3MB 이하이고 길이가 2분인 무음 WebM 비디오에 대한 지원을 추가했고,[72][73] 2014년 10월, Imgur는 사이트에 업로드된 GIF 파일을 비디오로 변환하고 HTML 플레이어에 대한 링크에 실제 파일의 모양을 제공하기 시작했습니다..gifv내선[74][75]

2016년 1월, 텔레그램은 모든 GIF를 MPEG-4 비디오로 다시 인코딩하기 시작했는데, 이 비디오는 동일한 화질을 위해 최대 95% 더 적은 디스크 공간이 필요합니다.[76]

참고 항목

참고문헌

  1. ^ a b c "Graphics Interchange Format, Version 87a". W3C. 15 June 1987. Archived from the original on 22 December 2018. Retrieved 13 October 2012.
  2. ^ a b c "Graphics Interchange Format, Version 89a". W3C. 31 July 1990. Archived from the original on 22 December 2018. Retrieved 6 March 2009.
  3. ^ "Online Art". Compute!'s Apple Applications. December 1987. p. 10. Retrieved 14 September 2016.
  4. ^ Holdener III, Anthony (2008). Ajax: The Definitive Guide: Interactive Applications for the Web. O'Reilly Media. ISBN 978-0596528386.
  5. ^ Furht, Borko (2008). Encyclopedia of Multimedia. Springer. ISBN 978-0387747248.
  6. ^ McHugh, Molly (29 May 2015). "You Can Finally, Actually, Really, Truly Post GIFs on Facebook". Wired. wired.com. Archived from the original on 30 May 2015. Retrieved 29 May 2015.
  7. ^ Perez, Sarah (29 May 2015). "Facebook Confirms It Will Officially Support GIFs". techcrunch.com. Archived from the original on 30 May 2015. Retrieved 29 May 2015.
  8. ^ "Introducing GIF Stickers". Instagram. 23 January 2018. Archived from the original on 12 December 2019. Retrieved 19 September 2019.
  9. ^ "Oxford Dictionaries USA Word of the Year 2012". OxfordWords blog. Oxford American Dictionaries. 13 November 2012. Archived from the original on 3 August 2014. Retrieved 1 May 2013.
  10. ^ Flood, Alison (27 April 2013). "Gif is America's word of the year? Now that's what I call an omnishambles". Books blog. The Guardian. London. Archived from the original on 1 December 2016. Retrieved 1 May 2013.
  11. ^ Olsen, Steve. "The GIF Pronunciation Page". Archived from the original on 25 February 2009. Retrieved 6 March 2009.
  12. ^ a b c "Gif's inventor says ignore dictionaries and say 'Jif'". BBC News. 22 May 2013. Archived from the original on 27 June 2018. Retrieved 22 May 2013.
  13. ^ Buck, Stephanie (21 October 2014). "70 percent of people worldwide pronounce GIF with a hard g". Mashable. Archived from the original on 23 December 2021. Retrieved 24 December 2021.
  14. ^ van der Meulen, Marten (22 May 2019). "Obama, SCUBA or gift?: Authority and argumentation in online discussion on the pronunciation of GIF". English Today. 36 (1): 45–50. Archived from the original on 24 May 2022. Retrieved 22 May 2022.
  15. ^ "GIF". The American Heritage Abbreviations Dictionary, Third Edition. Houghton Mifflin Company. 2005. Archived from the original on 3 September 2011. Retrieved 15 April 2007.
  16. ^ "GIF". The Cambridge Dictionary of American English. Cambridge University Press. Archived from the original on 27 February 2014. Retrieved 19 February 2014.
  17. ^ "Gif - Definition from the Merriam-Webster Dictionary". Merriam-Webster Dictionary. Merriam-Webster, Incorporated. Archived from the original on 22 October 2013. Retrieved 6 June 2013.
  18. ^ "GIF". Oxford Dictionaries Online. Oxford University Press. Archived from the original on 12 October 2014. Retrieved 7 October 2014.
  19. ^ "gif noun - Definition, pictures, pronunciation and usage notes Oxford Advanced Learner's Dictionary". Oxford Learner's Dictionaries. Archived from the original on 24 November 2020. Retrieved 6 February 2021.
  20. ^ "GIF Definition of GIF by Oxford Dictionary". Lexico. Archived from the original on 13 February 2021. Retrieved 6 February 2021.
  21. ^ Stevenson, Angus, ed. (2010). Oxford Dictionary of English (3rd ed.). Oxford University Press. ISBN 9780199571123. OCLC 729551189. Archived from the original on 23 August 2022. Retrieved 6 February 2021.
  22. ^ The New Oxford American Dictionary (2nd ed.). Oxford University Press. 2005. p. 711.
  23. ^ The New Oxford American Dictionary (3rd ed.). 2012. (Macintosh 내장 사전의 일부).
  24. ^ O'Leary, Amy (21 May 2013). "An Honor for the Creator of the GIF". The New York Times. Archived from the original on 22 May 2013. Retrieved 22 May 2013.
  25. ^ a b Rothberg, Daniel (4 December 2013). "'Jeopardy' wades into 'GIF' pronunciation battle". Los Angeles Times. Archived from the original on 6 December 2013. Retrieved 4 December 2013.
  26. ^ O'Leary, Amy (23 May 2013). "Battle Over 'GIF' Pronunciation Erupts". The New York Times. Archived from the original on 16 December 2013. Retrieved 5 December 2013.
  27. ^ Valinsky, Jordan (February 25, 2020). "Jif settles the great debate with a GIF peanut butter jar". CNN. Archived from the original on February 25, 2020. Retrieved February 25, 2020.
  28. ^ 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. pp. 297–301. doi:10.1109/ICDCSyst.2012.6188724. ISBN 9781457715457. Archived from the original on 2 July 2017. Retrieved 11 March 2015.
  29. ^ S. Chin; D. Iverson; O. Campesato; P. Trani (2011). Pro Android Flash (PDF). New York: Apress. p. 350. ISBN 9781430232315. Archived (PDF) from the original on 2 April 2015. Retrieved 11 March 2015.
  30. ^ Bakhshi, Saeideh; Shamma, David A.; Kennedy, Lyndon; Song, Yale; de Juan, Paloma; Kaye, Joseph "Jofish" (7 May 2016). "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. S2CID 7417853. Retrieved 17 August 2022.
  31. ^ 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 (1): 47–62. doi:10.1080/22041451.2016.1155332. S2CID 148538216. Retrieved 17 August 2022.
  32. ^ a b c Andreas Kleinert (2007). "GIF 24 Bit (truecolor) extensions". Archived from the original on 16 March 2012. Retrieved 23 March 2012.
  33. ^ a b Philip Howard. "True-Color GIF Example". Archived from the original on 22 February 2015. Retrieved 23 March 2012.
  34. ^ "Nullsleep - Jeremiah Johnson - Animated GIF Minimum Frame Delay Browser Compatibility Study". Archived from the original on 10 October 2014. Retrieved 26 May 2015.
  35. ^ "They're different! How to match the animation rate of gif files accross [sic] browsers". Developer's Blog. 14 February 2012. Archived from the original on 1 February 2017. Retrieved 15 June 2017.
  36. ^ Royal Frazier. "All About GIF89a". Archived from the original on 18 April 1999. Retrieved 7 January 2013.
  37. ^ Scott Walter (1996). Web Scripting Secret Weapons. Que Publishing. ISBN 0-7897-0947-3.
  38. ^ "XMP Specification Part 3: Storage in Files" (PDF). Adobe. 2016. pp. 11–12. Archived (PDF) from the original on 25 February 2018. Retrieved 16 August 2018.
  39. ^ a b c d e f g Greg Roelofs. "History of the Portable Network Graphics (PNG) Format". Archived from the original on 7 March 2012. Retrieved 23 March 2012.
  40. ^ a b c Stuart Caie. "Sad day... GIF patent dead at 20". Archived from the original on 10 February 2012. Retrieved 23 March 2012.
  41. ^ US 4558302, Welch, Terry A., Sperry Corp에 할당된 1985-12-10 출판.
  42. ^ JP 특허 S5719857A, 카나츠, 지윤, "데이터 압축 저장 장치", 1982-02-02 공개, 일본 전기 회사에 할당
  43. ^ JP 특허 S57101937A, 카나츠, 지윤, "데이터 저장 장치", 1986-20-24 공개, 일본 전기 회사에 할당
  44. ^ DE 특허 3118676, Eckhart, Heinz Karl, "Verfahren zur Kompression redundanter Folgen serieller Datenelemente [직렬 데이터 요소의 리던던트 시퀀스 압축 방법]", 1982-12-02 공개
  45. ^ 미국 특허 4,558,302
  46. ^ a b "The GIF Controversy: A Software Developer's Perspective". 27 January 1995. Archived from the original on 23 August 2016. Retrieved 26 May 2015.
  47. ^ a b – "Unisys Clarifies Policy Regarding Patent Use in On-Line Service Offerings". Archived from the original on 7 February 2007. 프로그래밍 프리덤 리그별로 아카이브됨
  48. ^ "Libungif". Archived from the original on 13 April 2015. Retrieved 26 May 2015.
  49. ^ Cargill, Tom (1 October 2001). "Replacing a Dictionary with a Square Root". Dr. Dobb's Journal. Archived from the original on 28 June 2017. Retrieved 20 January 2017.
  50. ^ – "LZW Software and Patent Information". Archived from the original on 8 June 2009. Retrieved 31 January 2007. 1999년 9월 2일 해명
  51. ^ Unisys가 GIF 사용을 위한 웹마스터(대부분)를 고소하지 않음 2017년 5월 10일 Wayback Machine에서 보관 – 논란에 대한 Slashdot 조사
  52. ^ "Burn All GIFs Day". Archived from the original on 13 October 1999.
  53. ^ Burn All GIF 2007년 2월 3일 Wayback Machine에서 보관 – 프로그래밍 자유 연맹의 프로젝트 (최신 버전)
  54. ^ a b c "License Information on GIF and Other LZW-based Technologies". Archived from the original on 2 June 2009. Retrieved 26 April 2005.
  55. ^ "Why There Are No GIF Files on GNU Web Pages". Free Software Foundation. Archived from the original on 19 May 2012. Retrieved 19 May 2012.
  56. ^ "PNG versus GIF Compression". 31 March 2007. Archived from the original on 15 July 2009. Retrieved 8 June 2009.
  57. ^ "AlphaImageLoader Filter". Microsoft. 4 September 2012. Archived from the original on 3 October 2014. Retrieved 26 May 2015.
  58. ^ "What's New in Internet Explorer 7". MSDN. Archived from the original on 1 March 2009. Retrieved 6 March 2009.
  59. ^ "PNG Image File Format". Archived from the original on 14 June 2009. Retrieved 8 June 2009.
  60. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Archived from the original on 19 February 2018. Retrieved 10 April 2020.
  61. ^ "VOTE FAILED: APNG 20070405a". SourceForge mailing list. 20 April 2007. Archived from the original on 13 February 2013. Retrieved 14 July 2013.
  62. ^ "Discussion for a simple "animated" PNG format". Archived from the original on 26 February 2009. Retrieved 12 July 2011.
  63. ^ "APNG Specification". Archived from the original on 5 July 2010. Retrieved 26 May 2015.
  64. ^ "Mozilla Labs » Blog Archive » Better animations in Firefox 3". 13 August 2007. Archived from the original on 7 March 2016. Retrieved 3 February 2016.
  65. ^ "195280 – Removal of MNG/JNG support". Archived from the original on 25 February 2021. Retrieved 26 May 2015.
  66. ^ "18574 – (mng) restore support for MNG animation format and JNG image format". Archived from the original on 17 March 2021. Retrieved 26 May 2015.
  67. ^ "Chromium Blog: Chrome 32 Beta: Animated WebP images and faster Chrome for Android touch input". Blog.chromium.org. 21 November 2013. Archived from the original on 17 July 2018. Retrieved 1 February 2014.
  68. ^ "Introducing GIFV - Imgur Blog". imgur.com. 9 October 2014. Archived from the original on 14 December 2014. Retrieved 14 December 2014.
  69. ^ Thomson, Gavin; Shah, Athar (2017). "Introducing HEIF and HEVC" (PDF). Apple Inc. Archived (PDF) from the original on 19 January 2020. Retrieved 5 August 2019.
  70. ^ "HEIF Comparison - High Efficiency Image File Format". Nokia Technologies. Archived from the original on 25 July 2019. Retrieved 5 August 2019.
  71. ^ "#3271 (Allow using additional pixel formats with libvpx-vp9) – FFmpeg". trac.ffmpeg.org. Archived from the original on 16 June 2020. Retrieved 10 April 2020.
  72. ^ Dewey, Caitlin. "Meet the technology that could make GIFs obsolete". The Washington Post. Archived from the original on 11 May 2015. Retrieved 4 February 2015.
  73. ^ "WebM support on 4chan". 4chan Blog. Archived from the original on 6 April 2014. Retrieved 4 February 2015.
  74. ^ "Introducing GIFV". Imgur. 9 August 2014. Archived from the original on 5 May 2020. Retrieved 21 July 2016.
  75. ^ Allan, Patrick (9 October 2014). "Imgur Revamps GIFs for Faster Speeds and Higher Quality with GIFV". Lifehacker. Archived from the original on 3 February 2015. Retrieved 4 February 2015.
  76. ^ "GIF Revolution". Official Telegram Blog. 4 January 2016. Archived from the original on 10 January 2016. Retrieved 4 January 2016.

외부 링크

위키미디어 커먼즈에는 GIF 파일 형식과 관련된 미디어가 있습니다.