HEIF を GIF に変換

GIF は 256 色というはっきりした上限を持ちます。携帯電話のカメラの写真は数百万色を含むので、この変換は再符号化ではなく縮減です。写真に残せる 256 色を何かが決め、それ以外はすべてそのどれかで近似されます。

結果は同じ写真の JPG より劣り、たいていの写真では容量も大きくなります。何にも強制されていないなら、これは間違ったページで、JPG や PNG、WebP への変換のほうがそれぞれ別の理由でより良い答えです。このページの残りは、選択の余地がない読者のために書かれています。

CompuServe が GIF を発表したのは 1987 年で、現行仕様の GIF89a は 1989 年のものです。この古さこそがいまも残っている理由です。過去 35 年のどの時期に書かれたソフトもこれを理解でき、昔に書かれたアップロードフィルターは JPEG と並んでこれだけを挙げていることがよくあります。

この検索を生むシステムには見覚えがあります。古いメッセージボード、誰もアップグレードしていない Wiki、固定の許可リストを持つ社内チケットシステム、スプラッシュ画面のある業務用や産業用のソフト。そのどれでも、形式は議論の余地のある好みではなく、多少帯の出た GIF のほうが拒否されたアップロードより勝ります。

素朴な方法——各チャンネルを固定の格子に丸める——は、古い GIF に人々がイメージするようなポスターっぽい結果を生みます。パレットが元の画像と何の関係もないからです。この変換ツールはそれを行いません。実際に画像の中にある色からパレットを作り、色空間を分割してそれぞれの領域がどれだけ多く出現するかで重み付けします。ImageMagick が使うのと同じ系統のアルゴリズムです。

その結果、少数の色調が支配的な画像は驚くほどよく仕上がります。無地の壁を背景にしたポートレート、白背景の商品写真、スクリーンショットなどです。全スペクトルにまたがる画像——市場の屋台、紅葉、水面に沈む夕日——では 256 のエントリーでは足りず、縮減が目立ってきます。

パレットは元データの完全な精度からではなく、縮小した色空間から作られ、わずかな正確さを犠牲にして多くの時間を節約します。どのみち 256 色で終わる形式にとって、この取引は「わずかに良いパレットのために数秒待たせる」よりずっと重く「待たせない」側に傾いています。

これは期待値を正しく設定するために知っておく価値があります。これは速くて十分に良い量子化処理であって、遅くて完璧主義的なものではありません。写真の最善の 256 色表現がどうしても必要なら——古いゲーム素材の印刷用など——ディザリングのオプションを持つ専用ツールのほうが優れており、かなり時間もかかります。

帯はまずグラデーションに現れます。澄んだ空が 3、4 段の階段になり、スタジオの背景に等高線のような線が出て、頬の肌の色がまだらになります。文字や輪郭、葉といった鮮明なディテールはずっとよく耐えます。そもそもなめらかな領域ではなかったからです。

実務的な緩和策は縮小です。より小さい最大幅で変換すれば、同じ帯がより少ない画素を占めるようになり、とくに行き先が小さく表示する場合は目立たなくなります。重要な部分だけに切り抜くのも同じ理由で効果があります。256 の枠を奪い合う色の種類が減るからです。

どちらの形式も連続した画像を持てます。GIF はほとんどの人がアニメーションと結び付ける形式で、HEIF のコンテナーも複数の画像を格納できます。ただ、それはここでは役に立ちません。デコーダーはコンテナーから主画像だけを取り出し、エンコーダーはそれを 1 フレームだけ書き出します。

HEIF の連写は静止画になり、それを変える設定はありません。アニメーションを作りたいなら、必要な元データは動画です。MP4 や MOV のページがそれをカバーしており、複数フレームの本物の GIF を作れます。

HEIF は本物のアルファチャンネルを持ち、各画素は任意の度合いで透けられます。GIF 形式が提供するのは「ここは背景を透かして見せる」という意味を持つパレットエントリー 1 つだけで、このページのエンコーダーはそれを書きません。結果のすべての画素は不透明です。

