ICO を TIFF に変換

このページはまさにその場面のために存在し、最初に言っておくべきなのは、この 2 つの要求が緊張関係にあるということです。TIFF を求めるワークフローは解像度を気にします。製版、スキャン、文書アーカイブ、じっくり見られたり紙に複製されたりするものすべてです。アイコンはソフトウェアの中でもっとも意図的に小さく作られた画像で、16 ピクセルでも読めるように描かれています。

変換自体は動作し、正しいファイルを作ります。そのファイルが目的に見合うかどうかは別の問いで、数値による答えがあります。それは次の節で示します。ファイルをこの先へ進める前にその問いを確認してください。校正が戻ってきてからよりも、いま本物の素材を探すほうがずっと安上がりです。

ICO のエントリーは寸法を 1 バイトに格納し、ゼロが 256 を表します。つまり 256 ピクセルはどのアイコンファイルも持てる絶対的な最大値です。印刷は通常 300 dpi で指定され、256 を 300 で割ると 0.85 インチ、21.7 ミリメートルです。精密な仕事で使われる 600 dpi では 10.8 ミリメートルになります。

つまり、印刷されるアイコンの正直な最大サイズは切手ほどの大きさで、多くのアイコンファイルは 32 や 48 ピクセルより大きいものを持たず、それぞれ 2.7 ミリ、4.1 ミリになります。それより大きく配置すると、ぼやけは微妙どころではなくなります。表紙に 40 ミリでマークを載せる必要があるなら、アイコンではそれをまかなえず、どんな変換をしてもそれは変わりません。

TIFF は形式というより画像のためのファイリングシステムに近く、その読み手たちが合意している範囲は名前が示唆するより狭いのが実情です。LZW は特許フリーでどこでも対応していますが、Deflate はそうではなく、TIFF の中の JPEG は TIFF の皮をかぶった別の画像であり、多くの人が TIFF を求める理由そのものを損ないます。無圧縮のベースライン形式だけが、すべての読み手が受け入れる唯一の形です。

TIFF に変換する人はほぼ必ず、特定の何か——印刷機、スキャナーのソフト、取り込みフォルダー——へファイルを渡そうとしています。その鎖のどこか 1 つが拒否するファイルのコストは、ディスク容量のコストよりはるかに高くつきます。これはこの変換ツールがあなたに代わって行っている取引で、隠すのではなくここに明記しています。

この計算をしておく価値があります。ファイルの中身がわかるからです。256 ピクセルの正方形は 1 画素あたり 4 サンプルで 262,144 バイト、実測結果は 263,144 バイトで、残りの約 1 キロバイトはディレクトリとタグです。4 サンプルとは赤・緑・青・アルファのことなので、アイコンの透明度は捨てられるのではなく書き込まれています。

書き込まれることと、それが尊重されることは同じではありません。TIFF の読み手は 4 番目のサンプルの扱いにばらつきがあります。白と合成するものもあれば、選択可能なチャンネルとして提示するものもあり、無視して下の色をそのまま表示するものもあります。後者の場合、切り抜かれたアイコンは黒く見えます。透明度がうまく機能したと判断する前に、実際に使うアプリケーションで結果を開いてください。

いちばん大きいものです。ブラウザーはコンテナーをデコードして最大の画像を返します。これは 16、32、48、256 ピクセルの絵柄をそれぞれ違う色で持つアイコンを作り、ディレクトリの順序を変えて 3 回変換して確認しました。結果は毎回 256 ピクセルの絵柄でした。

これがこの行き先にとって得られる最良の結果です。TIFF のワークフローが求めているのは解像度だからです。同時に、これはアイコンから得られる限界でもあります。拡大する設定はなく、ここでの最大幅の設定は縮小にしか働きません。

このペアには皮肉なところがあります。どちらの形式も複数の画像を持てるコンテナーとして作られています。ICO は同じマークを複数のサイズで、TIFF は複数のページを持てます。だからスキャナーは 12 ページの FAX を 1 ファイルにまとめられます。原理的には、アイコンの集合全体をそのまま渡すこともできそうです。

実際にはそうなりません。デコーダーは 1 枚の絵柄だけを返し、ライターも 1 ページだけを書き出すので、4 つのエントリーを持つアイコンは単ページの TIFF になり、残り 3 つの絵柄は消えます。集合を保つことが重要なら——たとえばアーカイブの記録として——TIFF を置き換えとして扱うのではなく、元の ICO も一緒に保管してください。

TIFF は数値の並び方を示す 2 文字で始まります。リトルエンディアンなら II、ビッグエンディアンなら MM で、その後に数値の 42 が続きます。ここで書き出されるファイルは MM で始まります。どちらも正当で、どの読み手も両方を扱えますが、2 つのファイルをバイト単位で比較して片方が壊れていると誤解する原因になりがちなところです。

ヘッダーの残りは画像ファイルディレクトリへのポインターで、幅・高さ・1 画素あたりのサンプル数・ストリップのオフセットはそこにあります。この間接参照があるからこそ TIFF は複数の画像を持てますが、同時に、PNG のように最初の 4 バイトだけで確信を持って判別することができない理由でもあります。

このファイルが意味のある大きさで印刷されるなら、正しい対応は、そのアイコンの元になった素材を求めて戻ることです。アイコンは派生した資産です。どこかに SVG や AI ファイル、あるいは 256 ピクセルのエントリーが縮小される前の大きな PNG があるはずで、それなら印刷機が求めるどんな解像度の TIFF でも作れます。

アイコンだけが本当に残っている場合——古い製品、事業をたたんだベンダー、動作中のシステムから撮ったスクリーンショットなど——には、この変換で得られるのが手に入る最良のものです。そのサイズの限界は、校正の段階で発見されるのではなく、レイアウトを指定した相手に前もって伝えておくべきです。

集合ごと置けば、各ファイルは個別にデコードされ書き出され、すべてが 1 つの ZIP として戻ってきます。元のフォルダーとは違い、ZIP は大きくなると見込んでください。8 キロバイトのアイコン数十個が、それぞれ 4 分の 1 メガバイトの TIFF 数十個になり、ZIP は無圧縮の画像データをほどほどにしか圧縮できません。

アーカイブの記録としてはたいてい許容範囲で、ときにはそれこそが目的です。無圧縮のファイルには陳腐化するデコーダーがないからです。作業用の集合としては、同じ要件を 100 分の 1 の容量で満たせる PNG のほうがよいのではないかを検討する価値があります。