TIFF を JXL に変換

このペアが検索される理由はもっともです。JPEG XL は本当にアーカイブ候補として強力な形式です。1 チャンネルあたり最大 32 ビットを保存でき、本物の可逆モードを持ち、広色域に対応し、同じ分類のどの形式より圧縮率が優れています。いくつかの国立図書館がまさにその理由でこの形式を真剣に検討したこともあります。

ただし、この変換ツールを通してはそのどれも届きません。間に挟まるパイプラインが 8 ビット RGB で、エンコーダーは画質の数値だけで動くからです。手に入るのは小さくて見た目のよい非可逆な派生版であって、多くの用途に便利ではあってもマスターではありません。アーカイブ用のコピーはビット単位で正確で、フルビット深度を保ち、カラーマネジメントされている必要がありますが、この経路はそのどれも満たしません。コレクションが大切なら TIFF を保ち、このページから出てくるものは、同じスキャンの JPG を扱うのと同じ扱いにしてください。

画質の設定は 100 まであり、上限付近ではエンコーダーの挙動が変わるので、思い込むより数字が何を買うのかを知っておく価値があります。このサイト自身のエンコーダーで 256×256 のテスト画像を測定したところ、既定の 82 ではグラデーションの 262,144 サンプル中 73,647 個が変化し、最大で 21 段階ずれました。100 では 334 サンプルだけが変化し、いずれも 1 段階以内でした。平坦な絵柄は 100 でビット単位で完全に一致しました。

これは可逆ではなくほぼ可逆であり、アーカイブにとっては意味のある違いで、単なる証明としてはどうでもよい違いです。実務的には、見るためだけのファイルなら 82 のままにし、あとで再符号化するワークフローに渡すなら 100 に設定し、目録の記録の中で結果を可逆コピーと表現しないでください。エンコーダー本体には専用の可逆モードが存在しますが、この変換ツールはそれを外に出していません。

非常に多くの TIFF が 16 ビットで、それこそが TIFF でスキャンする意味の大部分であり、後から階調やカーブを調整する余地をスキャンに与えるものです。ここで使われている読み込み処理は 16 ビットのファイルを正しくデコードしたうえで、各サンプルの上位バイトだけを残して 1 チャンネル 8 ビットに渡します。16 ビットのグレースケール TIFF で測定すると、格納値 30,000 は 117 として届きます。

仕上がった画像を見るだけなら誰も違いに気づきません。画面は 8 ビットしか表示しませんし、目もそれ以上を区別できません。編集用のマスターにとってはこれがすべての違いです。強いカーブ調整に耐えるなめらかな 16 ビットのグラデーションこそ捨てられたもので、8 ビットの結果に階調を強くかけるとバンディングが出ます。意図的に 16 ビットでスキャンしたなら、その判断はこのページを通り抜けられません。

印刷用のワークフローから来た TIFF は、しばしば ICC プロファイルの付いた CMYK で、この 2 つがそろって初めて印刷可能になります。ここでの読み込み処理は、埋め込まれたプロファイルを経由せず固定の式で CMYK を画面用の色へ変換するので、結果は同じ写真だとわかるものの色がわずかにずれます。たいてい深い影が平板になり、プロファイルが補正していたはずのところがやや寒色寄りになります。

プロファイル自体も運ばれません。このサイトのすべての画像変換は生の画素へデコードしてから再符号化するので、ICC、EXIF、XMP、IPTC、GPS のブロックはすべて無条件で失われ、ページが選ばせてくれる話ではありません。印刷用素材にとっては本当の損失で、これをアーカイブへの移行として扱うべきでない 2 つ目の理由です。画面で見るだけの画像にとってはコストになりません。

TIFF は 1 ファイルに複数の画像を持て、文書スキャナーはそれを当然のように使います。ここで作られる JPEG XL は 1 枚しか持ちません。読み込み処理は先頭ページを取ってそこで止まり、エラーも出さず、2 ページ目以降が存在したことを示す表示もインターフェースにはありません。

これがこの変換がコレクション全体を静かに損なう唯一の経路で、バッチのあとではなく前に確認しておく価値があります。文書スキャナーや FAX ゲートウェイ、記録管理システムから来た TIFF なら、複数ページである可能性を前提にいくつか開いてみてください。分割は ImageMagick で 1 行、IrfanView ならメニュー 1 つで済みます。ページをひとまとめにしておきたいなら、TIFF から PDF への変換がすべてを 1 ファイルに保つ道です。

出発点が無圧縮なので、非常に小さくなります。このサイト自身のサンプルは 480×320 でどれも TIFF として 615,400 バイトですが、既定の画質での JXL では、写真で 7,240 バイト、スクリーンショットのような場面で 13,252 バイト、平坦なグラフィックで 5,016 バイトになります。

写真の数字が興味深いところです。7,240 バイトはそのサンプル集合の中でどの形式よりも小さく、WebP の 14,700 バイトや AVIF の 17,599 バイトを下回ります。この画質での連続階調において、JPEG XL は 3 つの中でもっとも強力なコーデックであり、問題がバイト数と画質の比率だけなら、これが勝者です。ただしその問いだけで済むことはめったになく、それが次の節の話です。

ここで JPEG XL が不利になる場面で、この形式が「現行」ではなく「ニッチ」に分類されている理由でもあります。ブラウザーの対応は万能ではなく部分的なので、.jxl は相手の環境を確認せずに Web ページに置いたりメールに添付したりするファイルではありません。GIMP と ImageMagick は扱えますが、Photoshop はプラグインが必要で、普通のソフトの多くは単に見慣れないファイルのアイコンを表示します。

この事実によって、正直な用途は 2 つに絞られます。1 つは閉じたワークフロー——自分のツール、自分のストレージ、この形式を名指しするパイプライン。もう 1 つは、オリジナルを別の場所に安全に保管したうえで意図的に実験する人です。話したこともない相手が開かなければならないファイルなら、WebP や JPG、PNG にすべきで、それぞれの兄弟ページがこの 3 つをすべて扱っています。

正確さを保ったまま小さなアーカイブ用コピーが目的なら、TIFF から PNG への変換がその考えを正直に実現します。PNG は 8 ビットの範囲内で可逆で、地球上のあらゆるソフトが読め、平坦なスキャン素材ではしばしば高画質の非可逆ファイルより小さくなります。16 ビットは保てません——ここではどの経路も保てません——が、それ以外は何も失いません。

公開が目的なら、TIFF から WebP への変換はすべてのブラウザーで動き、TIFF から AVIF への変換は平坦なスキャン素材でより小さく画素の上限も高くなります。スキャンを人に送るのが目的なら、TIFF から PDF や TIFF から JPG が相手の期待するものです。そして本当のアーカイブ用マスターが目的なら、正しい答えは誰も好まないものです。すでに持っている TIFF こそがアーカイブ用マスターであり、それを保管すべきだということです。

utif2 が TIFF をデコードし、WebAssembly にコンパイルされた libjxl が JXL を書き出します。どちらも必要になったときだけ取得されます。ファイルについての何もネットワークを越えないので、未公開または制限された素材にこのページを使えるのは、この点があるからです。無料枠の上限は 1 ファイルあたり 100 MB で、600 dpi の A4 カラースキャンを無圧縮で保存したものにおおむね相当します。

バッチも同じように動きます。フォルダーを置けば各ファイルが自分の進捗行を持ち、結果は ZIP として戻ってきます。JPEG XL の符号化は AVIF ほど遅くはありませんが、瞬時でもありません。大きな処理は始めてから離れておく価値があります。エンジンは 1 回だけダウンロードされ、バッチの残りで使い回されます。