GIF 詳細情報 — フレーム数 / delay / disposal / ループ回数を可視化

GIF の内部構造が持つ情報の機微性

GIF ファイルの解析が必要になる場面は、Web から取得した GIF のフレーム構成を確認したいとき、自分が作成したアニメーションのファイルサイズを最適化したいとき、スクリーンキャプチャや画面録画を GIF に変換したものを確認するときなどです。

スクリーンキャプチャ由来の GIF には、録画時の画面内容 ——アプリの UI、ファイル名、通知、URL、パスワードフィールドの近傍 ——が各フレームのピクセルデータとして埋め込まれています。GIF のメタ情報を解析するだけという操作に見えても、ファイル自体をサーバーに送信することはデータの外部転送を意味します。

GIF 解析サービスへのアップロードが残すもの

「gif info online」「gif analyzer」で見つかるサービスは、GIF ファイルをサーバーに送信して解析結果を返します。フレーム数・遅延・ループ回数といった情報を得るだけのためにファイルを送信することになります。「解析するだけ」という用途でも、サーバー側には送信されたファイルが到達しています。

社内ツールのデモ GIF、未公開プロダクトのプロトタイプ画面、個人的なスクリーン録画 ——これらを解析目的であっても外部サービスに渡すことは避けるのが妥当です。GIF の構造解析はバイトレベルの処理であり、外部サーバーを介する必要はまったくありません。

gifuct-js によるブラウザ内 GIF パース

このツールは gifuct-js (MIT ライセンス) を使って GIF ファイルをブラウザ内でパースします。gifuct-js は GIF89a の LZW 圧縮データをデコードし、GCE (Graphic Control Extension)、LCT (Local Color Table)、Netscape Application Extension (ループ情報) などの各ブロックを JavaScript オブジェクトとして展開します。各フレームの合成サムネイルは Canvas の putImageData で生成されます。

GIF ファイルのバイト列は FileReader で読み込まれ、そのまま gifuct-js に渡されるだけで外部ネットワークには送信されません。サムネイル合成も Canvas API で完結します。DevTools の Network タブで確認すると、ページ読み込み後はリクエストが一切発生しないことが確認できます。

解析結果から読み取れるファイル最適化のヒント

フレーム数・delay・disposal method の組み合わせからファイルサイズの肥大化原因を特定できます。delay が 10ms (= stored value 1) になっているフレームが多数ある場合、実際には差分が少ないのに全フレームを保存していることがあります。LCT (Local Color Table) を持つフレームが多い場合は色数が増えてサイズが増大します。disposal method 1 (前フレームを保持) を活用することで、背景部分のデータを削減できる可能性があります。これらの解析はすべてブラウザ内で完結し、ファイルは外部に出ません。解析で特定のフレームを取り出して個別に確認・再利用したい場合は gif-frame-extract で PNG / JPEG として書き出せます。

GIF89a 仕様のバイナリレイアウト

GIF89a (CompuServe, 1989) はバイトレベルで以下の順序で並びます。最初の 6 バイトはマジックナンバー GIF89a、次に Logical Screen Descriptor (7 バイト、幅・高さ・GCT (Global Color Table) フラグ・背景色インデックスなど)、続いてオプショナルな GCT (最大 256 × 3 バイト)。その後はブロックの繰り返しで、各ブロックは Extension Introducer (0x21) または Image Separator (0x2C) または Trailer (0x3B) のいずれかから始まります。

Extension には GCE (Graphic Control Extension, ID 0xF9, 各フレームの delay と disposal method を持つ)、Application Extension (ID 0xFF, Netscape 2.0 のループ情報など)、Plain Text Extension、Comment Extension があります。Image Block は Image Descriptor (10 バイト、左上座標・幅・高さ・LCT フラグ) + オプショナルな LCT + LZW Minimum Code Size + Data Sub-blocks の構造。LZW (Lempel-Ziv-Welch, GIF 用の特殊実装) で圧縮された色インデックスを 12-bit までの可変長コードで格納します。gifuct-js はこれらすべてをパースして JavaScript オブジェクトに展開します。

delay 値とブラウザ間の挙動差 — 「ループしない」「再生が速すぎる」の典型原因

GIF の delay は GCE 内に 16-bit 値 (1/100 秒単位、最大 655.35 秒) として格納されます。ここで実装ごとの挙動差が問題になります。Firefox / Safari / Chrome は delay 値 0 または 1 (= 0ms または 10ms) を「ブラウザ既定値 100ms に置き換える」挙動を取っており、これは Internet Explorer 4 時代の互換性のための歴史的振る舞いです。ffmpeg で動画から変換した GIF が「想定より遅く再生される」現象の多くはこれが原因です。

ループ回数 (Netscape 2.0 Application Extension) は 0 が「無限ループ」、1 以上の値が「指定回数だけ再生して停止」を意味します。1 を「1 回ループ = 2 回再生」と解釈するか「1 回再生で終了」と解釈するかでブラウザ間に差があり、これも「ループしない GIF」の典型的な原因の 1 つです。本ツールで Loop count 表示を確認することで、想定挙動とのズレを特定できます。配信先プラットフォームの上限としては、Twitter / X が 15 MB、Discord が 8 MB (Nitro 50 MB)、Slack が 2 MB を目安にしており、これを超えるサイズの GIF は再生せず静止画として扱われるか、自動圧縮されます。サイズ超過が判明した場合は gif-to-mp4 で MP4 に変換すると、同等の見た目を 1/5〜1/10 のサイズで配信できることが多く、プラットフォーム制限を回避できます。