代わりにアルファは解決されます。パレットが選ばれる前に、透明な部分はドロップゾーンの上にある背景色——変更しなければ白——で塗られ、アンチエイリアスされた切り抜きは、なめらかな輪郭がその色に溶け込んだ状態で単色の四角の上に着地します。同じ色のページの上では正しく見え、それ以外では違って見えます。制御できない背景の上で機能する切り抜きが必要なら、それを保つのは PNG への変換で、隣のページにあります。

GIF は LZW で圧縮し、画像を読みながらパレット索引の並びの辞書を作り、同じ並びが再び現れるたびにそのエントリーを再利用します。これは平坦な絵柄にはよく効き、写真には最悪です。量子化のあとでも隣り合う画素が完全に一致することはほとんどないからです。だからファイルは、写真の情報量が減っているにもかかわらず大きくなります。

現代のコーデックであり正反対のことをする HEIF と比べると、この差はくっきりします。もとの写真の何倍もの容量で見た目もはっきり劣る GIF になるのはよくあることです。これは変換のバグではなく、1987 年の形式に 2026 年のカメラの出力を持たせようとすると起きることです。

この形式には EXIF も XMP も GPS 座標の置き場所もなく、たとえあったとしても変換では引き継がれなかったはずです。生の画素へデコードしてから再符号化する処理には、メタデータが運ばれる余地がありません。

公開の掲示板に載せる写真にとってはこれはささやかな恩恵です。アップロードする写真は、撮影場所やどの機種で撮ったかを掲示板に語ることがなく、あとから消し忘れる手間が 1 つ減ります。

どちらの処理もブラウザーのタブの中で行われるので、何もアップロードされず、待ち行列もアカウントも不要です。無料枠の上限 100 MB は入力ファイルに対するもので、どんな携帯電話の写真もそこには届きません。フォルダーはそれぞれ進捗行を持って変換され、2 つ以上終わると「すべて ZIP で」というボタンが使えます。

HEIF は残しておいてください。256 色のパレットに収めるために捨てられた色は、GIF から再構成できません。このサイトはそもそも HEIC/HEIF を書き出すことができません。使っているデコーダーは静的サイトが守れる形でライセンスされていますが、エンコーダーはそうではないからです。GIF は、頑固な 1 つのシステムのための一方通行のコピーです。

この形式に公平でいる価値があります。それが、この変換がうまくいく場面を教えてくれるからです。GIF は少数の平坦な色でできた画像のために設計されました。インターフェース部品、図表、チャート、ロゴ、ドット絵、パレットの限られたソフトのスクリーンショットなどです。それらに対しては小さく、正確で、どこでも読めます。256 色という上限は、そもそも画像が最初からそれ以上の色を持っていないので制限になりません。

ですから自分のファイルについて問うべきなのは「これは写真か」ではなく「実際に何色を含んでいるか」です。ホワイトボードの写真、携帯電話で撮ったスクリーンショット、印刷された書類の写真。これらはカメラのコンテナーに収まっているだけの平坦な色の画像で、風景写真よりずっとうまく GIF に変換できます。

GIF を求めているように見えるシステムの多くは、実はそうではありません。GIF を最初に挙げるアップロード欄、古いヘルプページ、同僚の習慣。どれも実際の検証ルールではなく、そのルールには JPEG や PNG も含まれていることがよくあります。まず PNG を 1 回試すだけで 1 分で済み、色の縮減をまるごと避けられるかもしれません。

制限が本物である場合、たいてい特定の形で本物です。固定の画素サイズか、最大ファイルサイズか、その形式しか対応してこなかったシステムか。どれと向き合っているかによって、ここでの対応も変わります。サイズの上限なら最大幅を小さくする理由になり、形式だけの制約なら見た目がいちばん良い寸法で変換すればよいということです。