JPEG画像は、拡張子が.jpgの実際のファイルに加えて、PDFファイルおよびTIFFファイル内にあります。
JPEG テクノロジーの利害関係者は、おそらく次のグループに分類できます。
- カメラとスキャナーの開発者。
- 写真家(高品質で高解像度の大きな写真);
- imgixタイプのソーシャルネットワークとCDN。制御されていないUGC起源の浸水した写真、クランプされたフォームの数とサイズを配信します。
- 適度な数の非UGCイメージを品質管理で管理するウェブマスター。
- スキャンされた紙の本やその他の史料の愛好家。
この記事の著者は主に最後のグループに属し、確かに芸術写真家の数には属していません。 これにより、物語に一定のバイアスが導入されるはずですが、それでも解決策の空間で考えられる軌道を説明するのに役立ちます。
元の画像をJPEG に変換するプロセスについて簡単に説明します。
- 色空間の変換とダウンサンプリング。
- 画像は8x8ピクセル(MCU)のブロックに分割されます。 画像サイズが8で完全に分割されていない場合、ボックスの残りの部分はいくつかのピクセルで埋められ、デコード時には単純にトリミングされます。
- 8x8ピクセルのDCT(離散コサイン変換)マトリックス。t.zで「より重要」になります。 画質係数は結果の8x8マトリックスの左上隅に近く、「重要度の低い」係数は右下隅に近くなります。 合計で8x8 = 64の係数があります。
- 量子化:前の段落の行列は要素ごとに量子化行列に分割されます(特定の画像ごとに比較的自由に選択できます。量子化の結果、右下隅の要素が通常ゼロの行列が得られます。
- 係数圧縮(エントロピーコーディング、RLEコーディング、ハフマンコーディング);
情報が失われる唯一の操作は量子化です。 他のすべての操作は損失なしで発生します。
利害関係者が異なれば、以下のフェーズが異なる生産サイクルが異なります。
- JPEGファイルの生成時に使用できる処理能力と時間はどれくらいですか? たとえば、カメラと本格的なコンピューター。
- 生成されたjpegファイルは最終結果ですか? たとえば、これはサイト上のストックイメージまたは生成されたプレビューの場合です。
- 生成されたjpegファイルは、事実上のソースイメージになりますか? たとえば、これはスキャンされた本のページに当てはまります。
- ファイルストレージにどのくらいのスペースがありますか? 常に十分なスペースはありませんが、時々非常に小さいです。
- 最終的な技術は何ですか? ブラウザ用のJPEGファイル? PDFファイル? 電子書籍リーダーなど、完全に制御される特殊なソフトウェアですか?
- 画像が何であるかを判断できますか? フルカラー写真またはスキャンした白黒ページにセピア色のトーンを使用しますか?
- 結果の品質をチェックするのにどれだけの労力を費やすことができますか? 写真家はPhotoshopに何時間も座ることができますが、CDNは「許容できる」品質しか提供できません。
標準のJPEG形式のままで、以下を変更できます 。
- 人間の知覚のモデルのフレームワーク内のソースピクセル。
- 量子化マトリックス(さらに、適切なマトリックスを個別に選択し、必要なJPEG品質に応じてスケーリングすることもできます);
- 量子化結果マトリックス。人間の知覚のモデルの枠組み内で、結果として得られる画像のピクセルをある程度変化させることができます。
- 係数圧縮スキーム。
標準のファイル形式を超えて、基本的なJPEGエンコードモデルを維持しながら、非標準の係数圧縮スキームを使用して、ストレージスペースを節約できます(エンドデバイスを制御する場合は表示もできます)。
最終的なフォーマットが標準PDFであり、ソースが本のページをスキャンしている場合、テクノロジーを使用して画像を白黒部分とカラー部分に分離できます。 エンドデバイスを制御する場合、別の非標準の「フォーマット」を使用できます。
キーポイント:ここで説明する多くのテクノロジは、ファイルサイズの削減に役立ちます。 これにより、実際にはファイルサイズのほぼ目標内にとどまりながら、画像の品質を改善する機会が得られることを理解することが重要です。
可能な解の空間の各次元を個別に検討します。
ソースピクセル
JPEG圧縮技術は、 視覚の心理視覚モデルに基づいています。人間の目は、高周波画像の詳細が失われます。 人は色の違いよりも明るさの違いをよりよく知覚します。 SSIM(Structural Similarity)の式に基づいてソースイメージを正しく再現するための標準化されたメトリックがあります。これは自動的に計算され、ターゲット値を設定できます。
再現の正確さの目標値の範囲内でソースピクセルを変更できる場合は、原則として、量子化後に圧縮しない方が圧縮しないピクセル値を選択できます。 ソフトウェアがそのような技術を使用しているかどうかはわかりません。
量子化行列
量子化マトリックスは、許容可能な圧縮率で再生品質を提供する主要なメカニズムです。 同時に作成されたテスト画像の本体の分析に基づいて25年以上前に作成されたものを含む、いくつかの標準デフォルトマトリックスがあります。 標準の行列を使用する場合、気にする必要がない場合は、すべてが多かれ少なかれ順番になります。
一般的に言えば、そのコンテンツを分析することにより、各画像に対して個別の量子化マトリックスを生成することが最適です。 カメラメーカーは、特許取得済みの生成方法を使用しています。 彼らは、Adobe Photoshopは画像を分析し、適切なマトリックスを選択できると言います。
JPEG圧縮品質は、標準の量子化行列の要素に適用される単なる重要な要素であり、ますます多くの情報を破棄します。
興味深い事実:量子化マトリックスは、コンピューターフォレンジックで使用して、写真が撮影されたデバイスを識別することができます。
量子化DCT係数
多くの場合、非圧縮形式で画像を保存することは実用的ではないため、JPEGファイルは事実上のソース資料です。 また、紙のソース資料にアクセスできない場合もありますが、たとえば、起源が不明で品質が疑わしいPDFファイルしかありません。 そのため、多くのアプリケーションでは、可能であればロスレス変換を適用して、DCT係数をファーストクラスオブジェクトとして慎重に操作することが理にかなっています。
DCT係数の行列レベルでの作業により、最小限の損失(または損失なし)で複数の変換を行うことができます。 ピクセルの完全なトランスコーディングを必要とする操作は、ここでは考慮されません。
最小限の損失での変換:
- 画像のサイズを完全に8で割った場合、90度と180度の回転。
- 特に切り取り線の座標が8で割り切れる場合、画像をトリミングします。
- 8 / Nの圧縮率で画像をスケーリングします。N= 9 ... 16。 特に、これは、1/2および2/3の係数で画像を圧縮できることを意味します。
- 画像の色からグレー表現への変換(色成分は捨てられます);
量子化後の次の操作は圧縮であることがわかっているため、原理的には、理論的には係数をわずかに変更して圧縮率を高めることができますが、同時に元の画像とほぼ同じピクセルでデコードされます。 このアプローチを使用する実装があるかどうかは不明です。
係数圧縮スキーム
標準JPEGは、ハフマン圧縮係数と算術コーディングをサポートしています。
ハフマン圧縮の実装は、多くの場合、最も簡単で素朴です。 特に、コンプレッサは係数を圧縮し、ランダムなデータとして扱います。 これらが画像をエンコードする2次元行列の係数であるという事実を考慮すると、かなり良い結果を得ることができます。 このレベルでの係数の圧縮は、損失なく発生します。
圧縮を改善する別の方法は、ファイルをプログレッシブJPEGにトランスコードすることです。 この場合、同じ次数の係数はグループ化され、通常、ファイルサイズが小さくなります。 これもロスレス圧縮操作です。 さらに、ファイルがアップロードされると、プログレッシブJPEGのレンダリングが高速になります。これは、Web上で別の利点になる場合があります。
2番目の標準圧縮方法は算術コーディングです。 残念ながら、この方法は専用のツールでのみサポートされています。特に、ほとんどの一般的なブラウザではサポートされていません。 これは、算術コーディングの疑わしい(過去の)特許ステータスによるものです。 算術符号化による画像の単純な圧縮により、損失がない場合にサイズを大幅に節約できます。 もちろん、この方法は、クライアントデバイスの実装を制御する場合、または画像がストレージのみに使用される場合に使用できます。
クライアントデバイスを完全に制御する場合、または画像のみを保存する場合は、圧縮のオブジェクトが画像であるという事実をより活用する非標準の圧縮スキームを使用できます。 たとえば、興味深いプログラムPackJPGは、JPEGを損失なしで約20%圧縮できますが、結果は非標準形式で保存されます。
画像レイヤーの分離
一部の画像、特にスキャンした印刷ページでは、画像を白黒(または他のパレット)レイヤーとフルカラーの「リファイン」素材に分割できます。 これらのレイヤーは両方とも、これに最適な形式で個別に圧縮できます。 たとえば、PDFの場合、白黒レイヤーはJBIG2を使用して圧縮でき、カラーレイヤーはJPEG2000、JPEGまたはPNGで圧縮できます。
同様のテクノロジーがDJVU形式で使用されています。
クライアントデバイスを制御する場合、たとえばHTML画像を重ねて表示するなど、同様の変換を行うことができます。
https://en.wikipedia.org/wiki/JPEGは非常に良い概要です。 いくつかの段落は、他の参考文献を研究した後にのみ明らかになります。
http://www.ijg.org/-参照形式の実装。 スーパーポータブルCで記述されているため、最適化されていません。
http://www.libjpeg-turbo.org/-JPEGの最適化された実装
http://www.libjpeg-turbo.org/About/Jpeg-9-IJGの批判+ http://www.libjpeg-turbo.org/About/SmartScale-物議を醸すSmartScaleニュースの批判
http://www.libjpeg-turbo.org/About/Mozjpeg-Mozjpegによる非常に優れたテクニカル分析
https://github.com/mozilla/mozjpeg-特定の一般的なユースケース向けに最適化されたJPEG実装
http://jpegclub.org/jpegtran/-JPEGファイルを最小限の損失で変換するためのユーティリティ
https://linux.die.net/man/1/exiftran-EXIFを使用してローテーションされたJPEGファイルを操作するためのユーティリティ。
https://github.com/ifad/pdfbeads-レイヤー分離を使用してPDFファイルを生成するためのスクリプト
https://en.wikipedia.org/wiki/DjVu#Compression-DjVuのレイヤーの分離の説明
https://github.com/packjpg-JPEGファイルの低レベル操作用のライブラリとユーティリティのセット
http://code.flickr.net/2017/01/05/a-year-without-a-byte/-Flickrが画像のストレージと配信を最適化する方法についてのストーリー