Chromeで小さなJPEGが違って見える理由：巧妙なデコード最適化
Why Tiny JPEGs Look Different in Chrome
Chromeで小さなJPEG画像がFirefoxなどと比べて太く見える現象は、バグではなく、Chromeが採用するJPEGデコード最適化によるものでした。ChromeはSkiaとlibjpeg-turboを通じて、画像を縮小表示する際に、完全にデコードする代わりに、周波数領域の低周波成分のみを使って1/8スケールでデコードします。これによりメモリと処理を節約できますが、高周波成分が失われるため、エッジがぼやけず、結果として太く見えるのです。この記事では、JPEGのDCT変換や部分IDCTスケーリングの仕組みを解説し、アイコンなどにはJPEGを使うべきでないと結論づけています。
結局のところ、ここでの教訓は、アイコンなどにJPEGを使うべきではないということです。このフォーマットとその最適化は、写真に対する私たちの知覚を中心に設計されています。
HNでの議論
67- jonathanlydall
PNGでも同じ問題が起きると思います。PNGは可逆圧縮なので、JPEGのような圧縮アーティファクト（著者が指摘しているように、JPEGは本来写真向けです）が発生せず、アルファブレンドにも対応しているため、一般的にアイコンに適しています。
Chromeがこの「最適化」を導入し、それが私たちがアップグレードしていたElectronのリリースにまで及んだとき、製品の多くの場所でアイコンがめちゃくちゃになり、SVGに置き換えるまでアップグレードを延期せざるを得ませんでした。
SVGにはライト/ダークモードに応答できるという利点もあります。異なるSVGのスタイルが衝突しないように、各アイコンを独自のシャドウDOMに入れる必要がありました。名前が同じ場合に備えてです。これはグラフィックデザイナーにとっては少し面倒でした。
- advisedwang
> 本当に、ここでの教訓は、JPEGをアイコンなどに使うべきではないということです。
そして、もっと重要なのは、表示サイズに適した解像度の画像を使うべきだということです。PNGに切り替えても、20x20で表示するアイコンに2000x2000の画像を使うのは無駄です。
- muizelaar
Firefoxで低スケールでのデコード作業が進行中です: https://bugzilla.mozilla.org/show_bug.cgi?id=2033250
- debazel
ChromeとFirefoxは2つの異なるスケーリングアルゴリズムを使用しており、それがこの違いにかなり寄与していると思われます。Chromeは全体的にぼやけているのに対し、Firefoxはシャープですが、わずかにリンギングアーティファクトがあります。個人的にはFirefoxの方が好みです。
- Theodores
libjpeg-turboをmoz-jpegの「アップデート」で上書きすると、よりきれいなJPEG処理ができます。
Mozillaは約10年前にMeta/Instagram向けにJPEGからより多くを引き出しました。彼らのライブラリは比較対象としてこの記事で注目に値するでしょう。基本的な考え方は、JPEGはCPUサイクルが高価でディスプレイがアナログだった時代に考案されたため、最適化に限られた労力しか費やされず、バンディングなどの問題が生じたというものです。これは当時のCRTではうまく処理されましたが、現代のデジタルディスプレイ（CPUが100万倍多いシステム）ではそうではありません。
どのツールを使っているかに関係なく、「ギガピクセル」からサムネイルへの変換は2段階以上のプロセスになり、カラフルなアイテムが灰色のどろどろにレンダリングされることがあります。元の色の一部が本当に必要な場合にです。
JPEGのピクセルブロック（8x8）を尊重する人はほとんどいません。また、ほとんどのグラフィックアーティストは2のべき乗についての知識がありません。かつては、特に初期の3Dグラフィックスのテクスチャマップを扱う場合、画像の寸法を重要な2進数に合わせることが必要でした。
この記事で進行中のもう1つのことは、実質的にすべてのウェブ画面は「レティナ」解像度と見なされるべきであり、最も低性能なオフィスPCを除くすべてのデバイスが「名目上」表示されるピクセル数の1.5倍のピクセル解像度を持っているということです。ウェブ統計で「1280 x 720」がよく使われる解像度として示されている場合、デバイスに関係なく、それは1.5倍の1920 x 1080の画面であり、Chromeや他のブラウザは1280ではなく1920ピクセルを横に詰め込んでいます。もし画像が […]