GIF を ICO に変換

ロゴの GIF は、ほとんどの場合ロゴそのものではありません。ある Web ページのために、そのページが必要とした大きさで一度だけ書き出され、256 色に減色され、しばしば大きな元データから縮小されたものです。どこかに元のデータがあることが多いです。Illustrator のファイル、SVG、ブランドフォルダーの中の高解像度 PNG などです。

5 分探す価値があります。ベクターの素材から作ったアイコンなら、16 ピクセルの大きさでもストロークを太くして描き直せて読みやすく保てますが、120 ピクセルの GIF から作ったアイコンではそれができません。何年もオーナーが変わっていないサイトなどでは探しても見つからないことがよくあり、その場合はこの変換が妥当な代替案です。このページの残りは、それをうまく機能させる方法についてです。

ICO はコンテナーです。Microsoft は 1985 年に、同じ絵柄を複数のサイズでまとめて持たせ、Windows が一覧表示には 16 ピクセル、デスクトップには 32 ピクセル、プレビューには 256 ピクセルを、何も拡大縮小せずに選べるようにするために設計しました。これがいまも他のアイコン形式に対するこの形式の主な優位性であり、1985 年生まれの形式が 2026 年になってもブラウザーから求められている理由です。

この変換が書き出すのはその集合です。ディレクトリには選んだサイズごとに 1 つのエントリーが入ります。既定では 48、32、16 ピクセルの 3 つで、それぞれそのサイズで作られた本物の PNG として、大きい順に並びます。下流の誰も推測する必要がありません。16 ピクセルのタブを描くブラウザーはディレクトリを読み、16 ピクセルの版をそのまま使います。GIF にとってはこれは見た目以上に良い結果です。小さな古いロゴを 256 まで拡大してからブラウザーが縮小し直す経路こそ、古いマークを灰色のにじみに変えてしまう典型的な経路だからです。

GIF の長辺が 256 ピクセルを超えている場合、ちょうど 256 になるまで縮小され、短辺はそれに比例して従います。各アイコンのエントリーはそこから作られるので、既定の組み合わせでは 400 ピクセルのロゴが 48、32、16 になります。求めたサイズより GIF のほうが小さい場合は拡大されて埋められます。これが元データより結果を悪くする唯一の経路です。90 ピクセルのロゴを「256 px のみ」で変換すると、90 ピクセルのロゴを引き伸ばしただけのものになります。

この上限は方針ではなく形式そのものの制約です。ICO のディレクトリエントリは各寸法を 1 バイトに格納するため、256 はその欄に収まらずゼロとして書かれます。仕様ではそれが 256 を表す書き方です。それより大きい値は記録する場所がなく、どのアイコン制作ツールもこの同じ数字で止まる理由です。

ここで書き出される各エントリーは正方形です。アイコンとはそういうものだからです。240×64 のワードマークの GIF は縦横比を保ったまま、収まる最大の縮尺で正方形の中央に置かれ、上下の帯は透明で埋められます。何も引き伸ばされません。これが重要な半分です。引き伸ばされたロゴは離れて見ても一目で失敗とわかります。

もう半分には代償が伴います。240×64 のマークが 16 ピクセルの正方形の中央に置かれると、高さはわずか 4 ピクセルほどになり、透明な帯の部分はアイコンとして無駄になります。ですから先に正方形へ切り抜いてください。縮小ではなく切り抜きです。頭文字やシンボル、モノグラムを取り出して中央に置き、与えられた枠を使い切るよう余白を最小限にしてください。

ディレクトリの各エントリーは PNG です。この形式は生のビットマップのデータも許していて——それが本来の意味でした——ですが Vista 以降のすべての Windows は ICO の中の PNG を読め、ファイルは容量が小さく、アルファチャンネルも 1 ビットのマスクではなく本物のものになります。この選択が、暗いタブバーの上でもアイコンが正しく見える理由です。

これがこのページに画質設定がない理由でもあります。PNG は可逆で調整するものが何もないので、スライダーがあっても動かすだけで何も変わりません。用意されていないのがいちばん正直なやり方です。うれしい副作用として、小さいエントリーを複数持つほうが大きいエントリー 1 つより容量が小さくなります。平坦なロゴで測定したところ、48・32・16 ピクセルの 3 つの PNG は合計 1,062 バイトで、このページがかつて書き出していた 256 ピクセル単独の 2,229 バイトを下回りました。より良いファビコンがより小さいファイルで手に入ります。

GIF の透明度はパレットの 1 エントリーを透けて見えるものとして印を付けただけのものです。1 画素は完全に透明か完全に不透明かのどちらかで、その中間はありません。ロゴの曲線周りのアンチエイリアスは、その GIF が置かれる想定だった背景に合わせて焼き込まれています。

32 ピクセルまで縮小すると、それが表面化します。白い背景に合わせてアンチエイリアスされたロゴの淡いハローは、暗いブラウザーのテーマの上でもそのまま淡いままで、清潔なマークではなく汚れた輪郭のように見えます。これを取り除く設定はありません。その縁の画素が本来どうあるべきだったかという情報は、GIF が作られた時点で失われているからです。ハローが目立つほどひどいなら、変換の設定を変えるのではなく、元データから描き直すのが正しい直し方です。

GIF を写真向きでない形式にしているパレット数の制限は、ここではほとんど関係ありません。ロゴは設計上、平坦な色で構成されています——2、3 種類の塗り、硬い輪郭、グラデーションなし——ので 256 色もあれば十分すぎるほどで、GIF はマークを描かれたとおりほぼそのまま保持しているはずです。

本当の制約は画素の寸法です。アイコンは 16 ピクセルや 32 ピクセルで判断され、そこで重要なのは形がまだ見分けられるかどうかです。細いセリフは消え、2 単語のワードマークは消え、しっかりした幾何学的なシンボルは残ります。ほとんどの人が最初の試みで犯す間違いは、ファイルそのものではなく実際のタブを見て確認しないことです。

現代的な実践は、ページのヘッダーに宣言された PNG の一式と SVG アイコンを使う方法で、それには相応の理由があります。ですがルートパスにあるファイルは、宣言を見つけられなかったブラウザーや、フィードリーダー、リンクのプレビュー、そしてこれしか仕組みがなかった時代に書かれた数多くのツールから、いまも求められています。それらすべてを満たすのに 1 ファイルで済みます。

ですから実務的な配置は両方です。ルートに置く ICO を万能のフォールバックとして持ちつつ、サイトのテンプレートが対応している現代的な宣言も並行して用意します。ここで GIF を変換すれば、その前者を 1 ステップで手に入れられます。しかもそれは、他に何も設定されていなくても機能し続ける半分です。

GIF はブラウザーがデコードし、絵柄は PNG として符号化され、アイコンのディレクトリは同じタブの中で JavaScript によってその周りに書き込まれます。サーバーには何も届かず、アカウントも不要で、変換とダウンロードの間に透かしも登録手続きもありません。

ロゴにとってこれはたいてい些細な点ですが、ときに本当に重要な点でもあります。禁輸中のブランド資産、社内ツールのマーク、契約のもとで送られたクライアントの素材。そのどれも、アイコンになるために他の誰かを経由する必要はありません。