GIF

GIF
回転する地球儀のアニメーションGIF
ファイル名拡張子
.gif
インターネットメディアの種類
image/gif
タイプコードGIFf
統一型識別子（UTI）com.compuserve.gif
魔法の数字GIF87a/GIF89a
開発者コンピュサーブ
初回リリース1987年6月15日[ 1 ] （1987年6月15日）
最新リリース
89a 1989 [ 2 ] （1989年）
フォーマットの種類ロスレスビットマップ画像形式
Webサイトwww .w3 .org /グラフィックス/GIF /spec-gif89a .txt

グラフィックス・インターチェンジ・フォーマット（GIF、/ ɡɪ f / GHIFまたは/ dʒɪ f / JIF）は、アメリカのコンピュータ科学者スティーブ・ウィルハイトが率いるオンラインサービスプロバイダーCompuServeのチームによって開発され、1987年6月15日にリリースされたビットマップ画像フォーマットである。[ 1 ]

このフォーマットは1ピクセルあたり最大8ビットを格納できるため、1つの画像で24ビットRGBカラースペースから最大256色のパレットを参照できます。また、1つのファイルで複数の画像を表現できるため、アニメーションに使用でき、フレームごとに最大256色の個別のパレットを使用できます。これらのパレット制限により、GIFはカラー写真やグラデーションのある画像の再現には適していませんが、単色の領域を持つグラフィックやロゴなどのシンプルな画像には適しています。

GIF画像は、画質を損なわずにファイルサイズを削減するために、Lempel-Ziv-Welch（LZW）ロスレスデータ圧縮技術を用いて圧縮されています。かつては、その幅広い実装とアプリケーションやオペレーティングシステム間の移植性から、ワールドワイドウェブで広く使用されていましたが、容量と画質の問題から使用頻度は低下し、静止画像にはPNG 、動画にはMP4といった新しい形式に置き換えられることが多くなりました。この文脈では、元のファイル形式とは無関係であるにもかかわらず、短い動画クリップが「GIF」と呼ばれることがあります。[ 3 ]

歴史

「工事中」アニメーション GIF は、90 年代後半から 2000 年代前半にかけて、未完成の Web サイトによく見られました。
このようなアニメーション GIF は、1990 年代後半から 2000 年代初頭にかけて、個人の Web サイトの装飾としてよく使われていました。

CompuServeは1987年6月15日、ファイルダウンロードエリアにカラー画像フォーマットを提供するためにGIFを導入しました。これは、それまで白黒のみだったランレングス符号化フォーマットに取って代わりました。GIFが普及したのは、Lempel-Ziv-Welchデータ圧縮方式を採用していたためです。これはPCXやMacPaintで使用されていたランレングス符号化方式よりも効率が良かったため、低速モデムでもかなり大きな画像でもかなり速くダウンロードできました。

GIFのオリジナルバージョンは87aと呼ばれていました。[ 1 ]このバージョンでは既にストリーム内で複数の画像をサポートしていました。

1989年、CompuServeは89aと呼ばれる拡張バージョンをリリースしました。[ 2 ]このバージョンでは以下の機能が追加されました。

  • アニメーション遅延のサポート
  • 透明な背景色
  • アプリケーション固有のメタデータの保存
  • テキストラベルをテキストとして表示できるようにする（グラフィックデータに埋め込むのではなく）。ただし、この機能はほとんど使用されていません。最近のブラウザはこれをサポートしておらず、フォントやスタイルを制御できる範囲も限られています。

2 つのバージョンは、ファイルの最初の 6バイト(「マジック ナンバー」または署名) を調べることで区別できます。ASCII として解釈すると、それぞれ「GIF87a」または「GIF89a」と表示されます。

CompuServeは、多くのコンピュータ向けにダウンロード可能な変換ユーティリティを提供することで、GIFの普及を促進しました。例えば、1987年12月までに、Apple IIGSユーザーはAtari STやCommodore 64で作成された画像を閲覧できるようになりました。[ 4 ] GIFは、ウェブサイトで一般的に使用された最初の2つの画像形式のうちの1つであり、もう1つは白黒のXBMでした。[ 5 ]

1995 年 9 月、 Netscape Navigator 2.0にアニメーション GIF をループする機能が追加されました。

GIFはCompuServeによって開発されましたが、1985年にUnisysが特許を取得したLempel-Ziv-Welch（LZW）ロスレスデータ圧縮アルゴリズムを採用していました。1994年にUnisysとCompuServeの間でライセンス契約をめぐる論争が起こり、 Portable Network Graphics （PNG）規格の開発が促進されました。2004年、GIFに使用されていた独自の圧縮技術に関するすべての特許が失効しました。

複数の画像を制御データとともに 1 つのファイルに保存する機能は、単純なアニメーションを作成するために Web 上で広く使用されています。

オプションのインターレース機能は、画像の走査線を不規則に保存することで、部分的にダウンロードされた画像でもある程度認識できるようにするもので、ユーザーが必要なものでない場合はダウンロードを中止できるため、GIFの人気にも貢献しました。 [ 6 ]

2015年5月にFacebookはGIFのサポートを追加しました。[ 7 ] [ 8 ] 2014年にはTwitterも、 2018年にはInstagramもGIFのサポートを追加しました。 [ 9 ]

2016年、インターネットアーカイブはジオシティーズアーカイブからGIFの検索可能なライブラリを公開した。[ 10 ] [ 11 ]

用語

GIFという単語は、多くの辞書の最新版に名詞として掲載されています。2012年には、オックスフォード大学出版局のアメリカ支部がGIFを動詞としても認め、「GIFファイルを作成する」という意味で、「GIFは夏季オリンピックのシーンを共有するのに最適な媒体だった」という表現が用いられています。同出版局の辞書編集者は、GIFが「研究やジャーナリズムを含む本格的な用途を持つツール」へと進化したとして、GIFを今年の言葉に選出しました。[ 12 ] [ 13 ]

発音

2013 年にホワイト ハウスのTumblrアカウントが開始されたことを告知するユーモラスなインフォグラフィックでは、GIF をgの音を強く発音するよう勧めています。

GIFの最初の文字の発音は1990年代から議論されてきました。英語で最も一般的な発音は/ dʒɪf /です。ⓘ（ginのように軟音のg）と/ ɡɪf /ⓘ （ giftのように硬いgで発音）と、文字G音素。このフォーマットの作成者は、頭字語GIF を/ dʒ ɪ f / （軟音のgでとウィルハイトは、この発音は意図的にアメリカのピーナッツバターブランドJif を、CompuServe の従業員はよく「こだわりのある開発者は GIF を選ぶ」と冗談を言っていました。これは Jif のテレビコマーシャルのパロディーです。 [ 14 ]しかし、この単語は広く/ ɡ ɪ f / （硬音のgで発音）さ、 [ 15 ]世論調査では、この硬音のg方が一般的であることが示されています。 [ 16 ] [ 17 ]

Dictionary.com [ 18 ]では両方の発音が引用されており、 / dʒ ɪ f /が主な発音である一方、 Cambridge Dictionary of American English [ 19 ]では硬いgの発音のみが示されている。Merriam -Webster's Collegiate Dictionary [ 20 ]とOxford Dictionariesでは両方の発音が引用されているが、硬いg が最初に置かれ、 / ɡ ɪ f、dʒ ɪ f /となっている。 [ 21 ] [ 22 ] [ 23 ] [ 24 ] New Oxford American Dictionary では第2版では/ dʒ ɪ f /のみが掲載されていたが[ 25 ] 、第3版では/ dʒ ɪ f、ɡ ɪ f /に更新された。 [ 26 ]

