WebP を TIFF に変換

この組み合わせを検索する多くの人が前提にしているのは、TIFF が高品質な形式で、それに変換することはアップグレードだという考えです。TIFF はチャンネルあたり 16 ビット、CMYK、レイヤー、複数ページを何も圧縮せず保持できるという意味では確かに高品質な形式です。しかし修復ではなく、容器は捨てられたものを取り戻せません。

WebP が非可逆だった場合——ウェブサイトから配信される WebP のほぼすべてがそうです——そのエンコーダーはすでに平坦な領域をなめらかにし、硬い境界に沿ってリンギングを残しており、それらのアーティファクトは今やまさにこの絵の一部です。それはバイト数を大きく消費しながら忠実に TIFF へ書き込まれます。この変換の正直な説明は、ファイル形式の要件を満たすということです。要件が本当に画質についてのものなら、答えはこのファイルを作り直すことではなく、原本を探すことです。

チャンネルあたり 8 ビットの 4 チャンネル、非圧縮、フォトメトリック RGB、ストリップに格納され、解像度タグは 72 dpi に設定されています。非圧縮であることは省略ではなく意図的な選択です。TIFF の読み込み側は思うより一致していません。LZW は特許フリーで実質的に普遍的ですが Deflate はそうではなく、JPEG-in-TIFF は TIFF の入れ物の中に入った別種の画像です。TIFF に変換する人はたいてい特定の機械のためにデータを渡そうとしているので、素朴な非圧縮という基準線こそが、そういう機械のすべてが受け付ける唯一のものです。

その代償はサイズで、小さくはありません。1 画素あたり 4 バイトということは、1,200 万画素の画像がヘッダーを除いて約 48 MB になるということで、内容によってその数字は変わりません。このサイト自身の 480 かける 320 のサンプルは、絵の内容にかかわらず TIFF で 615,400 バイトになり、同じ写真の WebP は 14,700 バイトです。42 倍の差です。提出システムにアップロード上限があるなら、それを基準に計画してください。

TIFF の解像度フィールドは 72 dpi として書かれ、WebP には対応するフィールドがないため、そこから導き出されているわけでもありません。そのタグを読む印刷業者は低解像度のファイルだと報告し、これがこのページでいちばんよくある混乱の元です。

ある大きさで印刷できるかを実際に決めるのは画素数で、それはこの変換で変わりません。300 dpi で 10 cm 幅の印刷にはおよそ 1,180 画素、A4 全面にはおよそ 2,480 画素が必要です。提出する前に自分の画像をその数字と照らし合わせてください。ウェブページから配信される WebP は幅 800 や 1,200 画素であることが多く、小さな印刷には十分でも全面ページには足りません。タグそのものが確認されるなら、変換後に画像編集ソフトで設定してください。それはメタデータのフィールドであり、画素は一切変わりません。

TIFF は CMYK に対応しており、それが印刷ワークフローが TIFF を要求する大きな理由です。正しい ICC プロファイルを持つ CMYK の TIFF は印刷機がそのまま使えるファイルです。この変換器は RGB を書き、それ以外は書けません。画像処理パイプライン全体が 8 ビット RGB に復号するからです。

ですから仕様が「CMYK TIFF」と言っているなら、このページが作るファイルはそれを満たさず、設定を変えても変わりません。分版は、行き先のプロファイルを持つソフトで行う必要があります。Photoshop、Affinity Photo、GIMP のいずれでもできますし、印刷業者はたいてい希望するプロファイルを教えてくれます。仕様が単に「TIFF」とだけ言っているなら、RGB はほぼ常に受け入れられ、多くの提出システムが実際に期待しているものです。推測するより先に確認する価値があります。差し戻された提出はメール 1 通より高くつきます。

TIFF は第 4 チャンネルを持って書かれるので、アルファチャンネルを持つ WebP はその透明を保ったまま届きます。色付きのページの上に置いたり、あとで合成したりする作品にとってはまさに正しく、これが JPG ではなくこの経路を選ぶ理由の一つでもあります。

提出という文脈では問題になることがあります。一部のポータル、一部の印刷用 RIP、一部の古いアーカイブツールはアルファチャンネル付きの TIFF を拒否するか、アルファを想定外のスポットチャンネルとして扱って奇妙な結果を出します。要件に透明の記載がなく、画像にも必要がないなら、変換前に画像編集ソフトで白背景に平坦化してください。アルファはファイル内で非乗算ではなく乗算済みとして宣言されており、これを厳密なリーダーがあらかじめ乗算されたものと解釈することもあるため、透明が仕事の一部でないなら平坦化しておくもう一つの理由になります。

TIFF は複数ページ、レイヤー、16 ビットチャンネル、スポットカラー、ICC プロファイルを持てます。WebP にはそのどれもなく、8 ビット RGB に任意のアルファを持つ単一の画像だけです。ですから TIFF のそうした能力はどれも空のまま届きます。結果は、1 行だけのテキストファイルが文書であるのと同じ意味で TIFF です。

メタデータも引き継がれません。このサイトのすべての画像変換は生の画素に復号してから再符号化するため、WebP に含まれる EXIF、XMP、ICC のブロックはどれも落ち、この組み合わせのどの設定でも保持できません。提出物に著作権やキャプション情報の埋め込みが要求されるなら、IPTC を書けるソフトで変換後に付け足す必要があります。Photoshop、exiftool、あるいはデジタルアセット管理システムなどです。

WebP は静止画かアニメーションのどちらかを保持でき、ここで使われているデコーダーは静止画だけを読みます。アニメーションのファイルは最初のコマに変換されるのではなく、読めるメッセージとともに拒否されます。これは意図的なもので、ファイルの十分の一を静かに返す変換器は、拒否する変換器より悪いからです。

TIFF は複数画像のコンテナなので原理的にはコマを保持できますが、このパイプラインの中でコマを組み立てる仕組みはないため、そもそも問いが生じません。1 コマだけ必要なら、ブラウザーでアニメーションを開いて一時停止し、そのコマをスクリーンショットしてください。動きそのものが内容なら、WebP から GIF、または WebP から MP4 が動きを保つページです。

目的が誰もが開ける形式での正確な複製なら、WebP から PNG のほうがあらゆる面で優れています。可逆で、透明も保たれ、大きさもごくわずかで、読める側がそれを拒む余地がありません。TIFF は何かが具体的にそれを要求したときにだけバイト数に見合う価値があります。

行き先が人や普通の印刷サービスなら、WebP から JPG が期待され、問題なく扱われます。文書の提出なら、WebP から PDF が TIFF を挙げている同じポータルを満たすことが多く、しかもはるかに小さくなります。変換する前に要件をよく読んでください。「高解像度」はたいていファイル形式ではなく画素数を意味し、小さな WebP から作った TIFF は要求の文言は満たしても目的は満たしません。

WebAssembly にコンパイルされた libwebp がファイルを復号し、utif2 が TIFF を書き出します。どちらも必要になったときだけ取得され、このタブの中で動きます。アップロードはなく、画像が未発表の作品や、どこかに預けられるクライアントの資産、あるいは公開差し止め中のものであるときに意味を持ちます。

無料枠の上限は入力側で 100 MB です。ですからここでの実質的な制約はメモリーです。大きな画像は書き出す間タブの中で画素あたり数バイトを消費し、非常に大きなものはスマホでメモリー不足になり得ます。バッチも動きます。フォルダーをドロップして ZIP で受け取れますが、出力は非圧縮なので百枚のバッチはギガバイト単位の ZIP になります。グループに分けて変換するのが現実的です。