画像リサイズ

一度に縮小すると画質が悪くなる理由

ブラウザが大きな画像をずっと小さな領域に一度に描画すると、元のピクセルのうち限られた数だけをサンプリングし、残りは無視します。サンプルの間にあったディテールは平均されずに捨てられ、その結果がエイリアシングです。ギザギザの斜線、細かな模様のちらつき、ノイズのようになった文字などです。width属性だけで縮小した画像が、画像編集ソフトで縮小した同じ画像よりたいてい見劣りするのはこのためです。

ここでの対策は、画像を繰り返し半分にしていき、最後の小さな一歩だけを最後に行うことです。半分にするたびに4ピクセルずつが平均されるので、目標の大きさに達したときには、出力の各ピクセルが、そこに含まれる1点の任意のサンプルからではなく、それが表す領域全体から導かれています。グラフィックスのミップマップと同じ原理で、大きく縮小する場合の差ははっきりわかります。

専用ツールはLanczosなどのフィルターでさらに一歩進み、より広い範囲の近傍を重み付けして、見た目のシャープさを少し多く保ちます。段階的に半分にする方法でも十分近く、写真ではその差を見分けるのは難しいうえ、スマートフォンでも即座にプレビューできるほど高速に動きます。

目標サイズの決め方

画像を表示する場所に合わせて大きさを決め、そのうえでピクセル密度を考慮します。ページ上で幅800 CSSピクセルで表示する写真は、CSSピクセル1つにつき2つのデバイスピクセルを持つ最近のスマートフォンやノートパソコンでくっきり見せるには、約1600ピクセル必要です。2倍を超えると、見た目の改善はほとんどないのにファイルサイズは大きく増えます。

さまざまな端末に配信するページなら、複数のサイズを用意してsrcset属性でブラウザに選ばせるのがよりよい方法です。640、960、1280、1920の幅があれば、ほとんどのレイアウトに対応できます。メールなら600ピクセル程度に抑えましょう。文書やスライドなら、配置する大きさの2倍に合わせます。

目標に届かせるために拡大してはいけません。拡大は撮影されていないピクセルをでっち上げるだけで、ぼやけた画像をより大きく、よりぼやけたものにし、何の得もないままファイルを大きくします。元画像より大きくする必要があるなら、変えるべきなのは元画像のほうです。

上限と、それがある理由

受け付けるファイルは30MBまで、画像は約1,670万ピクセルまでです。4000×4000程度、あるいは同じ総面積のほかの縦横比に相当します。

この上限は恣意的な方針ではなく、ブラウザのcanvasによるものです。特にiOSのSafariはcanvasが扱える面積に上限を設けており、それを超えたときの失敗の仕方は最悪です。エラーも例外もなく、すべてうまくいったかのように真っ白な画像が返ってきます。そうならないよう、上限を超えるものは説明を添えて受け付けません。5000万画素のRAW書き出しを縮小したいなら、デスクトップの画像編集ソフトが適した道具です。

一括処理を並列ではなく1枚ずつ行うのも同じ理由です。デコードした画像は、圧縮ファイルがどれほど小さくても、メモリ上で幅×高さ×4バイトを占めます。大きな画像を何枚も同時に扱うと、スマートフォンのブラウザがタブを落としてしまうのです。

リサイズ、トリミング、圧縮

これらはそれぞれ別の問題を解決するもので、本当の目的がファイルを小さくすることである場合によく混同されます。

リサイズはピクセルの数を変えるもので、ファイルサイズに対して圧倒的に効果的な手段です。効き方が2乗だからで、幅と高さを半分にするとピクセル数は4分の1になります。等倍で見えるものは変わりますが、フレーム全体はそのまま残ります。

トリミングはフレームに何が入っているかを変えます。これもピクセル数を減らしますが、技術的な判断ではなく構図の判断であり、元に戻せません。

圧縮は、既存のピクセルをどれだけ正確に保存するかを変えるもので、画像変換ツールの画質設定がこれにあたります。寸法はそのままで、忠実さと引き換えにサイズを小さくします。

Webページには重すぎる写真なら、うまくいく順序は、まず表示サイズにリサイズし、次に適切な画質でWebPかJPGにエンコードすることです。後者だけを行うと、たいてい削減できる分の大半を取り逃がします。

縮小にフィルターが必要な理由

画像を縮小するということは、出力ピクセル1つずつについて「元画像のこの領域を代表する色は何か」という問いに答えることです。最も近い元ピクセルを1つ取って周囲を無視するのは、最も安上がりで最も悪い答えです。サンプリング点の間に落ちたディテールは平均化されずに捨てられ、その捨てられたディテールは、元の写真には存在しなかった模様となって現れます。

これがエイリアシングで、映画の中で馬車の車輪が逆回転して見えるのと同じ現象です。ディテールが求めるよりも低いレートでサンプリングすると、ディテールは静かに失われるのではなく、より低い周波数の偽の模様として画像に折り返されます。細かいテクスチャはちらつき、斜めの線は階段状になり、小さな文字はノイズに変わります。