発音をめぐる意見の相違は、インターネット上で白熱した議論を巻き起こした。2013年のウェビー賞授賞式で生涯功労賞を受賞した際、ウィルハイト氏は公に硬いgの発音を否定した。[ 15 ] [ 27 ] [ 28 ]彼のスピーチはTwitterで1万7000件以上の投稿と数十のニュース記事を生み出した。[ 29 ]ホワイトハウス[ 15 ]とテレビ番組「Jeopardy!」も2013年にこの議論に加わった。[ 28 ] 2020年2月、 Jifブランドの所有者であるJM Smucker Companyは、アニメーション画像データベースおよび検索エンジンのGiphyと提携し、「Jif vs. GIF」（ハッシュタグ#JIFvsGIF）の限定版ピーナッツバター瓶を発売した。この瓶のラベルには、軟らかいgの発音はピーナッツバターのみを指し、GIFは硬いgの発音でのみ発音するとユーモラスに宣言されていた。[ 30 ]

使用法

GIFは、ロゴなど、色数が限られ、エッジのはっきりした線画に適しています。これは、均一な色で平坦な領域と明確なエッジを優先するロスレス圧縮形式の利点を活用しています。[ 31 ]また、ゲーム用の低色スプライトデータの保存にも使用できます。[ 32 ] GIFは、短いアニメーションや低解像度のビデオクリップ、または言葉の代わりに感情や気持ちを伝えるオンラインメッセージングのリアクションに使用できます。Tumblr 、[ 33 ] Facebook、Twitterなどのソーシャルメディアプラットフォームで人気があります。[ 34 ]

ファイル形式

概念的には、GIFファイルは、0個以上の「画像」で構成された固定サイズのグラフィック領域（「論理画面」）を記​​述します。多くのGIFファイルは、論理画面全体を占める単一の画像で構成されます。また、論理画面を複数のサブ画像に分割するファイルもあります。これらの画像は、アニメーションGIFファイルにおいてアニメーションフレームとして機能する場合もありますが、この場合も論理画面全体を占める必要はありません。

GIFファイルは、バージョンを示す固定長のヘッダー（「GIF87a」または「GIF89a」）で始まり、その後に論理スクリーンのピクセル寸法やその他の特性を示す固定長の論理スクリーン記述子（LSD）が続きます。スクリーン記述子は、グローバルカラーテーブル（GCT）の有無とサイズも指定できます。GCTが存在する場合は、GCTが次に続きます。

その後、ファイルは次のタイプのセグメントに分割され、各セグメントは 1 バイトのセンチネルで始まります。

  • 画像（ASCIIコンマ0x2Cで始まる','）
  • 拡張ブロック（ASCII感嘆符0x21で始まる'!'）
  • トレーラー (値 0x3B の 1 バイト、ASCII セミコロン';')。ファイルの最後のバイトになります。

画像は固定長の画像記述子で始まります。この記述子は、ローカルカラーテーブル（存在する場合、次に続く）の有無とサイズを指定します。画像データは、エンコードされていないシンボルのビット幅を示す1バイト（2色画像であっても少なくとも2ビット幅である必要があります）に続き、LZWエンコードされたデータを含む一連のサブブロックが続きます。

拡張ブロック（87a仕様で既に定義されているメカニズムを介して87a定義を「拡張」するブロック）は、センチネル、拡張の種類を指定する追加バイト、および拡張データを含む一連のサブブロックで構成されます。画像を変更する拡張ブロック（オプションのアニメーション遅延時間やオプションの透明背景色を指定するグラフィックコントロール拡張など）は、参照する画像を含むセグメントの直前に配置する必要があります。

各サブブロックは、そのサブブロック内の後続のデータバイト数（1～255）を示すバイトで始まります。一連のサブブロックは、空のサブブロック（0バイト）で終了します。

この構造により、すべての部分が理解できない場合でもファイルを解析できます。87aでマークされたGIFには拡張ブロックが含まれる場合があります。これは、デコーダーが理解できない拡張機能に含まれる機能を除いたファイルを読み取って表示できるようにするためです。

ファイル形式の詳細はGIF仕様に記載されています。[ 2 ]

パレット

これは、Web セーフ パレットで保存され、Floyd–Steinberg方式でディザリングされたGIF 画像の例です。このような画像で使用できる色が比較的少ないため、画像のコントラストと彩度が著しく低下しています。

GIFはパレットベースの画像形式です。各フレームには、24ビットRGBカラースペースから選択された最大256色が含まれます。これらの色はテーブル（パレット）で定義され、各ピクセルはこのパレットのインデックスを参照します。元々、この方式は色数のサポートが限られているハードウェアに適していましたが、現在では、シンプルなグラフィック、線画、ロゴ、基本的なアニメーションなどに最適な形式となっています。より多くの色を近似するために、ディザリング技術が使用されることもありますが、画像の鮮明度が低下したり、ファイルサイズが大きくなったりすることがあります。

GIFファイルにはグローバルカラーテーブルが含まれ、各フレームにはローカルカラーテーブルが含まれる場合があります。スペースを節約するため、仕様では2 n色のカラーテーブル（ nは1から8までの任意の値）が許容されています。ほとんどのグラフィックアプリケーションは、これらのテーブルサイズのGIF画像を読み込んで表示できますが、画像作成時にすべてのサイズをサポートしていないものも少なくありません。2色、16色、256色のカラーテーブルが広くサポートされています。

GIF は透明性をサポートしており、1 つの色を透明としてマークして、背景やレイヤー化された効果を透かして表示することができます。

真の色

GIFはトゥルーカラー画像に使用されることはほとんどありませんが、実際にはそうすることは可能です。[ 35 ] [ 36 ] GIF画像は複数の画像ブロックを含むことができ、各ブロックは独自の256色パレットを持つことができ、ブロックを並べて完全な画像を作成することができます。また、GIF89a仕様では「透明」色の概念が導入され、各画像ブロックは255色の可視色と1色の透明色からなる独自のパレットを持つことができます。画像ブロックを重ね合わせ、各レイヤーの可視部分を上のレイヤーの透明部分を通して見せることで、完全な画像を作成できます。

通常の256色制限を超える色数を表示する技術を示すアニメーションGIF

フルカラー画像をGIF形式でレンダリングするには、元の画像を255色または256色以下の小さな領域に分割する必要があります。各領域は、それぞれ独自のローカルパレットを持つ個別の画像ブロックとして保存され、画像ブロックを並べて表示する（タイル表示または半透明の画像ブロックを重ねる）ことで、完全なフルカラー画像が表示されます。例えば、画像を16×16ピクセルのタイル（合計256ピクセル）に分割すると、タイルのローカルパレットの制限である256色を超える色は含まれなくなります。ただし、より大きなタイルを使用することで、類似した色が結合され、色情報が多少失われる場合があります。[ 35 ]

各画像ブロックは独自のローカルカラーテーブルを持つことができるため、多数の画像ブロックを含むGIFファイルは非常に大きくなり、フルカラーGIFの有用性が制限されます。[ 36 ]さらに、すべてのGIFレンダリングプログラムがタイル画像やレイヤー画像を正しく処理できるわけではありません。多くのレンダリングプログラムはタイルやレイヤーをアニメーションフレームとして解釈し、アニメーションとして順番に表示します。[ 35 ]ほとんどのウェブブラウザは0.1秒以上の遅延時間でフレームを自動的に表示します。[ 37 ] [ 38 ]

GIFファイルの例

Microsoft ペイントは、小さな白黒画像を次の GIF ファイル（拡大表示）として保存します。ペイントは GIF を最大限に活用していません。カラーテーブルが不必要に大きく（使用される 2 色ではなく 256 色を格納）、シンボルの幅も大きいため、この GIF ファイルは 15 ピクセルの画像を効率的に表現できていません。グラフィック コントロール拡張ブロックはカラー インデックス 16（16 進数で 10）を透明として宣言していますが、このインデックスは画像では使用されていません。画像データに表示されるカラー インデックスは 10 進数の 40 と 255 のみで、グローバル カラー テーブルではそれぞれ白と黒にマッピングされます。

サンプル画像（拡大）、実寸大 幅3ピクセル×高さ5ピクセル

次の表の 16 進数は、形式仕様で規定されているように、 リトルエンディアンバイト順になっています。

