JPEGが複数回再圧縮されるときに「世代の喪失」を引き起こすまたは防ぐ要因は何ですか？

何年もの間、JPEGファイルを複数回再圧縮すると、認識できない混乱になるまで品質が徐々に低下すると考えられていました。JPEGは非可逆形式なので、これは直感的に理にかなっています。これがそうであると主張する他のQ＆Aもあります：

• MS PaintでJPEG画像を再保存すると、どのような画質が失われますか？

• JPEGファイルを単に開いたり閉じたりすると、画質が低下しますか？

ただし、同じ品質レベルでJPEGを再圧縮しても画像品質が低下することはありません。これは、他の場所で説明されている漸進的な劣化に反します。

JPEGが再圧縮されると、技術的にはどうなりますか？ 失われているものとその方法 画像は本当にテレビに表示されていた雪の混乱に本当に変わりますか？複数回再圧縮した後にバラバラになる画像を表示しているビデオはどうですか？

（単に手を振って、損失の一般的な概念に訴えないでください。）

（この質問とこれまでに引き付けられた回答は、JPEGファイルが複数回再圧縮されたときに画像の劣化を引き起こすまたは防ぐ技術的要因（特定の設定と画像操作）に焦点を当てています。）

ほとんどすべての画像品質の低下は、画像がJPEGとして初めて圧縮されるときに発生します。JPEGが同じ設定で再圧縮される回数に関係なく、世代の損失は丸め誤差に制限されます。

• MCUの境界はそのまま残ります（8x8ブロック）。

• クロマサブサンプリングは無効です。

• 一定のDQT（同じ品質設定）。

ただし、上記の基準を満たさない反復ごとに丸め誤差が大きくなる場合があり、すべての元のファイルのバックアップを保持することをお勧めします。

JPEG圧縮アルゴリズム

1. 色空間を変換します。必要に応じて、色情報をダウンサンプリングします（彩度サブサンプリング）（ロッシー）。ダウンサンプリングされていない場合、情報の損失は丸め誤差の結果です。

2. セグメンテーション。各チャネルを8x8ブロックに分割します（MCU = Minimal Coding Unit）。 （無損失の）

   注：クロマサブサンプリングが有効になっている場合、MCUは元の画像に関して実質的に16x8、8x16、または16x16になる場合があります。ただし、MCUはすべて8x8ブロックのままです。

3. 各MCUの離散コサイン変換（DCT）。情報の損失は、丸め誤差の結果です。

4. 量子化。 MCUの各セルの値は、量子化テーブル（DQT）で指定された数値で除算されます。値は切り捨てられ、その多くはゼロになります。 これは、アルゴリズムの主要な損失部分です。

5. ジグザグスキャン。各MCUの値を、ジグザグパターンに従って数字のシーケンスに再配置します。量子化中に発生したゼロは一緒にグループ化されます。 （無損失の）

6. DPCM =差分パルス符号変調。番号シーケンスを圧縮しやすい形式に変換します。 （無損失の）

7. RLE =ランレングスエンコーディング。連続したゼロは圧縮されます。（無損失の）

8. エントロピー/ハフマンコーディング。 （無損失の）

JPEGの再圧縮

そのノートカラーチャネル及び量子化をダウンサンプリングすることのみ意図的に非可逆工程です。とりあえず丸め誤差を別にすれば、他のすべてのステップはロスレスです。量子化が行われると、ステップを反転して繰り返すと同じ結果が得られます。つまり、（同じDQTを使用した）再量子化はロスレスです。

原則として、最初のパス後に無損失のリサンプリングアルゴリズムを作成することができます。ただし、ImageMagickの実装では、この画像に見られるように、定常状態に達する前に色が大幅にシフトする場合があります。

最適な条件が与えられた場合、同じ品質設定でJPEGを再圧縮すると、まったく同じJPEGになります。つまり、JPEGの再圧縮は潜在的に可逆です。実際には、JPEGの再圧縮は無損失ではありませんが、丸め誤差の影響を受け、制限されます。が丸め誤差がしばしば最終的にゼロに収束し、全く同じ画像が再作成され、その結果、クロマサブサンプリングは、有意な色の変化をもたらすことができます。

デモンストレーション（同じ品質設定）

bashImageMagickを使用して、特定の品質設定でJPEGファイルを繰り返し再圧縮する次のスクリプトを作成しました。

#!/usr/bin/env bash
n=10001; q1=90
convert original.png -sampling-factor 4:4:4 -quality ${q1} ${n}.jpg

