TIFF を AVIF に変換

これが、TIFF から WebP へではなくこちらのページにいる具体的な理由です。WebP は縦横の大きさを14ビットで記録するため、どちらの辺も 16,383 ピクセルを超えられません。ここで使っているエンコーダーで確かめると、16,383 ピクセルはそのまま書き出せ、16,384 ピクセルでは失敗します。AVIF の上限は 65,536 ピクセルです。

スキャンはこの数字に日常的に届きます。写真はまず届きません。600 dpi で取り込んだ A1 の図面はおよそ 14,000 × 19,900 ピクセル、400 dpi の A0 はおよそ 13,200 × 18,700、1,200 dpi で読んだ A3 はおよそ 14,000 × 19,800 で、どれも WebP の上限を超えています。スキャンの目的が細部を残すことだったなら、その入れ物に収めるために半分に縮めさせられるのは実質的な損失であり、AVIF はその損失を取り除きます。

もう一つの理由は圧縮効率で、内容によって結果が変わるので、思い込まずに測る価値があります。このサイトの三種類のサンプル画像を、このページと同じ経路で 480 × 320 に符号化した結果はこうです。スクリーンショットに近い画面は AVIF で 5,081 バイト、WebP で 10,830 バイト。平坦なグラフィックは 3,494 バイトに対して 4,428 バイト。写真は AVIF が 17,599 バイトで WebP の 14,700 バイトより大きくなります。

つまり AVIF は平坦な画像でおよそ半分になり、写真では負けます。これは偶然ではありません。AV1 のフレーム内予測は、はっきりした境界で区切られたほぼ一定色の広い領域が得意で、それはまさにスキャンされた書類や図面、活字のページ、楽譜の性質です。中間調の連続には、あるクオリティ設定のもとではそこまで有利ではありません。写真のスキャンで単純な答えを求めているなら TIFF から WebP へがその答えで、紙のものならこのページです。

AVIF はモダンブラウザには対応していますが、すべてのブラウザというわけではありません。古いスマートフォン、ロックダウンされた業務用パソコン、変わったクライアントを使う人がページに来て、空っぽの枠しか見えないことがあります。フォントの欠落や遅いスクリプトと違い、その失敗は全面的です。

公開するページでは、AVIF のソースと WebP か JPG のフォールバックを持つ picture 要素が答えになります。追加の書き出しが一回増えるだけで問題は消えます。メールで送る、あるいは同僚に手渡すファイルにはフォールバックの仕組みがないので、開いてもらえるかどうかを知っているかどうかが問われます。それがこの選択の全体で、隣の WebP のページが今も既定の推奨であり続ける理由です。

AVIF は AV1 の静止画符号化で、AV1 はブロックの記述方法を決めるために大量の計算を費やします。大きなスキャンではエンコードが変換全体の中で支配的な時間を占め ── 100 メガバイトの TIFF をデコードするのはそれに比べれば一瞬です ── かなり大きな画像はタブの中で数十秒かかることもあります。

そのコストは変換するあなたが一回だけ払うものです。それ以降の訪問者はダウンロードの分だけを払い、スマートフォンで遅い回線を使う人にとってはそちらの半分こそが問題になります。まとめてスキャンを変換するのは一瞬の操作ではなくコーヒー休憩になるということでもあり、公開する画像が 20,000 ピクセル幅である必要がないなら、先にピクセル寸法を落としておく価値があります。エンコードの労力と速さを交換する設定はここにはないので、大きなまとまりを早く終わらせる方法はピクセル寸法を落とすことであって、エンコーダーに手を抜かせることではありません。スマートフォンでも処理できますが、ゆっくりです。まとまった数のスキャンにはデスクトップの機械がふさわしい相手です。