GIF画像の値の例の表
バイト番号（16進数）16進数テキストまたは値意味
047 49 46 38 39 61GIF89aヘッダ
論理画面記述子
603 003論理画面幅
805 005論理的な画面の高さ
あF7 GCTは解像度3 × 8ビット/プライマリの256色に続き、最下位3ビットはビット深度から1を引いた値を表し、最上位の真のビットはGCTが存在することを意味する。
B000背景色: インデックス #0; #000000 黒
C000デフォルトのピクセルアスペクト比、0:0
グローバルカラーテーブル
D00 00 00
R（赤）G（緑）B（青）
000
グローバルカラーテーブル、カラー#0: #000000、黒
この例のバイトD hから 30C hは256色のパレットを定義します。サンプル画像で使用されている白黒のインデックスはそれぞれ28 hと FF hです。
1080 00 00
R（赤）G（緑）B（青）
12800
グローバルカラーテーブル、カラー#1: 透明ビット、画像では使用されません
.........グローバルカラーテーブルは30Aまで拡張されます
30AFF FF FF
R（赤）G（緑）B（青）
255255255
グローバルカラーテーブル、色 #255: #ffffff、白
グラフィックコントロール拡張
30D21'!'拡張ブロック（ASCII感嘆符で始まる'!'）
30EF9グラフィックコントロール拡張機能
30階044GCEデータの量、4バイト
31001透明な背景色。これはビットフィールドであり、最下位ビットは透明度を表します。
31100 00アニメーションの遅延（100分の1秒単位）;使用されません
3131016GCTにおける透明ピクセルの色番号
31400GCEブロックの終了
画像記述子
3152C','画像記述子（ASCIIコンマ0x2Cで導入','）
31600 00 00 00（0, 0）論理画面内の画像の北西隅の位置
31A03 00 05 00（3、5）画像の幅と高さ（ピクセル単位）
31E000ローカルカラーテーブルビット、0はなしを意味する
画像データ
31階088イメージの開始、LZW 最小コードサイズ
3200B11最初のデータサブブロックの開始。これに続く11バイトのエンコードされたデータを指定します。
32100 51 FC 1B 28 70 A0 C1 83 01 01<画像データ>11バイトの画像データ、フィールド320を参照
32℃000終了データサブブロック。後続のデータバイトがないことを示します（画像の終わり）。
トレーラー
32D3B';'ファイル終了ブロックインジケータ（ASCIIセミコロン';'）

画像コーディング

画像のピクセルデータは、左上から水平にスキャンされ、LZWエンコードによってコードに変換され、バイトにマッピングされてファイルに保存されます。ピクセルコードは通常、バイトの8ビットサイズと一致しないため、「リトルエンディアン」方式でバイトにパックされます。つまり、最初のコードの最下位ビットは最初のバイトの最下位ビットに格納され、コードの上位ビットはバイトの上位ビットに格納され、必要に応じて次のバイトの下位ビットに繰り越されます。後続の各コードは、未使用の最下位ビットから順に格納されます。

このバイトストリームは、一連の「サブブロック」としてファイルに保存されます。各サブブロックの最大長は255バイトで、サブブロック内のデータバイト数を示すバイトが先頭に付きます。一連のサブブロックは、空のサブブロック（データバイトが0バイトであることを示す単一の0バイト）で終了します。

上記のサンプル画像では、9 ビット コードとバイト間の可逆マッピングが以下に示されています。

可逆マッピング
9ビットコード バイト
16進数バイナリバイナリ16進数
1001 000000000000000000
02800 01010000101000 151
0FF011 111111111111 00FC
1031000 0001100011 0111B
10210000 00100010 100028
103100000 011011 1000070
1061000001 1010 100000A0
10710000011 11 1000001C1
1000001183
1011 000000010000000101
0000000 101

わずかな圧縮が見られます。当初15バイトで定義されたピクセルカラーは、制御コードを含む12バイトのコードで正確に表現されます。9ビットコードを生成するエンコードプロセスを以下に示します。ローカル文字列はパレットからピクセルカラー番号を蓄積し、ローカル文字列がコードテーブルに見つかる限り、出力アクションは発生しません。文字列の追加によってテーブルが初期サイズから拡大する前に到着する最初の2つのピクセルには特別な処理が行われます。各出力コードの後、ローカル文字列は最新のピクセルカラー（出力コードに含まれなかったカラー）に初期化されます。 

表 9ビット文字列 --> コード コード アクション #0 | 000h 9ビットコードのルートテーブルを初期化する パレット | : 色 | : #255 | 0FFh クリア | 100時間 終了 | 101時間 | 100時間クリア ピクセルローカル カラーパレット文字列 | BLACK #40 28 | 028h 常に出力される最初のピクセル WHITE #255 FF | 表内の文字列が見つかりました 28 FF | 102h 常に最初の文字列をテーブルに追加する FF | ローカル文字列を初期化する WHITE #255 FF FF | テーブルに文字列が見つかりません | 0FFh - 前の文字列の出力コード FF FF | 103h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化する WHITE #255 FF FF | テーブル内の文字列が見つかりました BLACK #40 FF FF 28 | テーブルに文字列が見つかりません | 103h - 前の文字列の出力コード FF FF 28 | 104h - 最新の文字列をテーブルに追加 28 | - ローカル文字列を初期化する WHITE #255 28 FF | 表に見つかった文字列 WHITE #255 28 FF FF | テーブルに文字列が見つかりません | 102h - 前の文字列の出力コード 28 FF FF | 105h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化する WHITE #255 FF FF | テーブル内の文字列が見つかりました WHITE #255 FF FF FF | テーブルに文字列が見つかりません | 103h - 前の文字列の出力コード FF FF FF | 106h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化する WHITE #255 FF FF | テーブル内の文字列が見つかりました WHITE #255 FF FF FF | テーブル内の文字列が見つかりました WHITE #255 FF FF FF FF | テーブルに文字列が見つかりません | 106h - 前の文字列の出力コード FF FF FF FF| 107h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化する WHITE #255 FF FF | テーブル内の文字列が見つかりました WHITE #255 FF FF FF | テーブル内の文字列が見つかりました WHITE #255 FF FF FF FF | 表内の文字列が見つかりました ピクセルはもうない 107h - 最後の文字列の出力コード 101時間終了

分かりやすくするために、上記のテーブルは長さが増加する文字列で構成されているように示されています。この方式は機能しますが、テーブルが消費するメモリ量は予測できません。実際には、格納される新しい文字列は、以前に格納された文字列に1文字を追加したもので構成されるため、メモリを節約できます。各アドレスには、既存のアドレスと1文字の2ワードのみを格納するのが経済的です。

LZWアルゴリズムでは、各ピクセルごとにテーブルを検索する必要があります。最大4096個のアドレスを線形検索すると、コーディング速度が低下します。実際には、コードは数値順に格納できます。これにより、各検索はSAR（一部のADCで使用されている逐次近似レジスタ）によって実行され、12回の絶対値比較のみで済みます。この効率化のために、コードと実際のメモリアドレスを変換するための追加のテーブルが必要です。この追加のテーブル管理は、新しいコードが格納される場合にのみ必要であり、これはピクセルレートよりもはるかに低いレートで発生します。

画像のデコード

デコードは、保存されたバイトを9ビットコードにマッピングすることから始まります。これらはデコードされ、以下に示すようにピクセルの色を復元します。エンコーダで使用されるものと同一のテーブルは、以下の規則に従って文字列を追加することで構築されます。