while true ; do
   q2=${q1}            # for variants, such as adding randomness
   convert ${n}.jpg -quality ${q2} $((n+1)).jpg
   #\rm $((n-5)).jpg   # uncomment to avoid running out of space
   n=$((n+1))

   echo -n "$q2  "
   md5sum ${n}.jpg
done

数百回繰り返し実行した後md5sum、結果を実行しました。

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

880db8f146db87d293def674c6845007  10316.jpg
880db8f146db87d293def674c6845007  10317.jpg
880db8f146db87d293def674c6845007  10318.jpg
880db8f146db87d293def674c6845007  10319.jpg
880db8f146db87d293def674c6845007  10320.jpg

実際、丸め誤差がゼロに収束し、まったく同じ画像が何度も再現されていることがわかります。

さまざまな画像と品質設定でこれを複数回繰り返しました。通常、定常状態に達し、まったく同じ画像が何度も再現されます。

何についてmattdmの結果@？

Ubuntu 18.04でImagemagickを使用してmattdmの結果を複製しようとしました。オリジナルはRawtherapeeのTIFFへの生の変換でしたが、もう利用できないようです。その代わりに、私は拡大版を取り、元のサイズ（256x256）に縮小しました。その後、収束するまで75で繰り返し再圧縮しました。結果は次のとおりです（オリジナル、1、n、差）：

私の結果は異なります。真のオリジナルがなければ、違いの理由を判断することは不可能です。

何についてのTHSのモンタージュ@？

90で収束するまで、モンタージュの左上隅から画像を再圧縮しました。これが結果です（元の、1、n、差）。

クロマサブサンプリングを有効にすると、定常状態に達するまでに色が変化します。

少数の設定間で変更する

変数を変更することによりq2、品質設定を均等に分布した値のセットに制限できます。

q2=$(( (RANDOM % 3)*5  + 70 ))

以下のための選択肢を設定する少数の、平衡は、最終的に到達できる MD5値が繰り返し始めるときに見られます。セットが大きいほど、時間がかかり、平衡に達する前にイメージが悪化するようです。

平衡状態で起こると思われるのは、量子化前のDCT係数がすべての（またはほとんどの）量子値で割り切れなければならないことです。たとえば、DCT係数が3と5で交互に分割される2つのDQTを切り替える場合、DCT係数が15で割り切れるときに平衡に達します。これは、品質の低下が元の設定の差よりもはるかに大きい理由です。

多数の設定間での変更

Eeyoreは次のq2ように変更された場合、満足しません。

q2=$(( (RANDOM % 9)  + 90 ))

ビデオを作成するには、次を使用しますffmpeg。

rename 's@1@@' 1*.jpg
ffmpeg -r 30 -i %04d.jpg -c:v libx264 -crf 1 -vf fps=25 -pix_fmt yuv420p output.mp4

最初の9999回の繰り返しを見るのは、水の沸騰を見るのとほとんど同じです。再生速度を2倍にしたい場合があります。11999年の反復後のEeyoreは次のとおりです。

MCUの境界が変更された場合はどうなりますか？

変更の回数が限られている場合、再圧縮を繰り返して定常状態に達する可能性があります。各反復で変更が発生した場合、おそらくDQTが変更されたときと同様の方法で画像が劣化します。

• これは、8で割り切れない寸法で画像を回転させるビデオで起こります。

編集はどうですか？

編集後の再圧縮の効果は、実行される特定の編集に依存します。たとえば、JPEGアーティファクトを減らした後、同じ品質設定で保存すると、同じアーティファクトが再導入されます。ただし、ヒーリングブラシなどの局所的な変更を適用しても、触れられていない領域には影響しません。

画質の最大の低下は、ファイルが指定の品質設定で初めて圧縮されたときに発生します。その後、同じ設定で再圧縮しても、丸め誤差よりも大きな変化は生じません。そのため、同じ品質設定で保存された他の画像のように、特定の品質設定での編集-再保存サイクルが期待されます（MCUの境界がそのままで、クロマサブサンプリングが無効になっている限り）。

それらのビデオはどうですか？

• JPEG実装に問題がありますか？（Photoshopで10/12に500回再保存します。）

• 品質設定の変更。（ほとんどのビデオ。）

• MCUの境界を破壊します。（トリミングまたは回転）

• 画像の品質を低下させたり、JPEGアルゴリズムを妨害したりするその他の操作

再圧縮されたJPEGでオリジナルを上書きできますか？