解決策は、各出力ピクセルが代表する領域全体を平均することで、フィルターによってその平均の重みづけが変わります。ボックス平均は単純で、わずかに眠い絵になります。Lanczosはsinc関数に基づくカーブでより広い近傍に重みをつけ、見た目のシャープさをより多く保ちますが、硬いエッジの近くにわずかなリンギングが出ます。ここで使っている段階的な半分ずつの縮小は、ずっと低いコストでそれに近い結果を得られます。

寸法、アスペクト比、トリミング

リサイズはフレーム全体を保ったまま、それを何ピクセルで表すかを変えます。トリミングはフレームそのものを変えます。この2つを混同すると、作りの悪いサイトでよく見る歪んだ画像ができあがります。横長の写真を正方形のコンテナに押し込むために、縦と横の寸法を別々に指定してしまった結果です。

レイアウトが決まった形を要求する場合は、引き伸ばすのではなく意図的にトリミングしてください。CSSのobject-fitにcoverを指定すればブラウザ側でこれができ、装飾的な画像なら十分です。ただし被写体が重要な画像では、あらかじめトリミングしておいたほうが何を残すかを制御できます。自動の中央トリミングは、集合写真の人物の頭を確実に切り落とします。

1つのトリミングでは足りないのがアートディレクションです。デスクトップでうまく機能する横長のヒーロー画像は、スマートフォンでは同じフレームを小さくしたものではなく、縦長に詰めたトリミングが必要になることがよくあります。メディア条件を伴うpicture要素はそのためのもので、同じトリミングを異なるサイズで配信するsrcsetとは役割が異なります。

画像の重さがページに与える代償

たいていの場合、ページがダウンロードするもののうち最も大きいのは画像であり、GoogleがCore Web Vitalsで報告する指標の1つであるLargest Contentful Paintも、非常に多くの場合は画像です。その1ファイルに含まれる不要なキロバイトの1つひとつが、ページが読み込み終わったように見える瞬間を遅らせます。

実用的な目安としては、ヒーロー画像を約200 KB以下に抑え、ファーストビューより下の画像はそれよりずっと小さくすることです。寸法さえ適切なら、通常の品質設定でも十分に達成できます。3 MBの写真をそのまま配信してCSSで縮小表示するのは、コンテンツ系サイトで最もよくあるパフォーマンス上の問題であり、訪問者の時間だけでなく通信量まで奪います。

もう半分はレイアウトの安定性です。widthとheightが指定されていない画像は場所を確保しないため、画像が届いた瞬間にその下のテキストが飛び跳ねます。両方の属性を設定するか、CSSでaspect-ratioを指定するかは1行の変更で、目に見える不具合をまるごと1カテゴリー消してくれます。

大量の画像を一度にリサイズする

数枚程度ならブラウザのツールがいちばん速い方法です。数十枚を超える場合や、ビルド処理の一部として行う場合は、スクリプトで扱えるツールのほうが適しています。ImageMagickのmogrify -resize 1600x -quality 82 *.jpgならディレクトリ1つをコマンド1回で処理できますし、sharp、libvips、PillowならNodeやPythonのパイプラインの中で同じことができ、メモリ消費も評判ほど大きくありません。

よくある事故を防ぐ習慣が2つあります。1つはコピーに対して作業することです。mogrifyは既定で元ファイルを上書きし、取り消しはできません。もう1つは固定寸法ではなく1600xのような幅だけの指定を使うことです。そうすれば縦位置と横位置のどちらの画像も歪まずに処理できます。

ユーザーからのアップロードを受け取るサイトでは、リサイズはリクエストのたびにではなく取り込み時に1回だけ行うべきです。後で別のサイズが必要になる可能性があるなら、オリジナルも保管しておきます。画像CDNを通じて必要に応じてサイズを生成するのも妥当な構成です。ページ内でCSSによって縮小するのは妥当ではありません。どちらにせよフルサイズのファイルがダウンロードされてしまうからです。

拡大と、AIツールが変えたもの

画像を拡大しても、そもそも記録されていなかったディテールを取り戻すことはできません。バイリニア、バイキュービック、Lanczosといった古典的な補間は、同じ情報からなめらかで大きな画像を作り出します。それが眠く見えるのは、実際に眠いからです。アルゴリズムの欠陥ではありません。情報が本当に存在しないのです。

機械学習による拡大は、これまで学習してきたものをもとにもっともらしいディテールを作り出すことで、よりシャープな結果を生みます。壁紙や旅行写真のプリントなら、それこそが望んでいるものである場合が多いでしょう。しかし証拠性が問われるもの、たとえば書類のスキャン、顧客が判断材料にする商品写真、報道記事の画像などでは深刻な問題になります。付け足されたディテールは推測にすぎないのに、本物のピクセルと同じ確からしさで提示されるからです。

確実な原則は変わりません。元を直すことです。元ファイルから書き出し直す、より高い解像度でスキャンし直す、必要なサイズの素材を改めて用意してもらう。それ以外はすべて、でっち上げた材料による修復です。