着信コードはテーブル内に見つかりますか?
はいローカルコードの文字列を追加し、その後に受信コードの文字列の最初のバイトを追加します。
いいえローカルコードの文字列を追加し、その後にその文字列の最初のバイトのコピーを追加します。 
9ビットシフト----> ローカルテーブル ピクセルコード コードコード --> 文字列 パレットカラー アクション 100h 000h | #0 9ビットコードのルートテーブルを初期化する  : | パレット  : | 色 0FFh | #255 100時間 | クリア 101時間 | 終了 028h | #40 BLACK 最初のピクセルをデコード 0FFh 028h | テーブルに着信コードが見つかりました | #255 WHITE - テーブルから文字列を出力する 102h | 28 FF - テーブルに追加 103h 0FFh | 受信コードがテーブルに見つかりません 103h | FF FF - テーブルに追加 | - テーブルから文字列を出力する | #255 ホワイト | #255 ホワイト 102h 103h | テーブルに着信コードが見つかりました | - テーブルから文字列を出力する | #40 ブラック | #255 ホワイト 104h | FF FF 28 - テーブルに追加 103h 102h | テーブルに着信コードが見つかりました | - テーブルから文字列を出力する | #255 ホワイト | #255 ホワイト 105h | 28 FF FF - テーブルに追加 106h 103h | 受信コードがテーブルに見つかりません 106h | FF FF FF - テーブルに追加 | - テーブルから文字列を出力する | #255 ホワイト | #255 ホワイト | #255 ホワイト 107h 106h | 受信コードがテーブルに見つかりません 107h | FF FF FF FF - テーブルに追加 | - テーブルから文字列を出力する | #255 ホワイト | #255 ホワイト | #255 ホワイト | #255 ホワイト 101時間 | 終了

LZWコードの長さ

例の256色よりも小さいパレットでは、より短いコード長を使用できます。パレットが64色（つまり色インデックスが6ビット幅）の場合、シンボルの範囲は0～63、シンボル幅は6ビット、コードは7ビットから開始できます。実際には、シンボル幅はパレットサイズと一致する必要はありません。デコードされた値が常にパレットの色数よりも小さい限り、シンボルの幅は2～8、パレットサイズは2～256の2の累乗にすることができます。例えば、パレットの最初の4色（値0～3）のみを使用する場合、シンボルの幅は2ビット、コードは3ビットから開始できます。

逆に、0と1の値のみを使用する場合でも、シンボル幅を8に設定できます。これらのデータには2色テーブルのみが必要です。このようにファイルをエンコードする意味はありませんが、2色画像でも同様の動作が通常発生します。0と1の値のみを使用する場合でも、最小シンボル幅は2です。

コードテーブルには、2つの特殊コードclrとend 、そして処理中に追加される文字列用のコードを格納するため、シンボルサイズより1ビット長いコードが初期状態で含まれています。テーブルがいっぱいになると、より多くの文字列を格納するためのスペースを確保するためにコード長が増加し、最大コード長は4095 = FFF(hex)です。デコーダーはテーブルを構築する際に、コード長の増加を追跡し、それに応じて入力バイトを展開します。

非圧縮GIF

7ビットシンボル（128色、8ビットコード）を含む46×46の非圧縮GIF画像。画像をクリックするとコードの説明が表示されます。

GIFエンコード処理を変更することで、LZW圧縮を施さずにGIF画像として表示可能なファイルを作成できます。この手法は、もともと特許侵害を回避するために導入されました。非圧縮GIFは、個々のピクセルにアクセスして読み取りやペイントができるため、グラフィックプログラマーにとって便利な中間形式にもなります。非圧縮GIFファイルは、画像エディタに渡すだけで通常のGIFファイルに変換できます。

修正されたエンコード方式では、LZWテーブルの構築は無視され、ルートパレットコードとCLEARおよびSTOPのコードのみが出力されます。これによりエンコードはよりシンプルになります（コード値とパレットコードが1対1で対応）。ただし、圧縮効果はすべて犠牲になります。画像内の各ピクセルは、そのカラーインデックスを示す出力コードを生成します。非圧縮GIFを処理する場合、標準的なGIFデコーダーは辞書テーブルに文字列を書き込むことができますが、コード幅が大きくなるとビットからバイトへのパッキング方法が異なるため、コード幅が大きくなることは決してありません。

シンボル幅がnの場合、幅n +1のコードは自然に 2 つのブロックに分けられます。1 つは単一のシンボルをコード化するための2 nコードの下部ブロック、もう 1 つは長さが 1 より大きいシーケンスに対してデコーダーが使用する2 nコードの上部ブロックです。上部ブロックの最初の 2 つのコードはすでに使用されています。2 nは CLEAR、2 n + 1は STOP です。デコーダーは上部ブロックの最後のコード2 n +1 − 1を使用しないようにする必要があります。デコーダーがそのスロットを埋めると、コード幅が増加するためです。したがって、上部ブロックには、コード幅の増加をトリガーしない2 n − 3 個のコードがデコーダーで使用できます。デコーダーはテーブルの維持において常に 1 ステップ遅れているため、エンコーダーから最初のコードを受信して​​もテーブル エントリは生成されませんが、後続のコードごとに 1 つ生成します。したがって、エンコーダーはコード幅の増加をトリガーせずに2 n − 2 個のコードを生成できます。したがって、エンコーダはデコーダにコーディング辞書をリセットさせるために、 2 n − 2コード以下の間隔で追加のCLEARコードを出力する必要があります。GIF規格では、このような追加のCLEARコードを画像データにいつでも挿入できます。複合データストリームは、それぞれ1～255バイトのサブブロックに分割されます。

上記の 3×5 のサンプル画像の場合、次の 9 ビット コードは「クリア」(100)、その後にスキャン順の画像ピクセル、そして「停止」(101) を表します。 

100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

上記のコードがバイトにマッピングされた後、圧縮されていないファイルは圧縮されたファイルと次のように異なります。

バイト番号（16進数）16進数テキストまたは値意味
320142020バイトの非圧縮画像データが続く
32100 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335000画像データの終了

圧縮例

単色の大きな画像の単純な例は、GIF ファイルで使用される可変長 LZW 圧縮を示しています。

GIFファイルの圧縮例
コード ピクセル 注記
いいえ。
ニi		価値
Ni + 256 		長さ
（ビット） 		このコード
ニi		蓄積された
⁠Ni ( Ni + 1)/2⁠		N iを使用する関係は、コーディング テーブルがいっぱいになるまで、同じ色のピクセルにのみ適用されます。
0 100時間 9 クリアコードテーブル
1 FFh 1 1 256色パレットの最高インデックスとして選択された左上のピクセルの色
2 102時間 2 3
3
⋮
255 		103時間
⋮
1FF時間 		3
⋮
255 		6
⋮
32640 		最後の9ビットコード
256
⋮
767 		200時間
⋮
3FF時間 		10 256
⋮
767 		32896
⋮
294528 		最後の10ビットコード
768
⋮
1791 		400時間
⋮
7FF時間 		11 768
⋮
1791 		295296
⋮
1604736 		最後の11ビットコード
1792
⋮
3839 		800時間
⋮
FFFh 		12 1792
⋮
3839 		1606528
⋮
7370880 		コードテーブルがいっぱい
⋮ FFFh 3839 最大コードは、同じ色のピクセルが複数ある場合に繰り返されることがあります。
全体的なデータ圧縮は漸近的に3839 × ⁠に近づきます。8/12⁠ = ⁠2559+1/3⁠
101時間 画像データの終了

表示されるコード値はバイトにパックされ、さ​​らに最大255バイトのブロックにパックされます。画像データのブロックは、後続のバイト数を宣言するバイトで始まります。画像の最後のデータブロックは、ブロック長が0のバイトで示されます。

インターレース

ウェブブラウザで読み込まれるインターレースGIFのスクリーンキャプチャ

GIF仕様では、GIFファイルの論理画面内の各画像について、インターレース（つまり、データブロック内のラスターラインの順序が連続していない）であることを指定できます。これにより、画像全体が描画される前に、画像の一部を表示して認識することが可能になります。

インターレース画像は上から下まで 8 ピクセルの高さのストリップに分割され、画像の行は次の順序で表示されます。

  • パス 1: 各ストリップの行 0 (一番上の行)。
  • パス 2: 各ストリップの 4 行目。
  • パス 3: 各ストリップの 2 行目と 6 行目。
  • パス 4: 各ストリップの行 1、3、5、および 7。

各ライン内のピクセルはインターレースではなく、左から右へ連続して表示されます。非インターレース画像と同様に、1つのラインのデータと次のラインのデータの間には途切れがありません。画像がインターレースであることを示すビットは、対応する画像記述子ブロックに設定されます。

