🍔 📏 👦🏿 明らかに品質を損なうことなく写真を圧縮する：Yelpのエクスペリエンス ✅ 👩‍🚀 👩‍✈️

Yelpは、夕食やヘアスタイルの写真から最新機能の1つである#yelfiesまで、1億枚以上のカスタム写真を保存しています。これらの画像は、アプリケーションとWebサイトのユーザーのトラフィックの大部分を占めており、それらの保存と転送は安価ではありません。人々に最高のサービスを提供するために、私たちはすべての写真を最適化するために一生懸命努力し、平均サイズを30％削減しました。これにより、時間とトラフィックが節約され、これらのイメージのメンテナンスコストも削減されます。そうそう、写真の品質を落とすことなくそれをしました！

ソースデータ

Yelpは12年間カスタム写真を保存しています。ロスレス形式（PNG、GIF）をPNGとして保存し、他のすべての形式をJPEGで保存します。 PythonとPillowはファイルの保存に使用され、写真のアップロードは次のスニペットのようなものから始まります。

# do a typical thumbnail, preserving aspect ratio new_photo = photo.copy() new_photo.thumbnail( (width, height), resample=PIL.Image.ANTIALIAS, ) thumbfile = cStringIO.StringIO() save_args = {'format': format} if format == 'JPEG': save_args['quality'] = 85 new_photo.save(thumbfile, **save_args)

その後、品質を損なうことなくファイルサイズを最適化するオプションを探し始めます。

最適化

まず、ファイルを自分で処理するか、CDNプロバイダーに魔法のように写真を変更させるかを決定する必要があります。高品質のコンテンツを優先するため、サイズと品質の選択肢と潜在的なトレードオフを評価することは理にかなっています。ファイルサイズを最適化することで、現状を調査し始めました。どのような変更を加えることができ、それぞれのサイズ/品質がどのように変化するかです。調査の最後に、3つの主要な分野で作業することにしました。記事の残りの部分では、私たちが行ったことと、各最適化から得られたメリットについて説明します。

枕の変更
- フラグを最適化する
- プログレッシブJPEG
写真アプリケーションのロジックの変更
- 大規模なPNG認識
- ダイナミックJPEG品質
JPEGエンコーダーの変更
- Mozjpeg（トレリス量子化、カスタム量子化マトリックス）

枕の変更

フラグを最適化する

これは、私たちが行った最も単純な変更の1つです。CPU時間による追加のファイルサイズ節約の責任をPillowに移すことです（ optimize=True

）。定義により、これは写真の品質に影響しません。

JPEGの場合、このフラグは、各画像をスキャンするときに余分なパスを作成して、最適なハフマンコードを見つけるようエンコーダーに指示することを意味します。ファイルへの書き込みの代わりに、各最初のパスは各値の発生の統計を計算します。この情報は完全なエンコードに必要です。 PNG標準はzlibを使用するため、この場合の最適化フラグはエンコーダーにgzip -6

代わりにgzip -6

gzip -9

を使用するように指示します。

このような変更は簡単に行うことができましたが、ファイルサイズを数パーセントしか削減できない理想的なソリューションではないことがわかりました。

プログレッシブJPEG

JPEGを保存するとき、いくつかの異なるタイプを選択できます。

上から下にロードするベースラインJPEG
ぼやけたものから鮮明なものまでロードするプログレッシブJPEG。プログレッシブ画像オプションは、Pillowで簡単に有効にできます（ progressive=True

）。その結果、品質が主観的に向上します（つまり、不完全なシャープネスよりも、画像の部分的な欠落に気付きやすくなります）

さらに、プログレッシブ画像をパックする方法では、通常、ファイルサイズが小さくなります。 Wikipediaの記事で詳しく説明されているように、8×8ピクセルブロックのジグザグ浸透がエントロピーエンコーディング用のJPEG形式で使用されます。これらのピクセルブロックの値がパックされず、順番に並べられていない場合、通常はゼロ以外の値があり、その後ゼロのシーケンスがあり、このパターンは画像内の8×8ブロックごとに繰り返され、交互に並べられます。プログレッシブコーディングでは、ピクセルブロックの処理順序が変更されます。ファイルの最初は各ブロックの大きな値であり（プログレッシブ画像の最初のスキャンに特徴的なブロックノイズを与えます）、終わり近くには、ゼロを含む小さな値の長い範囲が保存され、これらの範囲は詳細を提供します。このようなファイル内のデータの再配布は、イメージ自体を変更しませんが、連続してゼロの数を増やします（圧縮が容易です）。