すべての元のファイルのバックアップを保持することは賢明ですが、誤って1つのファイルを上書きした場合、損害はおそらく制限されます。クロマサブサンプリングを無効にしてJPEG で作業することも問題ありません。

JPEGは、色ごとに8ビット以上を使用する画像には使用できません。

特に高レベルのJPEG圧縮を使用している場合、再圧縮の損失は現実的です。

あなたは正確に同じパラメータを持つJPEGファイルの保存・再あれば理論的には、および 8×8つのブロックにあなたの作物を揃えている、劣化がなければならない最低限のこと。ただし、高レベルの圧縮を使用している場合は、最初の圧縮によって導入されたアーティファクトが画像の永続的な変更であり、再圧縮されてアーティファクトが増えるため、さらなる損失が発生します。

低レベルの圧縮（Gimpの「100」やPhotoshopの11または12などの高品質）で再保存すると、新しく追加されたアーティファクトは気づきにくくなります。画像が良くなることはありませんが、著しく悪くなることはありません。しかし、それはします画像全体の変化を紹介しています。

簡単なテストとして、ImageMagickを使用してJPEG画像を75％で何度も再圧縮しました。以下のサンプルは、さらなる圧縮を回避するためにPNGファイルとしてアップロードされ、効果をより明確にするためにPNGに変換するとサイズが2倍になりました。（テストで使用したオリジナルは2倍ではありませんでした。）8回のリサンプリングの後、効果は完全に安定した結果に収束し、再圧縮によりビット単位の同一ファイルが得られることがわかりました。

これが非圧縮のオリジナルです：

75％JPEGに移行した結果は次のとおりです。

そして、これが再保存されたものです：

その1秒の保存により、さらに多くの劣化が発生します！

そして、これが最終的な収束画像です（8回目のパス）：

繰り返しますが、いくつかの偽色パターンを含む色は間違いなくさらに外れており、ブロック状のアーティファクトがさらに飛び出します。アルゴリズムは収束しますが、大幅に劣化したバージョンになります。だから、それをしないでください。

しかし、9パス後の99％の品質レベルの同じものがあります（それが収束するため、それ以降のパスは同じです）：

ここでは、違いはほとんど記録されません。（つまり、文字通り、ピクセルごとに非圧縮バージョンと比較してください。偏差はごくわずかなランダムノイズです。）では、最初の75％の画像に戻って99％で再保存するとどうなりますか。さて、これ、（一度だけ）：

高品質での保存は、同じパラメータで再保存するよりも明らかに目に見えて優れています。しかし、ピンクのトリミングと目の周りに明らかな新しい劣化があります。同じ設定のリサイクルバージョンでは、JPEGアーティファクトは再圧縮ごとに誇張されています。私が選んだ低解像度と低品質で、それはすべてを異なる方法で再圧縮するよりも悪いことがわかりました。

それらのビデオで：私はこれをトップのGoogleヒットとして見つけました。説明に記載されていることに注意してください。

これは、ランダムに高品質の設定（85以上）で JPEGイメージを何度も再エンコードすると発生します。

強調が追加されました —これは、同じ設定で保存するか、超高品質で保存する代わりに、毎回ランダムな設定が使用されるため、収束がない理由を説明します。

私が見つけた第二のビデオは言います：

JPEGイメージがコピーされ、各イメージごとに完全な回転が行われました。[...]（596「時計回りに回転」アクション）

したがって、再び、エラーを蓄積し続けるために何かが行われました。

いずれにせよ、実用的な写真編集のために、一度に 75％を節約することは、100万回に99％を節約するよりもはるかに悪いことに言及する価値があります。私の例では、75％のアーティファクトは非常に明白であるため、さらなる劣化は海に水を捨てるようなものです。これらのアーティファクトが実際に表示されないほど十分に高いレベルで保存する場合は、元の設定で再度保存することをお勧めします。もちろん、圧縮されていないオリジナルから常に作業を続けることができれば、より良い結果が得られます。

何らかの理由でJPEGを使用する必要がある場合（または強く推奨する場合）は、初期ファイルの違いに気付かなくても、可能な限り最高の品質で保存するようにカメラを設定します。参照は、それだけの価値はペンタックスのプレミアムJPEG品質設定を使用しますか？その詳細については、必ずしも実際にペンタックス固有ではありません。

再圧縮は画質に測定可能な影響を与えますが、圧縮率を変更するとその影響はより顕著になります。