品質のつまみは 1 から 100 まで、初期値は 82 です。写真のスキャンでは妥当な釣り合いですが、活字を含むスキャンではそのままにしておくべき設定ではありません。文字は何千もの黒と白のはっきりした境目のかたまりで、どんな非可逆コーデックもまず最初にそこをにじませます。症状はどの文字の周りにも出るソフトな灰色のにじみで、コピー機で複写したような見た目になります。

文字や細い罫線を含むものは 90 以上に上げてください。ファイルは大きくなりますが TIFF よりはるかに小さいままで、通常の拡大率での可読性の差ははっきり見えます。署名や、寸法の書かれた測量図、引用される数表のように、ドキュメントがピクセル単位で正確でなければならない場合には、どの非可逆設定も正しくなく、TIFF から PNG へがその仕事に向いています。

AVIF は 1 チャンネルあたり 12 ビットと広色域を保持できますが、この変換ツールはそのどちらも渡せません。パイプラインがすべてのソースを 8 ビット RGB にデコードするからです。16 ビットの TIFF は各サンプルの上位バイトだけを残すことで縮められ、CMYK の TIFF は埋め込まれた ICC プロファイルを経由せず計算式によって画面色に変換されるため、印刷用のスキャンは色がずれて出てきます。

コンテナの機能も二つ同じように失われます。複数ページの TIFF はエラーも出さずに最初のページだけが渡されるので、スキャンした図面集は変換前に分割する必要があります。レイヤーはフラット化されます。ウェブページ向けの、8 ビット sRGB で単一画像であることが前提の画像にとってはどれも害になりませんが、その TIFF が原本だった場合にだけ害になります。TIFF は残し、AVIF は公開用にしてください。

AVIF は完全なアルファチャンネルを持てるので、TIFF に含まれる切り抜きやマスクされた領域はやわらかい縁を保ったまま渡ります。これは、透明部分を背景色で塗りつぶすしかなかった従来の「スキャンを JPG にする」習慣を上回る点の一つです。

メタデータは逆で、無条件です。EXIF、XMP、IPTC、ICC プロファイル、GPS のブロックはどれもデコードと再エンコードを経て生き残らず、このページのどこにもそれらを保つ仕組みはありません。公開するスキャンにとってそれは正しい結果です。アーカイブの画像が操作者名や機体のシリアル番号を運んでいる必要はなく、キャプションはファイルではなくページ側に書くものです。

画像がフォールバックの用意なくどこでも動かなければならないなら、TIFF から WebP へがそのページです。今使われているブラウザはすべて WebP を読めますし、写真の内容ではここでの測定でも WebP のほうが AVIF より小さくなっていました。ファイルが誰かのメールや印刷所に届く必要があるなら、TIFF から JPG へが相手の想定するものです。

何一つ変わってはいけないなら、TIFF から PNG へがすべてのピクセルを正確に保ち、あらゆる環境で読める状態を保ちます。TIFF から PDF へは、表示ではなくファイルとして保存し送る、スキャンされた書類にふさわしい行き先です。これらの中で唯一、複数ページを保つものだからです。AVIF を選ぶ価値があるのは、画像が大きく、平坦で、公開されるときです。それ以外では見送る価値があります。

すべてはタブの中で動きます。utif2 が TIFF をデコードし、WebAssembly にコンパイルされた libavif が AVIF をエンコードし、どちらもその形式のファイルが落とされたときにだけ読み込まれます。画像に関する何ものもネットワークを越えません。まだ公開していないアーカイブ資料や、禁輸期間中のもの、ライセンス上の制約があるものにとってこれは重要です。

無料の上限は 1 ファイルあたり 100 MB で、600 dpi の A4 カラースキャンを無圧縮で扱ったのとほぼ同じ大きさです。より大きなスキャンは先に縮小する必要があり、その設定は同じオプションパネルにあります。バッチにも対応しています。フォルダーを置き、各行の進み具合を見て、最後に ZIP で受け取ってください。AVIF のエンコードが遅い工程である以上、大きなバッチは本当に時間がかかります。見張っているより、始めてから離れておく作業です。