ベースラインJPEGとプログレッシブJPEGの比較

ベースラインJPEGレンダリングの仕組みの例

プログレッシブJPEGレンダリングの仕組みの例

写真アプリケーションのロジックの変更

大規模なPNG認識

Yelpは、カスタムコンテンツの2つの形式（JPEGとPNG）で動作します。 JPEGは写真には適していますが、通常、コントラストの高いデザイナーコンテンツ（ロゴなど）には対応していません。対照的に、PNGは画像を完全にロスレスに圧縮し、グラフィックには最適ですが、小さな歪みがまだ目立たない写真には扱いにくいです。ユーザーがPNG形式で写真をアップロードする場合、そのようなファイルを認識してJPEGで保存すれば、多くのスペースを節約できます。 YelpのPNG写真の主な情報源の1つは、写真を変更し、効果を適用し、フレームを追加するモバイルデバイスおよびアプリケーションのスクリーンショットです。

左：ロゴとフレームを使用した一般的なPNGの組み合わせ。右：スクリーンショットの典型的なPNG。

このようなオプションのPNGの数を減らしたかったのですが、形式を変更したり、ロゴ、グラフィックスなどの品質を低下させたりして無理をしないことが重要でした。画像が写真かどうかを判断するにはどうすればよいですか？ピクセルで？

2500枚の画像の実験サンプルを確認した後、ファイルサイズと一意のピクセル数の組み合わせにより、写真を正確に決定できることがわかりました。最大解像度で小さなコピーを生成し、ファイルサイズが300 KiBを超えるかどうかを確認します。その場合、2 ¹⁶を超える一意の色の画像ピクセルを確認します（YelpはダウンロードしたRGBA画像をRGBに変換しますが、これを行わなかった場合、これを確認します）。

実験サンプルでは、「大きな写真」の定義に関するこのような手動設定により、グラフィックスに誤検出がなく、最適化に適している可能性があるすべてのファイルの88％が明らかになります。

ダイナミックJPEG品質

JPEGファイルのサイズを縮小する最初で最も有名な方法は、 quality

という設定を使用するquality

です。 JPEG形式で保存できる多くのアプリケーションでは、 quality

を数値として定義しています。

品質は一種の抽象化です。実際、JPEG画像の各カラーチャンネルには個別の品質レベルがあります。 0〜100の品質レベルは、カラーチャネルの異なる量子化テーブルに対応し、失われるデータの量を決定します（通常は高周波数で）。信号の量子化は、情報が失われた場合のJPEGコーディングプロセスの手順の1つです。

ファイルサイズを縮小する最も簡単な方法は、ノイズを増やすことで画質を低下させることです。ただし、すべての画像が同じ品質レベルで同じ量の情報を失うわけではありません。

品質とサイズの完璧なバランスを実現するために、品質設定を動的に変更し、個々の画像ごとに最適化することができます。これを行うには2つの方法があります。

ボトムアップ：これらのアルゴリズムは、カスタマイズされた量子化テーブルを生成し、8×8ピクセルのブロックレベルで画像を処理します。彼らは同時に、理論上の品質がどれだけ失われたか、そしてこれらの失われたデータが人間の目の歪みの外観をどのように向上または減少させるかを計算します。
トップダウン：これらのアルゴリズムは、画像全体を元のバージョンと比較し、失われた情報の量を判断します。品質設定が異なる候補を一貫して生成するため、使用する評価アルゴリズムに応じて、最低レベルの評価に対応するものを選択できます。

ボトムアップアルゴリズムの動作を評価した結果、使用したい最高品質の設定で適切な結果が得られないという結論に達しました（ただし、破棄の選択に関してエンコーダがより太くなる可能性がある中品質の範囲で潜在性があるようです）バイト）。この戦略に関する多くの科学論文は、コンピューティングリソースが不足している90年代初頭に公開されたため、ブロック間の関係の評価など、オプションBが使用するリソース集約的な方法を使用することは困難でした。

そこで、2番目のアプローチに移りました：分割アルゴリズムを半分に使用して異なる品質レベルで候補画像を生成し、この値がカスタムの範囲内にある限り、 pyssimを使用して構造類似性指数（ SSIM ）を計算して各画像の品質低下を評価しますしかし、静的なしきい値。これにより、知覚されるしきい値を超えた画像についてのみ、平均ファイルサイズ（および平均品質）を選択的に下げることができました。

次の図では、3つの異なる品質設定で再生成された2,500個の画像のSSIM値を表示しています。