アニメーションGIF

GIF は、ニュートンのゆりかごのこの画像のように、アニメーションを表示するために使用できます。

GIF はアニメーション メディアとして設計されたわけではありませんが、複数の画像を 1 つのファイルに保存できることから、当然、アニメーション シーケンスのフレームを保存するためにこの形式を使用することが示唆されました。アニメーションを表示できるようにするために、GIF89a 仕様では、ファイル内の画像 (フレーム) を時間遅延でペイントして、ビデオ クリップを形成できるグラフィック コントロール拡張機能 (GCE)が追加されました。アニメーション GIF 内の各フレームは、フレームが描画された後の時間遅延を指定する独自の GCE によって導入されます。ファイルの先頭のグローバル情報は、既定ですべてのフレームに適用されます。データはストリーム指向であるため、各 GCE の開始のファイル オフセットは、先行するデータの長さによって異なります。各フレーム内では、LZW コード化されたイメージ データが最大 255 バイトのサブブロックに配置されます。各サブブロックのサイズは、その直前のバイトによって宣言されます。

デフォルトでは、アニメーションはフレームのシーケンスを一度だけ表示し、最後のフレームが表示されると停止します。アニメーションをループさせるために、Netscape は1990 年代にアプリケーション拡張ブロック (ベンダーがアプリケーション固有の情報を GIF ファイルに追加できるようにすることを目的としていた) を使用して Netscape アプリケーション ブロック (NAB) を実装しました。[ 39 ]このブロックは、アニメーション フレームのシーケンスの直前に配置され、フレームのシーケンスを再生する回数 (1～65535 回) または連続して繰り返すかどうか (0 は永久にループすることを示す) を指定します。これらの繰り返しアニメーションのサポートは、Netscape Navigatorバージョン 2.0 で初めて登場し、その後他のブラウザーに広がりました。[ 40 ]現在ではほとんどのブラウザーが NAB を認識してサポートしていますが、厳密には GIF89a 仕様の一部ではありません。

次の例は、記事のインフォボックスに（サムネイルとして）表示される アニメーション ファイルRotating earth (large).gifの構造を示しています。

GIFの構造
バイト番号（16進数）16進数テキストまたは値意味
047 49 46 38 39 61GIF89a論理画面記述子
690 01400ピクセル単位の幅
890 01400高さ（ピクセル単位）
あF7 GCTは解像度3 × 8ビット/プライマリ で256色に対応します。
B000背景色: #000000、黒
C000デフォルトのピクセルアスペクト比、0:0
D00グローバルカラーテーブル
⋮
30D 21 '!'拡張ブロック（ASCII感嘆符で始まる'!'）
30EFFアプリケーション拡張
30階0B11アプリケーション名と検証バイトを含むブロックのサイズ（常に 11）
3104E 45 54 53 43 41 50 45 32 2E 30ネットスケープ2.08バイトのアプリケーション名と3つの検証バイト
31B033次のサブブロックのバイト数
31C011現在のデータ サブブロックのインデックス(NETSCAPE ブロックの場合は常に 1)
31DFF FF65535符号なし繰り返し回数
31階00アプリケーション拡張ブロックのサブブロックチェーンの終わり
320 21 '!'拡張ブロック（ASCII感嘆符で始まる'!'）
321F9フレーム #1 のグラフィック コントロール拡張
322044現在のサブブロック内のバイト数（4）
32304
000..... ...001.. ......0. .......0
（読みやすくするためにセクションに分けられています）		予約済み、下位5ビットはビットフィールド破棄方法1: 破棄しないユーザー入力なし透明色、0は指定なしを意味する
32409 009フレーム遅延: 次のフレームを描画する前に 0.09 秒の遅延
326FF透明色インデックス（このフレームでは未使用）
32700グラフィック制御拡張ブロックのサブブロックチェーンの終了
3282C','画像記述子（ASCIIコンマ0x2Cで導入','）
32900 00 00 00（0, 0）論理画面内の画像の北西隅の位置: (0, 0)
32D90 01 90 01（400、400）フレームの幅と高さ: 400 × 400 ピクセル
331000ローカルカラーテーブル: 0 はなし、インターレースなしを意味します
332088フレーム#1の画像データの最小LZWコードサイズ
333FF255次のサブブロック内のLZW画像データのバイト数: 255バイト
334...<画像データ>画像データ、255バイト
433FF255次のサブブロック内のLZW画像データのバイト数、255バイト
434...<画像データ>画像データ、255バイト
⋮次のブロックでも繰り返します
92C000このフレームのサブブロックチェーンの終了
92C1 21 '!'拡張ブロック（ASCII感嘆符で始まる'!'）
92C2F9フレーム #2 のグラフィック コントロール拡張
⋮次のフレームを繰り返す
エダブド 21 '!'拡張ブロック（ASCII感嘆符で始まる'!'）
枝部F9フレーム #44 のグラフィック コントロール拡張
⋮フレーム#44の画像情報とデータ
F48F53Bトレーラー: ファイルの最後のバイト。EOF を示す。

各フレームのアニメーション遅延は、GCEで100分の1秒単位で指定されます。画像記述子は画像全体ではなく、再スキャンする小さな矩形を定義できるため、フレームがディスプレイのピクセルの一部のみを書き換えるだけで済む場合、ある程度のデータ節約が可能です。アニメーションGIFをサポートしていないブラウザやその他のディスプレイでは、通常、最初のフレームのみが表示されます。

アニメーション GIF ファイルのサイズと色の品質は、作成に使用したアプリケーションによって大きく異なります。ファイル サイズを最小化するための戦略としては、すべてのフレームに共通のグローバル カラー テーブルを使用する (各フレームの完全なローカル カラー テーブルではなく)、連続するフレームでカバーされるピクセルの数を最小化する (あるフレームから次のフレームに変化するピクセルのみが後のフレームに含まれるようにする) などがあります。より高度な手法では、既存の LZW 辞書 (非可逆圧縮の一種) に適合するように色のシーケンスを変更します。一連の独立したフレーム画像を単純に合成アニメーションにまとめると、ファイル サイズが大きくなる傾向があります。既存の GIF のファイル サイズを最小化するツールが用意されています。

メタデータ

メタデータは、GIFファイル内にコメントブロック、プレーンテキストブロック、またはアプリケーション固有のアプリケーション拡張ブロックとして保存できます。多くのグラフィックエディターでは、画像の生成に使用されたデータを非公式のアプリケーション拡張ブロックに格納することで、後から編集できるようにしています。

これらの方法はすべて、技術的にはメタデータをサブブロックに分割して、アプリケーションがメタデータ ブロックの内部構造を知らなくてもそのブロック内を移動できるようにする必要があります。

Extensible Metadata Platform (XMP) メタデータ標準では、GIFファイルにXMPデータを含めるための非公式ながら現在では広く普及している「XMPデータ」アプリケーション拡張ブロックが導入されました。[ 41 ] XMPデータはNUL文字を含まないUTF-8でエンコードされているため、データ内に0バイトは存在しません。データを正式なサブブロックに分割するのではなく、拡張ブロックは「マジックトレーラー」で終了し、データをサブブロックとして扱うアプリケーションを、サブブロックチェーンの終了を示す最後の0バイトへと誘導します。

ユニシスとLZWの特許執行

1977年と1978年に、ジェイコブ・ジヴとアブラハム・レンペルは、現在LZ77とLZ78と総称される、新しいクラスのロスレスデータ圧縮アルゴリズムに関する2本の論文を発表しました。1983年、テリー・ウェルチはLZ78の高速版を開発し、レンペル・ジヴ・ウェルチ（LZW）と名付けました。[ 42 ] [ 43 ]

ウェルチは1983年6月にLZW法の特許を出願した。その結果得られた特許US4558302 [ 44 ]は1985年12月に付与され、スペリー社に譲渡された。スペリー社はその後1986年にバローズ社と合併してユニシス社を設立した[ 42 ]。さらにイギリス、フランス、ドイツ、イタリア、日本、カナダでも特許を取得した。

