Loading article…
Graphics Interchange Format ( GIF ; / ɡɪf / GHIFまたは/ dʒɪf / JIF )は、アメリカのコンピュータ科学者スティーブ・ウィルハイトが率いるオンラインサービスプロバイダーCompuServeのチームによって開発され、1987 年 6 月 15 日にリリースされたビットマップ画像フォーマットです。 [ 1 ]
このフォーマットはピクセルあたり最大8ビットまで格納できるため、1つの画像で24ビットRGBカラースペースから選択した最大256色の独自のパレットを参照できます。また、1つのファイルで複数の画像を表現できるため、アニメーションに使用でき、各フレームごとに最大256色の個別のパレットを使用できます。このようなパレットの制限があるため、GIFはカラー写真やグラデーションのある画像の再現にはあまり適していませんが、単色領域のあるグラフィックやロゴなどのシンプルな画像には適しています。
GIF 画像は、視覚的な品質を損なわずにファイル サイズを小さくするために、Lempel–Ziv–Welch (LZW)ロスレス データ圧縮技術を使用して圧縮されます。かつては、アプリケーションやオペレーティングシステム間での幅広い実装と移植性から、ワールド ワイド ウェブで広く使用されていましたが、容量と品質の問題からその使用は減少し、静止画像にはPNG 、動画にはMP4などの新しい形式に置き換えられることが多くなっています。このような状況では、元のファイル フォーマットとは何の関係もないにもかかわらず、短いビデオ クリップが「GIF」と呼ばれることがあります。[ 3 ]
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は、Webサイトで一般的に使用される最初の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もGIFのサポートを追加し、 2018年にはInstagramもサポートを追加しました。 [ 9 ]
2016年、インターネットアーカイブは、 GeoCitiesアーカイブから検索可能なGIFライブラリを公開した。[ 10 ] [ 11 ]
As a noun, the word GIF is found in the newer editions of many dictionaries. In 2012, the American wing of the Oxford University Press recognized GIF as a verb as well, meaning "to create a GIF file", as in "GIFing was the perfect medium for sharing scenes from the Summer Olympics". The press's lexicographers voted it their word of the year, saying that GIFs have evolved into "a tool with serious applications including research and journalism".[12][13]
The pronunciation of the first letter of GIF has been disputed since the 1990s. The most common pronunciations in English are /dʒɪf/ⓘ (with a soft g as in gin) and /ɡɪf/ⓘ (with a hard g as in gift), differing in the phoneme represented by the letter G. The creators of the format pronounced the acronym GIF as /dʒɪf/, with a soft g, with Wilhite stating that he intended for the pronunciation to deliberately echo the American peanut butter brand Jif, and CompuServe employees would often quip "choosy developers choose GIF", a spoof of Jif's television commercials.[14] However, the word is widely pronounced as /ɡɪf/, with a hard g,[15] and polls have generally shown that this hard g pronunciation is more prevalent.[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年のWebby Awards授賞式で生涯功労賞を受賞した際、ウィルハイト氏は公然とハードgの発音を否定した。[ 15 ] [ 27 ] [ 28 ]彼のスピーチはTwitterで17,000件以上の投稿と数十件のニュース記事につながった。[ 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、X (旧 Twitter) [34 ]などのソーシャルメディアプラットフォームで人気があります。
概念的に言えば、GIFファイルは、0個以上の「画像」が配置された固定サイズのグラフィック領域（「論理画面」）を表します。多くのGIFファイルは、論理画面全体を埋め尽くす単一の画像で構成されています。一方、論理画面を複数のサブ画像に分割するファイルもあります。画像は、アニメーションGIFファイルではアニメーションフレームとしても機能しますが、これも必ずしも論理画面全体を埋め尽くす必要はありません。
GIFファイルは、バージョンを示す固定長ヘッダー（「GIF87a」または「GIF89a」）で始まり、続いて論理画面のピクセル寸法やその他の特性を示す固定長論理画面記述子が続きます。画面記述子には、グローバルカラーテーブル（GCT）の有無とサイズも指定される場合があり、存在する場合はその次に続きます。
その後、ファイルは1バイトの番兵によって開始される以下の種類のセグメントに分割されます。
','）'!'）';'）は、ファイルの最後のバイトであるべきです。画像は、固定長の画像記述子で始まります。この記述子では、ローカルカラーテーブルの有無とサイズを指定できます（ローカルカラーテーブルが存在する場合は、その次に続きます）。続いて画像データが続きます。まず、エンコードされていないシンボルのビット幅を示す1バイト（2色画像の場合でも、少なくとも2ビット幅である必要があります）があり、その後にLZWエンコードされたデータを含む一連のサブブロックが続きます。
拡張ブロック（87a仕様で既に定義されているメカニズムを介して87a定義を「拡張」するブロック）は、番兵、拡張の種類を指定する追加バイト、および拡張データを含む一連のサブブロックで構成されます。画像を変更する拡張ブロック（オプションのアニメーション遅延時間とオプションの透明な背景色を指定するグラフィック制御拡張など）は、参照する画像を含むセグメントの直前に配置する必要があります。
各サブブロックは、そのサブブロック内の後続データバイト数（1～255）を示す1バイトで始まります。一連のサブブロックは、空のサブブロック（0バイト）で終了します。
この構造により、ファイルの一部が理解できなくても解析が可能になります。87aとマークされたGIFファイルには拡張ブロックが含まれている場合があります。これは、デコーダーが理解できない拡張機能に含まれる機能を除いても、ファイルを読み込んで表示できるようにするためです。
ファイル形式の詳細はGIF仕様書に記載されています。[ 2 ]
GIFはパレットベースです。ファイル内の画像（フレーム）で使用される色は、最大256個のエントリを保持できるパレットテーブルでRGB値が定義され、画像のデータはパレットテーブル内のインデックス（0～255）で色を参照します。パレットの色定義は、数百万の色合い（2 24色、各原色に8ビット）を持つ色空間から抽出できますが、フレームで使用できる色の最大数は256色です。この制限は、GIFが開発された当時、256色以上を同時に表示できるハードウェアが稀だったため、妥当なものでした。単純なグラフィック、線画、漫画、グレースケール写真では、通常256色未満しか必要ありません。
各フレームは、1つのインデックスを「透明な背景色」として指定できます。このインデックスが割り当てられたピクセルは、背景の同じ位置にあるピクセルの色を取得します。この背景色は、前のフレームのアニメーションによって決定されている場合があります。
ディザリングと呼ばれる多くの技術は、2色以上のピクセルを使用して中間色を近似することで、限られたカラーパレットでより広い範囲の色を近似するために開発されてきました。これらの技術は、より深い色解像度を近似するために空間解像度を犠牲にします。ディザリングはGIF仕様の一部ではありませんが、GIF画像としてエンコードされた画像で使用できます。これは、空間解像度の低下によって画面上で画像がぼやけて見えることと、ディザリングパターンが画像データの圧縮性を妨げ、GIFの主な目的に反することの両方から、GIF画像にとって理想的な解決策ではないことがよくあります。
グラフィカルなウェブブラウザが登場した初期の頃（1981年～1987年、グラフィックス処理ユニットを参照）、8ビットバッファ（256色しか表示できない）を備えたグラフィックカードが一般的で、ウェブセーフパレットを使用してGIF画像を作成することがかなり一般的でした。これにより、予測可能な表示は保証されましたが、色の選択肢は大幅に制限されました。24ビットカラーが標準になると、パレットには個々の画像に最適な色を設定できるようになりました。
小さな画像であれば、小さなカラーテーブルで十分な場合があり、カラーテーブルを小さくすることでファイルのダウンロード速度が向上します。87a および 89a の仕様では、nが 1 から 8 までの任意の値に対して、2 n色のカラーテーブルが認められています。ほとんどのグラフィックアプリケーションは、これらのテーブルサイズのいずれかで GIF 画像を読み込んで表示できますが、画像を作成する際にすべてのサイズをサポートしていないアプリケーションもあります。2、16、および 256 色のテーブルは広くサポートされています。
GIF は真のカラー画像にはほとんど使用されませんが、そうすることも可能です。[ 35 ] [ 36 ] GIF 画像は複数の画像ブロックを含むことができ、各画像ブロックは独自の 256 色のパレットを持つことができ、ブロックをタイル状に並べて完全な画像を作成できます。あるいは、GIF89a 仕様では、「透明」色の概念が導入され、各画像ブロックは 255 色の可視色と 1 つの透明色のパレットを持つことができます。画像ブロックを重ねることで完全な画像を作成でき、各レイヤーの可視部分は上のレイヤーの透明部分を通して表示されます。
フルカラー画像を GIF としてレンダリングするには、元の画像を 255 色または 256 色以下の小さな領域に分割する必要があります。これらの各領域は、独自のローカルパレットを持つ個別の画像ブロックとして保存され、画像ブロックが一緒に表示されると (タイル状に並べるか、部分的に透明な画像ブロックを重ね合わせることによって)、完全なフルカラー画像が表示されます。たとえば、画像を 16 x 16 ピクセル (合計 256 ピクセル) のタイルに分割すると、どのタイルもローカルパレットの制限である 256 色を超えることはありませんが、より大きなタイルを使用して類似の色が統合され、色情報が一部失われる可能性があります。[ 35 ]
各画像ブロックは独自のローカルカラーテーブルを持つことができるため、画像ブロックが多いGIFファイルは非常に大きくなる可能性があり、フルカラーGIFの有用性が制限されます。[ 36 ]さらに、すべてのGIFレンダリングプログラムがタイル画像やレイヤー画像を正しく処理するわけではありません。多くのレンダリングプログラムは、タイルやレイヤーをアニメーションフレームとして解釈し、アニメーションとして順番に表示します[ 35 ]。ほとんどのWebブラウザは、フレームを0.1秒以上の遅延時間で自動的に表示します。[ 37 ] [ 38 ]
以下の表の16進数は、フォーマット仕様で規定されているとおり、リトルエンディアンのバイト順になっています。
左上から水平方向にスキャンされた画像ピクセルデータは、LZWエンコーディングによってコードに変換され、その後、ファイルに格納するためにバイトにマッピングされます。ピクセルコードは通常、バイトの8ビットサイズと一致しないため、コードは「リトルエンディアン」方式でバイトにパックされます。最初のコードの最下位ビットは最初のバイトの最下位ビットに格納され、コードの上位ビットはバイトの上位ビットに格納され、必要に応じて次のバイトの下位ビットに溢れ出します。後続の各コードは、まだ使用されていない最下位ビットから格納されます。
このバイトストリームは、ファイル内に「サブブロック」のシリーズとして格納されます。各サブブロックの最大長は255バイトで、サブブロック内のデータバイト数を示すバイトが先頭に付加されます。サブブロックのシリーズは、空のサブブロック（データバイト数が0バイトであることを示す単一の0バイト）で終了します。
上記のサンプル画像について、9ビットコードとバイト間の可逆的なマッピングを以下に示します。
わずかな圧縮が見られます。最初に 15 バイトで定義されたピクセルカラーは、制御コードを含めて正確に 12 バイトのコードで表現されます。9 ビットコードを生成するエンコード処理を以下に示します。ローカル文字列は、コードテーブルにローカル文字列が見つかる限り、出力アクションなしでパレットからピクセルカラー番号を蓄積します。テーブルが文字列の追加によって初期サイズから拡張される前に到着する最初の 2 つのピクセルには特別な処理があります。各出力コードの後に、ローカル文字列は最新のピクセルカラー (出力コードに含まれなかった色) で初期化されます。
テーブル 9 ビット文字列 --> コード コード アクション #0 | 000h 9ビットコードのルートテーブルを初期化します パレット | : 色 | : #255 | 0FFh clr | 100時間 終了 | 101時間 | 100時間クリア ピクセルローカル | カラーパレット文字列 | ブラック #40 28 | 028h 1番目のピクセルは常に出力されます ホワイト #255 FF | テーブル内で見つかった文字列 28 FF | 102h 常に最初の文字列をテーブルに追加します FF | ローカル文字列を初期化する ホワイト #255 FF FF | テーブルに文字列が見つかりません | 0FFh - 前の文字列の出力コード FF FF | 103h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化します ホワイト #255 FF FF | テーブル内で見つかった文字列 ブラック #40 FF FF 28 | テーブルに文字列が見つかりません | 103h - 前の文字列の出力コード FF FF 28 | 104時間 - 最新の文字列をテーブルに追加 28 | - ローカル文字列を初期化する ホワイト #255 28 FF | テーブル内で文字列が見つかりました ホワイト #255 28 FF FF | テーブルに文字列が見つかりません | 102h - 前の文字列の出力コード 28 FF FF | 105h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化します ホワイト #255 FF FF | テーブル内で見つかった文字列 ホワイト #255 FF FF FF | テーブルに文字列が見つかりません | 103h - 前の文字列の出力コード FF FF FF | 106時間 - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化します ホワイト #255 FF FF | テーブル内で見つかった文字列 ホワイト #255 FF FF FF | テーブル内で見つかった文字列 ホワイト #255 FF FF FF FF | テーブルに文字列が見つかりません | 106h - 前の文字列の出力コード FF FF FF FF| 107h - 最新の文字列をテーブルに追加 FF | - ローカル文字列を初期化します ホワイト #255 FF FF | テーブル内で見つかった文字列 ホワイト #255 FF FF FF | テーブル内で見つかった文字列 ホワイト #255 FF FF FF FF | テーブル内で見つかった文字列 ピクセルはもう不要 107h - 最後の文字列の出力コード 101時間終了
分かりやすくするために、上の表は長さが徐々に長くなる文字列で構成されているものとして示されています。この方式でも機能しますが、表が消費するメモリ量は予測不可能です。実際には、格納する新しい文字列は、以前に格納された文字列に1文字を追加したもので構成されていることに着目することで、メモリを節約できます。各アドレスには、既存のアドレスと1文字の2つのワードだけを格納するのが効率的です。
The LZW algorithm requires a search of the table for each pixel. A linear search through up to 4096 addresses would make the coding slow. In practice, the codes can be stored in order of numerical value; this allows each search to be done by a SAR (Successive Approximation Register, as used in some ADCs), with only 12 magnitude comparisons. For this efficiency, an extra table is needed to convert between codes and actual memory addresses; the extra table upkeep is needed only when a new code is stored, which happens at a much lower rate than pixel rate.
Decoding begins by mapping the stored bytes back to 9-bit codes. These are decoded to recover the pixel colors as shown below. A table identical to the one used in the encoder is built by adding strings according to this rule:
shift9-bit ----> Local Table Pixelcode code code --> string Palette color Action 100h 000h | #0 Initialize root table of 9-bit codes : | palette : | colors 0FFh | #255 100h | clr 101h | end 028h | #40 BLACK Decode 1st pixel 0FFh 028h | Incoming code found in table | #255 WHITE - output string from table 102h | 28 FF - add to table 103h 0FFh | Incoming code not found in table 103h | FF FF - add to table | - output string from table | #255 WHITE | #255 WHITE 102h 103h | Incoming code found in table | - output string from table | #40 BLACK | #255 WHITE 104h | FF FF 28 - add to table 103h 102h | Incoming code found in table | - output string from table | #255 WHITE | #255 WHITE 105h | 28 FF FF - add to table 106h 103h | Incoming code not found in table 106h | FF FF FF - add to table | - output string from table | #255 WHITE | #255 WHITE | #255 WHITE 107h 106h | テーブルに受信コードが見つかりません 107時間 | FF FF FF FF - テーブルに追加 | - テーブルからの出力文字列 | #255 ホワイト | #255 ホワイト | #255 ホワイト | #255 ホワイト 101時間 | 終了
例の 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になります。
コードテーブルには、初期状態ではシンボルサイズより1ビット長いコードが格納されています。これは、特殊コードであるclrとend、および処理中に追加される文字列のコードを格納するためです。テーブルがいっぱいになると、より多くの文字列を格納するスペースを確保するためにコード長が拡張され、最大で4095（FFF（16進数））まで拡張されます。デコーダはテーブルを構築する際に、このコード長の拡張を追跡し、入力バイトを適切に展開することができます。
GIFエンコード処理は、LZW圧縮を行わないファイルでもGIF画像として表示できるように変更することができます。この手法はもともと特許侵害を回避するために導入されました。非圧縮GIFは、個々のピクセルにアクセスして読み取ったり描画したりできるため、グラフィックプログラマーにとって便利な中間フォーマットにもなります。非圧縮GIFファイルは、画像エディタを通すだけで通常のGIFファイルに変換できます。
変更されたエンコード方式では、LZW テーブルの構築を無視し、ルートパレットコードと CLEAR および STOP のコードのみを出力します。これにより、エンコードはよりシンプルになります (コード値とパレットコードが 1 対 1 で対応) が、圧縮はすべて失われます。画像内の各ピクセルは、そのカラーインデックスを示す出力コードを生成します。非圧縮 GIF を処理する場合、標準の GIF デコーダーは辞書テーブルに文字列を書き込むことを妨げられませんが、コード幅はビットからバイトへの異なるパッキングを引き起こすため、決して増やしてはなりません。
シンボル幅がnの場合、幅n + 1のコードは自然に 2 つのブロックに分けられます。1 つのブロックは単一シンボルを符号化するための2 n個のコードからなる下側のブロック、もう1 より大きい長さのシーケンスにデコーダが使用する2 n個のコードからなる上側のブロックです。この上側のブロックのうち、最初の 2 つのコードは既に使用されています。2 nは CLEAR 用、2 n + 1は STOP 用です。デコーダは上側のブロックの最後のコード 2 n + 1 − 1 も使用できないようにする必要があります。デコーダがそのスロットを埋めると、コード幅が増加するためです。したがって、上側のブロック k には、コード幅の増加を引き起こさない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
上記のコードをバイト列にマッピングした後、非圧縮ファイルは圧縮ファイルと以下のように異なります。
単色の大きな画像という単純な例は、GIFファイルで使用されている可変長LZW圧縮方式を実証するものである。
表示されるコード値はバイトにパックされ、さらに最大255バイトのブロックにパックされます。画像データのブロックは、続くバイト数を宣言するバイトで始まります。画像の最後のデータブロックは、ブロック長ゼロのバイトで示されます。
GIF仕様では、GIFファイルの論理画面内の各画像がインターレース方式であることを指定できます。つまり、データブロック内のラスタ線の順序が連続していないことを指定できます。これにより、画像全体が描画される前に、画像の一部を表示して認識することが可能になります。
インターレース画像は上から下まで高さ8ピクセルの帯状に分割され、画像の行は次の順序で表示されます。
各行内のピクセルはインターレースされておらず、左から右へ連続して表示されます。非インターレース画像と同様に、1行のデータと次の行のデータの間には途切れがありません。画像がインターレースであることを示すインジケータは、対応する画像記述子ブロック内の特定のビットです。
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」の構造を示しています。
各フレームのアニメーション遅延時間は、GCEで100分の1秒単位で指定されます。画像記述子が画像全体ではなく、より小さな矩形領域を再スキャンするように定義できるため、フレームがディスプレイ上のピクセルの一部だけを書き換えるだけで済む場合、データ量の削減が可能になります。アニメーションGIFをサポートしていないブラウザやその他のディスプレイでは、通常、最初のフレームのみが表示されます。
アニメーションGIFファイルのサイズと色品質は、作成に使用するアプリケーションによって大きく異なります。ファイルサイズを最小限に抑える方法としては、すべてのフレームに共通のグローバルカラーテーブルを使用する（各フレームに完全なローカルカラーテーブルを使用するのではなく）、連続するフレームでカバーされるピクセル数を最小限に抑える（あるフレームから次のフレームに変化するピクセルのみが含まれるようにする）などが挙げられます。より高度なテクニックとしては、既存のLZW辞書に合うようにカラーシーケンスを変更する（これは一種の非可逆圧縮です）方法があります。独立したフレーム画像を単純に合成アニメーションにパックすると、ファイルサイズが大きくなる傾向があります。既存のGIFファイルのサイズを最小限に抑えるためのツールも利用可能です。
メタデータは、コメントブロック、プレーンテキストブロック、またはアプリケーション固有のアプリケーション拡張ブロックとしてGIFファイルに保存できます。いくつかのグラフィックエディタは、非公式のアプリケーション拡張ブロックを使用して画像生成に使用されたデータを含め、後で編集できるようにしています。
これらの方法はすべて、技術的にはメタデータをサブブロックに分割する必要があり、そうすることでアプリケーションはメタデータブロックの内部構造を知らなくてもそのブロックをナビゲートできるようになります。
拡張メタデータプラットフォーム（XMP）メタデータ標準では、GIF ファイルに XMP データを含めるための、非公式ながら現在では広く使われている「XMP データ」アプリケーション拡張ブロックが導入されました。[ 41 ] XMP データはNUL 文字を含まないUTF-8を使用してエンコードされているため、データには 0 バイトはありません。データを正式なサブブロックに分割するのではなく、拡張ブロックは「マジック トレーラー」で終了し、データをサブブロックとして扱うアプリケーションをサブブロック チェーンを終了する最後の 0 バイトにルーティングします。
1977年と1978年に、Jacob ZivとAbraham Lempelは、現在LZ77とLZ78と総称される新しいクラスの可逆データ圧縮アルゴリズムに関する2つの論文を発表しました。1983年、Terry WelchはLZ78の高速版を開発し、 Lempel–Ziv–Welch （LZW）と名付けました。[ 42 ] [ 43 ]
ウェルチは1983年6月にLZW法の特許出願を行った。その結果、1985年12月に付与された特許US4558302 [ 44 ]は、スペリー社に譲渡され、スペリー社はその後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の使用を中止すると脅迫した。PNG形式（下記参照）は、代替として1995年に開発された。[ 42 ] [ 43 ] [ 49 ]しかし、PNG形式に対するWebブラウザやその他のソフトウェアのメーカーからのサポートを得ることは困難であることが判明し、PNGの人気が徐々に高まったにもかかわらず、GIFを置き換えることは不可能であった。[ 42 ]そのため、LZW圧縮を使用しないGIFのバリエーションが開発された。たとえば、Eric S. Raymondのgiflibに基づくlibungifライブラリは、データ形式に従うが圧縮機能を回避したGIFを作成することを可能にし、UnisysのLZW特許の使用を回避している。[ 51 ] 2001年のDr. Dobb'sの記事では、特許を侵害することなく、ランレングス符号化メカニズムの下でうまく圧縮されるデータに対してLZW互換の符号化を実現する方法が説明されている。[ 52 ]
1999 年 8 月、Unisys はライセンス慣行の詳細を変更し、特定の非営利および個人用 Web サイトの所有者が 5,000 ドルまたは 7,500 ドルの 1 回限りのライセンス料を支払うことでライセンスを取得できるオプションを発表しました。[ 53 ]このようなライセンスは、ライセンスされたソフトウェアを使用して GIF を生成した Web サイトの所有者やその他の GIF ユーザーには必要ありませんでした。それにもかかわらず、Unisys は、Web サイトで GIF を使用したことで 5,000 ドルを請求されるか訴訟を起こされると信じたユーザーから、何千ものオンライン攻撃と嫌がらせのメールを受けました。[ 54 ]数百の非営利団体、学校、政府に無料ライセンスを提供したにもかかわらず、Unisys は全く良い宣伝効果を得ることができず、1999 年に「すべての GIF を燃やせ」キャンペーンを開始したLeague for Programming Freedomなどの個人や団体から非難され続けました。 [ 55 ] [ 56 ]
米国のLZW特許は2003年6月20日に失効した。[ 57 ]英国、フランス、ドイツ、イタリアの対応する特許は2004年6月18日に失効し、日本の特許は2004年6月20日に失効し、カナダの特許は2004年7月7日に失効した。[ 57 ]その結果、UnisysはLZW技術の改良に関するさらなる特許および特許出願を保有しているが、[ 57 ] LZW自体（そして結果としてGIF）は2004年7月以降自由に使用できるようになった。[ 58 ]
ポータブルネットワークグラフィックス（PNG）は、UnisysのLZW圧縮技術に関する特許の侵害を避けるために、GIFの代替として設計されました。[ 42 ] PNGはGIFよりも優れた圧縮と多くの機能を提供しますが、[ 59 ]アニメーションは唯一の重要な例外です。PNGは、真の色画像とアルファ透明度が必要な場合にGIFよりも適しています。
PNG形式への対応は徐々に進みましたが、新しいWebブラウザはPNGをサポートしています。古いバージョンのInternet ExplorerはPNGのすべての機能をサポートしていません。バージョン6以前では、 Microsoft固有のHTML拡張機能を使用しない限り、アルファチャンネルの透明度をサポートしていません。 [ 60 ] PNG画像のガンマ補正はバージョン8より前にはサポートされておらず、以前のバージョンではこれらの画像の表示に色味の誤りがある可能性があります。[ 61 ]
同一の 8 ビット (またはそれ以下) の画像データの場合、PNG ファイルは、PNG エンコードで使用されるより効率的な圧縮技術のため、通常は同等の GIF よりも小さくなります。[ 62 ] GIF の完全なサポートは、主にそれが可能にする複雑なキャンバス構造によって複雑になりますが、これがコンパクトなアニメーション機能を可能にするものです。
動画は、ウェブ上での一般的な使用においてGIFが抱える多くの問題を解決します。具体的には、ファイルサイズが大幅に小さくなること、 8ビットカラーの制限を超えることができること、フレーム間符号化によってフレーム処理と圧縮が優れていることなどが挙げられます。ウェブブラウザにおけるGIFフォーマットのほぼ普遍的なサポートと、 HTML標準における動画の公式サポートの欠如により、GIFはウェブ上で短い動画のようなファイルを表示する目的で広く普及しました。
<video>、一部のウェブサイトでは、生成されたvideoタグのループ再生バージョンが使用されています。これにより、GIFのような見た目になりますが、圧縮ビデオならではのサイズと速度のメリットが得られます。2014 年 4 月、4chan はサイズが 3 MB 未満で長さが 2 分未満の無音WebM動画のサポートを追加しました。 [ 76 ] [ 77 ]また、2014 年 10 月、Imgur はサイトにアップロードされたすべての GIF ファイルをH.264動画に変換し、HTML プレーヤーへのリンクに.gifv拡張子付きの実際のファイルのような外観を与えるようになりました。[ 78 ] [ 79 ]
2016年1月、TelegramはすべてのGIFをMPEG-4ビデオに再エンコードし始めました。これにより、「同じ画質で最大95%少ないディスク容量で済む」ようになりました。[ 80 ]
{{cite web}}: CS1 maint: url-status (リンク)