quality = 85

現在の方法を使用して作成された元の画像は青で表示されます。
品質設定をquality = 80

に減らして、ファイルサイズを小さくする別のアプローチを赤で示しています。
最後に、 SSIM 80-85

動的な品質であるアプローチがオレンジ色で示されています。ここで、品質は、SSIMの比率の一致または過剰に応じて、80から85（両端を含む）の範囲から選択されます。これは、画像範囲の中央でこの遷移を行う事前に計算された静的値です。これにより、見栄えの悪い画像の品質を低下させることなく、平均ファイルサイズを削減できます。

品質設定を変更するための3つの異なる戦略を持つ2500画像のSSIMインデックス

SSIM？

人間の視覚システムを模倣しようとする画像の品質を変更するためのアルゴリズムがいくつかあります。私たちはそれらの多くを高く評価し、SSIMは古いものの、その特性により、このような反復最適化に最適であると考えています。

JPEG量子化エラーの影響を受けやすい
高速でシンプルなアルゴリズム
画像をPNGに変換してCLIアプリケーションに転送することなく、ネイティブPILオブジェクトで計算できます（＃2を参照）

動的品質のサンプルコード：

 import cStringIO import PIL.Image from ssim import compute_ssim def get_ssim_at_quality(photo, quality): """Return the ssim for this JPEG image saved at the specified quality""" ssim_photo = cStringIO.StringIO() # optimize is omitted here as it doesn't affect # quality but requires additional memory and cpu photo.save(ssim_photo, format="JPEG", quality=quality, progressive=True) ssim_photo.seek(0) ssim_score = compute_ssim(photo, PIL.Image.open(ssim_photo)) return ssim_score def _ssim_iteration_count(lo, hi): """Return the depth of the binary search tree for this range""" if lo >= hi: return 0 else: return int(log(hi - lo, 2)) + 1 def jpeg_dynamic_quality(original_photo): """Return an integer representing the quality that this JPEG image should be saved at to attain the quality threshold specified for this photo class. Args: original_photo - a prepared PIL JPEG image (only JPEG is supported) """ ssim_goal = 0.95 hi = 85 lo = 80 # working on a smaller size image doesn't give worse results but is faster # changing this value requires updating the calculated thresholds photo = original_photo.resize((400, 400)) if not _should_use_dynamic_quality(): default_ssim = get_ssim_at_quality(photo, hi) return hi, default_ssim # 95 is the highest useful value for JPEG. Higher values cause different behavior # Used to establish the image's intrinsic ssim without encoder artifacts normalized_ssim = get_ssim_at_quality(photo, 95) selected_quality = selected_ssim = None # loop bisection. ssim function increases monotonically so this will converge for i in xrange(_ssim_iteration_count(lo, hi)): curr_quality = (lo + hi) // 2 curr_ssim = get_ssim_at_quality(photo, curr_quality) ssim_ratio = curr_ssim / normalized_ssim if ssim_ratio >= ssim_goal: # continue to check whether a lower quality level also exceeds the goal selected_quality = curr_quality selected_ssim = curr_ssim hi = curr_quality else: lo = curr_quality if selected_quality: return selected_quality, selected_ssim else: default_ssim = get_ssim_at_quality(photo, hi) return hi, default_ssim

この手法については、他にもブログ記事がいくつかあります。コルトマカンリスの記事をご覧ください。また、公開するときに、Etsyも公開しました！ハイファイブ、高速インターネット！

JPEGエンコーダーの変更

モズジペグ

Mozjpegはlibjpeg-turboのオープンソースフォークで、ファイルサイズのためにランタイムを犠牲にしました。このアプローチは、オフラインファイル回復パイプラインとの互換性があります。 libjpeg-turboの3〜5倍のリソース消費により、このアルゴリズムは画像のサイズを小さくします。

mozjpegの違いの1つは、代替の量子化テーブルを使用することです。前述のように、品質は各カラーチャネルの量子化テーブルの抽象化です。すべての兆候は、デフォルトのJPEG量子化テーブルが非常に簡単であることです。 JPEG仕様が言うように：

これらの表は例としてのみ提供されており、特定のアプリケーションに必ずしも適しているわけではありません。

したがって、当然、これらのテーブルがエンコーダのほとんどの実装でデフォルトで使用されていることに驚かないでください...

Mozjpegは代替テーブルを比較するという大変な作業を行い、画像生成時に最高のパフォーマンスを発揮する代替テーブルを使用しています。

Mozjpeg +枕