上記の特許に加えて、ウェルチの 1983 年の特許には、それに影響を与えた他のいくつかの特許の引用も含まれています。

1984年6月、ウェルチによる論文がIEEE誌に掲載され、初めてLZW技術が公表された。[ 49 ] LZWは人気のデータ圧縮技術となり、特許が認められると、ユニシスは100社以上の企業とライセンス契約を結んだ。[ 42 ] [ 50 ]

LZWの人気を受けて、CompuServeは1987年に開発したGIFの圧縮技術としてLZWを採用した。当時、CompuServeはこの特許の存在を知らなかった。[ 42 ] Unisysは、GIFのバージョンがLZW圧縮技術を使用していることを知り、1993年1月にCompuServeとライセンス交渉に入った。その後の契約は1994年12月24日に発表された。[ 43 ] Unisysは、LZW特許を採用しているすべての大手商用オンライン情報サービス企業が、Unisysから妥当な価格でこの技術のライセンスを取得することを期待しているが、オンラインサービスで使用するものも含め、非商用、非営利のGIFベースのアプリケーションについては、ライセンスや料金の支払いを要求しないと述べた。[ 50 ]

この発表の後、CompuServeとUnisysに対する非難が広がり、多くのソフトウェア開発者がGIFの使用をやめると脅した。1995年には、GIFの代替としてPNG形式（下記参照）が開発された。 [ 42 ] [ 43 ] [ 49 ]しかし、ウェブブラウザやその他のソフトウェアのメーカーからPNG形式へのサポートを得るのは困難で、PNGの人気は徐々に高まったものの、GIFを置き換えることはできなかった。[ 42 ]そのため、LZW圧縮を使用しないGIFのバリエーションが開発された。例えば、Eric S. Raymondのgiflibをベースにしたlibungifライブラリは、データ形式に準拠しながらも圧縮機能を回避し、UnisysのLZW特許の使用を回避したGIFの作成を可能にしている。[ 51 ] 2001年のDr. Dobbの論文では、ランレングス符号化機構で十分に圧縮できるデータを、特許を侵害することなくLZW互換符号化する方法が説明されている。[ 52 ]

