私はJPEG圧縮がロッシーであることを認識しています。 私は2つの質問を持っている：操作Tが与えられJPEGイメージの再エンコードは偶発的な操作ですか？
：
1. JPEG-80
Tは視覚的には偶然の操作ですか？ Tを繰り返すうちに画像の品質が低下しますか？ JPEG-XRコーデックについても同じことが成り立ちますか？
ありがとうございました！
編集： 矛盾する回答がありますので、参考にしていただければ幸いです。
同じ設定で同じJPG圧縮エンジンを使用している場合、通常は冪等であります。それが保証されているかどうかはわかりませんが、ほとんどの実装ではそれが処理されると思います。私は、Javaランタイムの実装が偶発的であることを確かに知っています。
私はWIC APIを使用しています：http://msdn.microsoft.com/en-us/library/windows/desktop/gg430027(v=vs.85).aspx – Sau
DaveはJPEG画像を再エンコードしようとしました最初にビットマップに変換するので、この証拠はあまり説得力がありません。私はどちらのAPIにも精通していませんが、以前にエンコードしたものを覚えていれば、JPEGイメージを再エンコードするのに十分なほどスマートです。結局のところ、JPEGの再エンコーディングは一般的に望ましくないので、潜在的に共通の機能の誤用に耐えることはAPIにとって意味がありますが、何が起きているのかを明確にする警告を出すべきです" – StockB
定義上、損失の多い操作は、（理想的には）エンドユーザーに気付かれないように表現を単純化することによってデータを破棄します。しかし、エンコーダは、どのピクセルが重要で、どのピクセルが重要でないかを判断するための魔方法はありません。したがって、たとえアーティファクトであっても、すべてのピクセルを均等にエンコードします。
つまり、エンコーダは、可逆圧縮画像を可逆画像と同じに扱います。すべてのエンコーダが知っているので、ユーザはアーチファクトを表すためにを意図しているので、損失のある画像はさらに単純化され、処理中の追加データを破棄する。
それは保証されませんが、それが起こることがあります。ここでは
はJPEG生成損失のいくつかの例があります。特に、エンコード - >デコード - >エンコード - >デコード処理を十分に繰り返すと、最終的には固定小数点で解決され、品質がさらに低下するのを止めます（同じ品質と同じエンコーダを使用する限り）。
JPEG符号化は、いくつかの工程で行われる：YUVへの変換
復号化は逆の処理です。
ステップ1と2には丸め誤差があります（特に整数演算を使用した速度最適化エンコーダでは）ので、等価再エンコードの場合、エンコードを取得し、丸め誤差を小さくするか互いに打ち消し合うのが幸運です。
主要な損失のあるステップであるステップ3は、実際には冪等元です。デコードされたピクセルが同様の十分なDCTに変換された場合、同じデータに再び量子化されます。
JPEG XRもYUVを使用するため、丸め誤差が発生する可能性がありますが、DCTの代わりにOTOHを使用すると、丸め誤差なしに計算できる別の変換が使用されるため、JPEG-フォーマット。
.png){kind=link}
私は確かにわかりませんが、私はそれを信じていません。特に異なるエンジン間。単一のエンジンであっても、発生する近似は、2回適用されたときに同じ領域にならないことがあります。 –
私はいいえと言います。 jpegにエンコードするたびに、より多くの「損失」が発生します。 – leppie