ほとんどのLinuxディストリビューションには、デフォルトでlibjpegがインストールされています。そのため、Pillowの下のmozjpegはデフォルトでは機能しませんが、構成で構成するのはそれほど難しくありません。 mozjpegをビルドするときは、 --with-jpeg8

を使用して、Pillowとリンクできることを確認してください。 Dockerを使用する場合、次のようなDockerfileを作成できます。

 FROM ubuntu:xenial RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y --no-install-recommends install \ # build tools nasm \ build-essential \ autoconf \ automake \ libtool \ pkg-config \ # python tools python \ python-dev \ python-pip \ python-setuptools \ # cleanup && apt-get clean \ && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* # Download and compile mozjpeg ADD https://github.com/mozilla/mozjpeg/archive/v3.2-pre.tar.gz /mozjpeg-src/v3.2-pre.tar.gz RUN tar -xzf /mozjpeg-src/v3.2-pre.tar.gz -C /mozjpeg-src/ WORKDIR /mozjpeg-src/mozjpeg-3.2-pre RUN autoreconf -fiv \ && ./configure --with-jpeg8 \ && make install prefix=/usr libdir=/usr/lib64 RUN echo "/usr/lib64\n" > /etc/ld.so.conf.d/mozjpeg.conf RUN ldconfig # Build Pillow RUN pip install virtualenv \ && virtualenv /virtualenv_run \ && /virtualenv_run/bin/pip install --upgrade pip \ && /virtualenv_run/bin/pip install --no-binary=:all: Pillow==4.0.0

以上です！通常の画像処理プロセスでmozjpegを使用してPillowを収集し、使用できるようにします。

効果

これらの改善点はどれほど重要でしたか？ 2,500枚のYelpのビジネス写真のランダムなサンプルから始め、それらを処理パイプラインに通し、サイズ変更を測定しました。

枕の設定を変更すると4.5％節約
大きなPNGを特定すると6.2％節約
動的品質により4.5％節約
mozjpegエンコーダーに切り替えると13.8％節約されます

全体として、これにより平均画像サイズが約30％削減されました。これは、最も一般的な写真解像度に使用し、ユーザーにとってサイトを高速化し、データ転送で1日あたりテラバイトを節約しました。 CDNレベルで修正されたとおり：

CDNの経時的な平均ファイルサイズの変化（および画像ではない他のファイル）

しなかったこと

このセクションでは、使用できる他のいくつかの典型的な最適化について説明しますが、ツールのデフォルト設定のため、またはそのような妥協を意図的に拒否したため、それらはYelpに適していませんでした。

ダウンサンプリング

サブサンプリングは、Web画像ファイルの品質とサイズの両方を決定する重要な要素です。ダウンサンプリングの詳細な説明はインターネットで見つけることができますが、この記事ではすでに4:1:1

ダウンサンプリングを実行していると言うだけで十分です（他の設定を指定しない限り、これらはPillowのデフォルト設定です）。さらなる最適化を獲得します。

ロッシーPNGエンコーディング

PNGで何をしているのか、これらの画像を同じ形式で保存するオプションを知っていますが、 pngminiのような非可逆エンコーダーを使用することは理にかなっていますが、JPEG圧縮オプションを選択しました。それでも、エンコーダの作成者は、ファイルの圧縮について72〜85％言っているため、これは妥当な結果をもたらす代替手段です。

より現代的なフォーマット

WebPやJPEG2kなどのより新しい形式のサポートは、私たちによって確実に考慮されました。しかし、仮にこの仮想プロジェクトを実装したとしても、JPEG / PNG画像を必要とするユーザーのロングテールが存在するため、いずれにせよそれらを最適化する努力は無駄ではありませんでした。

Svg

SVGは、デザイナーがスタイルガイド用に作成した静的画像など、サイトの多くの場所で使用します。この形式とsvgoのような最適化ツールはページサイズを大幅に削減しますが、これらはタスクに適していません。

ベンダーマジック

サービスとして画像の配信、サイズ変更、トリミング、トランスコードを提供している企業が多すぎます。オープンソースthumborを含む。将来的には、これがレスポンシブ画像、動的タイプのコンテンツのサポートを実装し、最先端の進歩を維持するための最も簡単な方法かもしれません。しかし今、私たちは自分でそれをやっています。

さらに読む

ここで言及されている2冊の本は、この記事の文脈外では完全に自給自足であり、このテーマについてさらに読むために強くお勧めします。

明らかに品質を損なうことなく写真を圧縮する：Yelpのエクスペリエンス