ここでは、ラインフィーチャと連続フィーチャの組み合わせを含むテストイメージで実行された操作のいくつかのSSIM値として簡単に確認します。JPG95を選択したのは、それがAd-photo schoolで使用するように教えられたためであり、JPG83はデジタルコンテンツプロバイダーの間で一般的であるためです。

• TIFF画像をJPG95-.9989として保存
• Tiff画像をJPG83-.9929として保存
• JPG95画像をJPG95として10回再保存する-.9998
• JPG83画像をJPG83として10回再保存-.9993
• JPG95としてJPG95を再保存してからJPG95として再保存-.9929
• JPG95をJPG83、JP83をJP92、JPG92をJPG86として保存します。

したがって、同じ圧縮で10回再保存すると失われる構造的類似性の量は、tiffの品質で保存する場合の失われる量の1/10です。ただし、JPG圧縮を一度でも変更しても品質が低下することは、そのイメージをTiffからJPGに保存することで失われる品質と同じです。

このテストをさらにいくつかの方法で実行し、更新します。

方法論：ImageJで：

1. Tiff RGBをグレースケール8ビットに変換
2. Tiff OriginalからJPG95およびJPG83を保存します
3. 指定されたとおりに、さらに再保存操作を実行します
4. 比較画像を読み込み、SSIM Index Pluginを使用します

注：SSIM値を初めて見る多くの人は、それらをパーセントとして読み取り、差が小さいと仮定します。これは必ずしも真実ではありません。SSIM値は、1からの分散と見なされるのではなく、相互に比較する必要があります。

いくつかの実験のようなものはありません。次のbashスクリプト（Linux上で記述され、ImageMagickがあればOSXで動作します）：

• 最初の画像から始まる（名前付きstep000.jpg）
• JPEGファイルを取得し、白いドットを追加して（これが新しい画像であることを証明するために）、（ロスレスPNG）として保存します
• PNGを取得し、それをJPEGとして再圧縮します（したがって、JPEGからJPEGに圧縮することはなく、ソフトウェアが単にエンコードされたブロックをコピーするという仮説を立てることはできません）
• 2つのJPEG間の異なるピクセルを示す画像を作成します
• 前のステップの出力JPGを使用して、すすいで繰り返します

結果は次のとおりです。

1. 高いJPG品質で多くの損失はありません
2. 丸めエラーは最終的に落ち着きますが、数世代後、物事はそれ以上悪化しません。

もちろん、これはすべて、JPEGが毎回同じパラメーターで同じソフトウェアによって保存されることを前提としています。

#! /bin/bash
# Runs successive JPEG saves on an image to evaluate JPEG losses

# convert & compare command from imagemagick
# if you use a recent version of IM, set these variables to:
# compare="magick compare"
# convert="magick convert"
convert=convert
compare=compare

dotradius=2
defaultsteps=10
defaultquality=90 # default quality for "convert"

function usage {
        echo "Usage: $0 [quality [steps]]"
        echo ""
        echo "Where:"
        echo "       - 'quality' is the quality factor of the JPEG compression "
        echo "          (1-100, 100 is best, default is $defaultquality)"
        echo "       - 'steps' is the number of successive steps to perform"
        echo "         (default is $defaultsteps)"
        echo ""
        echo "Produces:"
        echo "   - successive saves of a JPEG image to test JPEG-induced losses."
        echo "   - compare images with the original file and the 1st JPEG save."
        echo ""
        echo "Starts from a 'step000.jpg' file in the current directory."
        exit 1
}

[[ -n "$3" ]] && { usage ; exit 1 ; }
steps=${1:-$defaultsteps}
quality=${2:-$defaultquality}    
dotcolor="white" # change this if the top of the image is too clear

echo "Running with $steps steps with quality $quality"

for step in $(seq $steps)
do 
    echo "Step $step of $steps"
    src=$(printf step%03d $(( $step - 1 )) ) 
    dst=$(printf step%03d $(( $step )) )
    dif=$(printf diff%03d $(( $step )) )
    # dot coordinates
    let cxc="2 * $dotradius * $step"
    let cxr="$cxc + $dotradius"
    let cyc="$dotradius * 2"
    let cyr="$dotsradius * 2"

    $convert $src.jpg -fill white -draw "circle $cxc,$cyc,$cxr,$cyr" $dst.png
    $convert $dst.png -quality $quality $dst.jpg
    rm $dst.png
    $compare $src.jpg $dst.jpg $dif.jpg
done

とりあえず、結果は表示しませんが、自分の写真を試してみることをお勧めします。十分なコメントがあれば、サンプルを追加します。