1999年8月、ユニシスはライセンス制度の詳細を変更し、特定の非営利および個人ウェブサイトの所有者に対し、5,000ドルまたは7,500ドルの一時ライセンス料を支払うことでライセンスを取得できるオプションを発表しました。[ 53 ]ライセンスソフトウェアを使用してGIFを生成したウェブサイト所有者やその他のGIFユーザーには、このようなライセンスは必須ではありませんでした。しかし、ユニシスは、ウェブサイトでGIFを使用したことで5,000ドルの罰金を請求されたり訴訟を起こされたりすると信じ込んでいるユーザーからの数千件ものオンライン攻撃や中傷メールにさらされました。[ 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）は、UnisysのLZW圧縮技術の特許侵害を回避するために、GIFの代替として設計されました。[ 42 ] PNGはGIFよりも優れた圧縮率と多くの機能を提供しますが、[ 59 ]アニメーションが唯一の大きな例外です。PNGは、トゥルーカラー画像とアルファ透過性が求められる 場合には、GIFよりも適しています。

PNG形式のサポートは徐々に進みましたが、新しいウェブブラウザはPNGをサポートしています。Internet Explorerの古いバージョンはPNGのすべての機能をサポートしていません。バージョン6以前では、 Microsoft固有のHTML拡張機能を使用せずにアルファチャンネルの透明化をサポートしていません。 [ 60 ] PNG画像のガンマ補正はバージョン8より前ではサポートされておらず、以前のバージョンではこれらの画像の表示に誤った色合いが生じる可能性があります。[ 61 ]

同一の8ビット（またはそれ以下）の画像データの場合、PNGファイルは、PNGエンコードで使用されるより効率的な圧縮技術により、通常、同等のGIFファイルよりも小さくなります。[ 62 ] GIFの完全なサポートは、主に複雑なキャンバス構造によって複雑になっていますが、これがコンパクトなアニメーション機能を可能にしています。

アニメーション形式

動画は、ウェブ上でのGIFの一般的な使用において生じる多くの問題を解決します。例えば、ファイルサイズが大幅に小さいこと、 8ビットカラー制限を克服できること、インターフレームコーディングによるフレーム処理と圧縮率の向上などが挙げられます。ウェブブラウザでGIF形式がほぼ普遍的にサポートされていること、そしてHTML標準では動画が公式にサポートされていないことが、ウェブ上で短い動画のようなファイルを表示する目的でGIFが注目を集めるきっかけとなりました。

  • MNG（Multiple-image Network Graphics）は、もともとアニメーション用のPNGベースのソリューションとして開発されました。MNGは2001年にバージョン1.0に到達しましたが、それをサポートするアプリケーションはほとんどありません。
  • APNG（Animated Portable Network Graphics）は、 2006年にMozillaによって提案されました。APNGは、MNG形式の代替としてPNG形式の拡張版です。2019年現在、APNGはほとんどのブラウザでサポートされています。[ 63 ] APNGはPNGファイルをアニメーション化する機能を提供しながら、アニメーションチャンクを理解できないデコーダー（MNGとは異なり）でも下位互換性を維持します。古いデコーダーは、アニメーションの最初のフレームのみをレンダリングします。
PNGグループは2007年4月20日にAPNGを公式拡張機能として正式に拒否した。[ 64 ]
その後、PNGをベースにしたシンプルなアニメーショングラフィックフォーマットが、様々なアプローチで提案されてきました。[ 65 ]しかしながら、APNGは現在もMozillaによって開発中であり、Firefox 3.0でサポートされています。 [ 66 ] [ 67 ]一方、MNGのサポートは廃止されました。[ 68 ] [ 69 ] APNGは現在、Chrome（バージョン59.0以降）、Opera、Firefox、Edgeなど、すべての主要ウェブブラウザでサポートされています。
  • 一部の Web サイトでは、単純なビデオを表示するために埋め込みのAdob​​e FlashオブジェクトとMPEGファイルが使用されていましたが、追加のブラウザ プラグインの使用が必要でした。
  • WebMとWebPは現在開発中であり、一部のウェブブラウザでサポートされています。[ 70 ]
  • ウェブアニメーションの他の選択肢としては、AJAXを使用して個々のフレームを提供したり、JavaScriptまたはSMIL （「同期マルチメディア統合言語」）を使用してSVG （ 「スケーラブルベクターグラフィックス」）画像をアニメーション化したりすることが挙げられる。[ 71 ]
  • HTMLのビデオタグ（ ）が多くのウェブブラウザで広くサポートされるようになったため<video>、一部のウェブサイトではビデオタグのループバージョンが使用されています。これにより、GIFのような見た目になりながら、圧縮された動画のサイズと速度の利点を享受できます。
注目すべき例としては、GfycatとImgurとそのGIFVメタフォーマットが挙げられます。これは実際には、ループされたMP4またはWebM圧縮ビデオを再生するビデオタグです。[ 72 ]
  • HEIF（High Efficiency Image File Format）は、2015年に策定された画像ファイル形式で、HEVCビデオフォーマットをベースにした離散コサイン変換（DCT）非可逆圧縮アルゴリズムを採用しています。JPEG画像フォーマットと関連があります。JPEGとは異なり、HEIFはアニメーションをサポートしています。[ 73 ]
DCT圧縮ができないGIF形式と比較して、HEIFははるかに効率的な圧縮を可能にします。HEIFはより多くの情報を保存し、同等のGIFのわずかなサイズでより高品質のアニメーション画像を生成します。[ 74 ]

用途

2014年4月、4chanはサイズが3MB以下で長さが2分以下の無音WebM動画のサポートを追加しました。 [ 76 ] [ 77 ]また、2014年10月には、ImgurはサイトにアップロードされたGIFファイルをH.264動画に変換し、HTMLプレーヤーへのリンクに.gifv拡張子が付いた実際のファイルのような外観を与えるようになりました。[ 78 ] [ 79 ]

2016年1月、TelegramはすべてのGIFをMPEG-4ビデオに再エンコードし始めました。これにより「同じ画質で最大95%のディスク容量を削減」できます。[ 80 ]

参照

参考文献

  1. ^ a b c「Graphics Interchange Format, Version 87a」。W3C 。 1987年6月15日。2018年12月22日時点のオリジナルよりアーカイブ。 2012年10月13日閲覧。
  2. ^ a b c「Graphics Interchange Format, Version 89a」。W3C 。 1990年7月31日。2018年12月22日時点のオリジナルよりアーカイブ。2009年3月6日閲覧。
  3. ^ティファニー、ケイトリン (2022年10月7日). 「GIFは死の床にある」 .アトランティック誌. 2023年10月21日閲覧。
  4. ^ 「オンラインアート」。Compute !のAppleアプリケーション。1987年12月。10ページ。 2016年9月14日閲覧。
  5. ^ホールデナーIII、アンソニー（2008年）『Ajax：決定版ガイド：Web向けインタラクティブアプリケーション』オライリーメディア、ISBN 978-0596528386。
  6. ^フルト、ボルコ (2008)。マルチメディア百科事典。スプリンガー。ISBN 978-0387747248。
  7. ^ McHugh, Molly (2015年5月29日). 「ついにFacebookにGIFを投稿できるようになりました」 . Wired . 2015年5月30日時点のオリジナルよりアーカイブ。2015年5月29日閲覧。
  8. ^ Perez, Sarah (2015年5月29日). 「FacebookがGIFを正式にサポートすることを確認」 TechCrunch . 2015年5月30日時点のオリジナルよりアーカイブ。 2015年5月29日閲覧。
  9. ^ 「GIFステッカーの紹介」 Instagram 、 2018年1月23日。2019年12月12日時点のオリジナルよりアーカイブ。2019年9月19日閲覧。
  10. ^ Ghoshal, Abhimanyu (2016年10月28日). 「ジオシティーズ時代の160万点の素晴らしいオールドスクールGIFをお楽しみください」 . TNW | Shareables . 2024年11月4日閲覧。
  11. ^ "GifCities" . gifcities.org . 2024年11月4日閲覧。
  12. ^ 「Oxford Dictionaries USA Word of the Year 2012」。OxfordWordsブログ。Oxford American Dictionaries。2012年11月13日。2014年8月3日時点のオリジナルよりアーカイブ。 2013年5月1日閲覧。
  13. ^ Flood, Alison (2013年4月27日). 「GIFはアメリカの今年の言葉？これぞ大混乱」 . Books blog. The Guardian . ロンドン. 2016年12月1日時点のオリジナルよりアーカイブ。 2013年5月1日閲覧。
  14. ^オルセン、スティーブ. 「GIF発音ページ」 . 2009年2月25日時点のオリジナルよりアーカイブ。2009年3月6日閲覧。
  15. ^ a b c「GIFの発明者は辞書を無視して「Jif」と言う" . BBCニュース. 2013年5月22日.オリジナルより2018年6月27日時点のアーカイブ。 2013年5月22日閲覧。
  16. ^ Buck, Stephanie (2014年10月21日). 「世界中の70%の人がGIFを硬いgで発音する」 . Mashable . 2021年12月23日時点のオリジナルよりアーカイブ。 2021年12月24日閲覧。
  17. ^ van der Meulen, Marten (2019年5月22日). 「オバマ、スキューバか贈り物か？： GIFの発音に関するオンライン議論における権威と議論」 . English Today . 36 (1): 45–50 . 2022年5月24日時点のオリジナルよりアーカイブ。 2022年5月22日閲覧。
  18. ^ "GIF" . The American Heritage Abbreviations Dictionary, Third Edition . Houghton Mifflin Company. 2005年. 2011年9月3日時点のオリジナルよりアーカイブ。 2007年4月15日閲覧。
  19. ^ "GIF" . 『ケンブリッジアメリカ英語辞典』. ケンブリッジ大学出版局. 2014年2月27日時点のオリジナルよりアーカイブ。 2014年2月19日閲覧。
  20. ^ 「GIF - Merriam-Webster辞書による定義」 Merriam -Webster辞書Merriam-Webster, Incorporated. 2013年10月22日時点のオリジナルよりアーカイブ。 2013年6月6日閲覧。
  21. ^ "GIF" . Oxford Dictionaries Online . Oxford University Press. 2014年10月12日時点のオリジナルよりアーカイブ。 2014年10月7日閲覧。
  22. ^ 「gif noun - 定義、写真、発音、使用法 | Oxford Advanced Learner's Dictionary」。Oxford Learner's Dictionaries。2020年11月24日時点のオリジナルよりアーカイブ。 2021年2月6日閲覧。
  23. ^ “GIF | オックスフォード辞書によるGIFの定義” . Lexico . 2021年2月13日時点のオリジナルよりアーカイブ。2021年2月6日閲覧。
  24. ^スティーブンソン、アンガス編 (2010).オックスフォード英語辞典（第3版）. オックスフォード大学出版局. ISBN 9780199571123. OCLC  729551189 .
  25. ^ 『新オックスフォード米語辞典（第2版）』オックスフォード大学出版局、2005年、711頁。
  26. ^新オックスフォード米語辞典（第3版）。2012年。(Macintosh の組み込み辞書の一部)。
  27. ^ O'Leary, Amy (2013年5月21日). 「GIFの作者に栄誉を」 . The New York Times . 2013年5月22日時点のオリジナルよりアーカイブ。2013年5月22日閲覧。
  28. ^ a bロスバーグ、ダニエル（2013年12月4日）。「『Jeopardy』が『GIF』の発音バトルに参戦」ロサンゼルス・タイムズ。2013年12月6日時点のオリジナルよりアーカイブ。 2013年12月4日閲覧。
  29. ^ O'Leary, Amy (2013年5月23日). 「『GIF』の発音をめぐる争いが勃発」 . The New York Times . 2013年12月16日時点のオリジナルよりアーカイブ。 2013年12月5日閲覧。
  30. ^ Valinsky, Jordan (2020年2月25日). 「JifがGIFピーナッツバター瓶で大論争を解決」 . CNN . 2020年2月25日時点のオリジナルよりアーカイブ。2020年2月25日閲覧。
  31. ^ Marur, DR; Bhaskar, V. (2012年3月). "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. 2017年7月2日時点のオリジナルよりアーカイブ。2015年3月11日閲覧。
  32. ^ S.チン; D.アイバーソン。 O.カンペサト; P. トラーニ (2011)。プロ Android フラッシュ(PDF)。ニューヨーク：アプレス。 p. 350.ISBN​ 9781430232315. 2015年4月2日時点のオリジナルよりアーカイブ(PDF) 。 2015年3月11日閲覧。
  33. ^ Bakhshi, Saeideh; Shamma, David A.; Kennedy, Lyndon; Song, Yale; de Juan, Paloma; Kaye, Joseph "Jofish" (2016年5月7日). 「速く、安く、そして良い：アニメーションGIFが私たちを魅了する理由」 . 2016 CHI Conference on Human Factors in Computing Systems 論文集. pp.  575– 586. doi : 10.1145/2858036.2858532 . ISBN 9781450333627. S2CID  7417853 . 2022年8月17日閲覧。
  34. ^ Highfield, Tim; Leaver, Tama (2016). 「Instagrammaticsとデジタル手法：セルフィーやGIFからミームや絵文字まで、ビジュアルソーシャルメディアの研究」 . Communication Research and Practice . 2 (1): 47– 62. doi : 10.1080/22041451.2016.1155332 . hdl : 20.500.11937/36939 . S2CID 148538216. 2022年8月17日閲覧。 
  35. ^ a b c Andreas Kleinert (2007). 「GIF 24 Bit (truecolor) extensions」 . 2012年3月16日時点のオリジナルよりアーカイブ。 2012年3月23日閲覧。
  36. ^ a b Philip Howard. 「True-Color GIFの例」 . 2015年2月22日時点のオリジナルよりアーカイブ。2012年3月23日閲覧。
  37. ^ 「Nullsleep - Jeremiah Johnson - Animated GIF Minimum Frame Delay Browser Compatibility Study」。2014年10月10日時点のオリジナルよりアーカイブ。2015年5月26日閲覧。
  38. ^ 「ブラウザ間でGIFファイルのアニメーションレートを一致させる方法」開発者ブログ、2012年2月14日。2017年2月1日時点のオリジナルよりアーカイブ。 2017年6月15日閲覧。
  39. ^ Royal Frazier. 「All About GIF89a」 . 1999年4月18日時点のオリジナルよりアーカイブ。 2013年1月7日閲覧。
  40. ^スコット・ウォルター (1996). 『Webスクリプティングの秘密兵器』 . Que Publishing . ISBN 0-7897-0947-3。
  41. ^ 「XMP仕様パート3：ファイルへの保存」（PDF） Adobe 2016年 11～ 12ページ。 2018年2月25日時点のオリジナルよりアーカイブ（PDF） 。 2018年8月16日閲覧。
  42. ^ a b c d e f g Greg Roelofs. 「Portable Network Graphics (PNG) Formatの歴史」 . 2012年3月7日時点のオリジナルよりアーカイブ。2012年3月23日閲覧。
  43. ^ a b c Stuart Caie. 「悲しい日…GIFの特許が20歳で消滅」オリジナルより2012年2月10日時点のアーカイブ。 2012年3月23日閲覧。
  44. ^ US 4558302、Welch、Terry A.、1985年12月10日公開、Sperry Corp.に譲渡。 
  45. ^ JP特許 S5719857A、金津 紀雲、「データ圧縮記憶装置」、1982年2月2日公開、日本電気株式会社に譲渡。 
  46. ^ JP特許 S57101937A、金津 紀雲、「データ記憶装置」、1986年20月24日公開、日本電気株式会社に譲渡。 
  47. ^ DE 特許 3118676、Eckhart、Heinz Karl、「Verfahren zur Kompression redundanter Folgen serieller Datenelemente [シリアル データ要素の冗長シーケンスを圧縮する方法]」、1982 年 12 月 2 日発行 
  48. ^米国特許4,558,302
  49. ^ a b「GIF論争：ソフトウェア開発者の視点」 1995年1月27日。2016年8月23日時点のオリジナルよりアーカイブ。 2015年5月26日閲覧。
  50. ^ a b「Unisys、オンラインサービス提供における特許使用に関するポリシーを明確化」 。2007年2月7日時点のオリジナルよりアーカイブ。–プログラミング自由連盟によるアーカイブ
  51. ^ “Libungif” . 2015年4月13日時点のオリジナルよりアーカイブ。2015年5月26日閲覧。
  52. ^ Cargill, Tom (2001年10月1日). 「辞書を平方根に置き換える」 . Dr. Dobb's Journal . 2017年6月28日時点のオリジナルよりアーカイブ。 2017年1月20日閲覧。
  53. ^ 「LZWソフトウェアと特許情報」 。 2009年6月8日時点のオリジナルよりアーカイブ。2007年1月31日閲覧。– 1999年9月2日の明確化
  54. ^ UnisysはGIFの使用に関して（ほとんどの）ウェブマスターを訴えていないArchived 10 May 2017 at the Wayback Machine – Slashdot survey to the controversy
  55. ^ “Burn All GIFs Day” . 1999年10月13日時点のオリジナルよりアーカイブ。
  56. ^ Burn All GIFs Archived 3 February 2007 at the Wayback Machine – A project of the League for Programming Freedom (最新バージョン)
  57. ^ a b c「GIFおよびその他のLZWベース技術に関するライセンス情報」 。 2009年6月2日時点のオリジナルよりアーカイブ。2005年4月26日閲覧。
  58. ^ 「なぜGNUウェブページにGIFファイルがないのか」フリーソフトウェア財団。2012年5月19日時点のオリジナルよりアーカイブ。 2012年5月19日閲覧。
  59. ^ 「PNGとGIFの圧縮」 2007年3月31日. 2009年7月15日時点のオリジナルよりアーカイブ。2009年6月8日閲覧。
  60. ^ "AlphaImageLoader Filter" . Microsoft. 2012年9月4日. 2014年10月3日時点のオリジナルよりアーカイブ。 2015年5月26日閲覧。
  61. ^ 「Internet Explorer 7の新機能」。MSDN 。 2009年3月1日時点のオリジナルよりアーカイブ。2009年3月6日閲覧。
  62. ^ “PNG画像ファイル形式” . 2009年6月14日時点のオリジナルよりアーカイブ。2009年6月8日閲覧。
  63. ^ 「HTML5、CSS3などでサポートされるテーブルを使用できますか？」 caniuse.com 。 2018年2月19日時点のオリジナルよりアーカイブ。2020年4月10日閲覧。
  64. ^ 「VOTE FAILED: APNG 20070405a」。SourceForgeメーリングリスト。2007年4月20日。2013年2月13日時点のオリジナルよりアーカイブ。 2013年7月14日閲覧。
  65. ^ 「シンプルな「アニメーション」PNG形式に関する議論」 。 2009年2月26日時点のオリジナルよりアーカイブ。2011年7月12日閲覧。
  66. ^ 「APNG仕様」。2010年7月5日時点のオリジナルよりアーカイブ。2015年5月26日閲覧。
  67. ^ 「Mozilla Labs » Blog Archive » Better animations in Firefox 3」 2007年8月13日. 2016年3月7日時点のオリジナルよりアーカイブ。 2016年2月3日閲覧。
  68. ^ “195280 – MNG/JNGサポートの削除” . 2021年2月25日時点のオリジナルよりアーカイブ。2015年5月26日閲覧。
  69. ^ “18574 – (mng) MNGアニメーション形式とJNG画像形式のサポートを復元” . 2021年3月17日時点のオリジナルよりアーカイブ。2015年5月26日閲覧。
  70. ^ 「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日閲覧。
  71. ^ Calou, Juan. 「SVGアニメーション - ガイド」 . Toptal . 2024年3月15日閲覧。
  72. ^ 「Introducing GIFV - Imgur Blog」 imgur.com、2014年10月9日。2014年12月14日時点のオリジナルよりアーカイブ。 2014年12月14日閲覧。
  73. ^ Thomson, Gavin; Shah, Athar (2017). 「HEIFとHEVCの紹介」(PDF) . Apple Inc. 2020年1月19日時点のオリジナルよりアーカイブ(PDF) . 2019年8月5日閲覧。
  74. ^ 「HEIF比較 - 高効率画像ファイルフォーマット」 Nokia Technologies . 2019年7月25日時点のオリジナルよりアーカイブ。 2019年8月5日閲覧。
  75. ^ “#3271 (libvpx-vp9 で追加のピクセル形式の使用を許可する) – FFmpeg” . trac.ffmpeg.org . 2020年6月16日時点のオリジナルよりアーカイブ。2020年4月10日閲覧。
  76. ^デューイ、ケイトリン. 「GIFを時代遅れにする可能性のあるテクノロジーとは？」ワシントン・ポスト. 2015年5月11日時点のオリジナルよりアーカイブ。 2015年2月4日閲覧。
  77. ^ 「4chanでのWebMサポート」。4chanブログ。2014年4月6日時点のオリジナルよりアーカイブ。 2015年2月4日閲覧。
  78. ^ “Introducing GIFV” . Imgur. 2014年8月9日. 2020年5月5日時点のオリジナルよりアーカイブ。 2016年7月21日閲覧。
  79. ^ Allan, Patrick (2014年10月9日). 「ImgurがGIFVでGIFを刷新し、より高速かつ高品質に」 Lifehacker . 2015年2月3日時点のオリジナルよりアーカイブ。 2015年2月4日閲覧。
  80. ^ 「GIF Revolution」。公式Telegramブログ。2016年1月4日。2016年1月10日時点のオリジナルよりアーカイブ。 2016年1月4日閲覧。
ウィキメディア コモンズには、 GIF ファイル形式に関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=GIF&oldid=1331035808」から取得