Welche Faktoren verursachen oder verhindern einen „Generationsverlust“, wenn JPEGs mehrmals neu komprimiert werden?

Ich habe jahrelang geglaubt, dass das wiederholte Komprimieren von JPEG-Dateien die Qualität allmählich verschlechtern würde, bis sie nicht mehr wiederzuerkennen sind, wie dies beim Erstellen von Fotokopien der Fall ist. Dies ist intuitiv sinnvoll, da JPEG ein verlustbehaftetes Format ist. Es gibt auch andere Q & As, die behaupten, dass dies so ist:

• Welche Bildqualität geht beim erneuten Speichern eines JPEG-Bildes in MS Paint verloren?

• Verringert das einfache Öffnen und Schließen einer JPEG-Datei die Bildqualität?

Ich habe jedoch auch gelesen, dass das erneute Komprimieren von JPEGs mit derselben Qualitätsstufe die Bildqualität nicht beeinträchtigt. Dies läuft der an anderer Stelle beschriebenen allmählichen Verschlechterung zuwider.

Was passiert technisch , wenn ein JPEG erneut komprimiert wird?  Was geht verloren und wie? Verwandelt sich das Bild wirklich in das schneebedeckte Chaos, das früher im Fernsehen zu sehen war? Was ist mit diesen Videos, die Bilder zeigen, die nach mehrmaliger Neukomprimierung auseinanderfallen?

(Bitte winken Sie nicht nur mit der Hand und appellieren Sie an das allgemeine Konzept der Verlusthaftigkeit.)

(Diese Frage und die Antworten , die es so weit angezogen hat, den Schwerpunkt auf den technischen Faktoren (spezifische Einstellungen und Bildmanipulationen) , die Ursache oder Bildverschlechterung zu verhindern , wenn eine JPEG - Datei erneut komprimiert wird mehrere Male.)

Fast alle Bildqualitätsverluste treten auf, wenn ein Bild zum ersten Mal als JPEG komprimiert wird. Unabhängig davon, wie oft ein JPEG mit denselben Einstellungen erneut komprimiert wird , sind Generationsverluste auf Rundungsfehler beschränkt.

• Die MCU-Grenzen bleiben erhalten (8x8 Blöcke).

• Chroma-Unterabtastung ist deaktiviert.

• Konstante DQT (gleiche Qualitätseinstellung).

Jedoch kann groß sein Rundungsfehler für jede Iteration , dass die oben genannten Kriterien nicht erfüllt sind, und es ist ratsam , Backups aller Originaldateien zu halten.

Der JPEG-Komprimierungsalgorithmus

1. Farbraum konvertieren. Falls gewünscht, die Farbinformationen herunterrechnen (Chroma-Unterabtastung) (verlustbehaftet) . Wenn nicht heruntergerechnet, ist Informationsverlust das Ergebnis eines Rundungsfehlers .

2. Segmentierung. Teilen Sie jeden Kanal in 8x8 Blöcke (MCU = Minimal Coding Unit). (Verlustfrei)

   Hinweis: Wenn die Chroma-Unterabtastung aktiviert ist, können MCUs in Bezug auf das Originalbild effektiv 16 x 8, 8 x 16 oder 16 x 16 Pixel groß sein. Die MCUs bestehen jedoch immer noch aus 8x8-Blöcken.

3. Diskrete Cosinustransformation (DCT) auf jeder MCU. Informationsverlust ist das Ergebnis eines Rundungsfehlers .

4. Quantisierung.  Der Wert in jeder Zelle der MCU wird durch eine in einer Quantisierungstabelle (DQT) angegebene Zahl geteilt. Die Werte sind abgerundet, viele davon werden zu Null. Dies ist der primäre verlustbehaftete Teil des Algorithmus.

5. Zick-Zack-Scan. Ordnen Sie die Werte in jeder MCU nach einem Zick-Zack-Muster in eine Folge von Zahlen um. Die bei der Quantisierung aufgetretenen Nullen werden zusammengefasst. (Verlustfrei)

6. DPCM = Differential Pulse Code Modulation. Konvertieren Sie die Zahlenfolgen in eine Form, die einfacher zu komprimieren ist. (Verlustfrei)

7. RLE = Run Length Encoding. Aufeinanderfolgende Nullen werden komprimiert. (Verlustfrei)

8. Entropie / Huffman-Codierung. (Verlustfrei)

JPEGs erneut komprimieren

Beachten Sie, dass das Downsampling der Farbkanäle und die Quantisierung die einzigen absichtlich verlustbehafteten Schritte sind . Abgesehen von Rundungsfehlern sind alle anderen Schritte verlustfrei. Sobald die Quantisierung erfolgt ist, führt das Umkehren und Wiederholen des Schritts zu identischen Ergebnissen. Mit anderen Worten ist die Neuquantisierung (mit demselben DQT) verlustfrei .

Grundsätzlich ist es möglich, einen Resampling-Algorithmus zu erstellen, der nach dem ersten Durchgang verlustfrei ist. Bei der Implementierung in ImageMagick können sich die Farben jedoch drastisch verschieben, bevor ein stabiler Zustand erreicht ist, wie im Bild zu sehen ist.

Unter optimalen Bedingungen würde das erneute Komprimieren eines JPEG mit denselben Qualitätseinstellungen genau dasselbe JPEG ergeben. Mit anderen Worten, das erneute Komprimieren von JPEGs ist potenziell verlustfrei . In der Praxis ist das erneute Komprimieren von JPEGs nicht verlustfrei, sondern unterliegt Rundungsfehlern und wird durch diese begrenzt. Obwohl Rundungsfehler häufig irgendwann gegen Null konvergieren , so dass genau dasselbe Bild neu erstellt wird, kann die Chroma-Unterabtastung zu erheblichen Farbänderungen führen.

Vorführung (gleiche Qualitätseinstellung)

Ich habe das folgende bashSkript geschrieben, das ImageMagick verwendet, um eine JPEG-Datei mit einer bestimmten Qualitätseinstellung wiederholt zu komprimieren:

#!/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

Nachdem ich es einige hundert Iterationen laufen ließ, führte ich md5sumdie folgenden Ergebnisse aus:

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

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

Wir können sehen, dass der Rundungsfehler tatsächlich gegen Null konvergiert ist und dass immer wieder genau dasselbe Bild reproduziert wird .

Ich habe dies mehrfach mit unterschiedlichen Bildern und Qualitätseinstellungen wiederholt. Normalerweise stabiler Zustand erreicht ist , und die genaue gleiche Bild wiedergegeben werden immer und immer wieder .

Was ist mit @ mattdms Ergebnissen ?

Ich habe versucht, die Ergebnisse von mattdm mit Imagemagick unter Ubuntu 18.04 zu replizieren. Das Original war eine Rohkonvertierung zu TIFF in Rawtherapee, aber es scheint nicht mehr verfügbar zu sein. An seiner Stelle habe ich die vergrößerte Version genommen und auf die ursprüngliche Größe (256x256) verkleinert. Dann habe ich bei 75 wiederholt komprimiert, bis ich Konvergenz bekam. Hier ist das Ergebnis (Original, 1, n, Unterschied):

Meine Ergebnisse sind unterschiedlich. Ohne das wahre Original ist der Grund für den Unterschied nicht zu bestimmen.

Was ist mit @ ths Montage ?

Ich habe das Bild von der oberen linken Ecke der Montage bis zur Konvergenz bei 90 erneut komprimiert. Dies ist das Ergebnis (Original, 1, n, Differenz):

Nach dem Aktivieren der Chroma-Unterabtastung ändern sich die Farben bis zum Erreichen des stationären Zustands.

Wechseln zwischen einer kleinen Anzahl von Einstellungen

Durch Ändern der Variablen q2kann die Qualitätseinstellung auf eine Reihe gleichmäßig verteilter Werte beschränkt werden.

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

Bei einer kleinen Anzahl von Einstellungsmöglichkeiten kann schließlich ein Gleichgewicht erreicht werden , das sich abzeichnet, wenn sich die md5-Werte wiederholen. Es scheint, je größer die Menge ist, desto länger dauert es und desto schlechter wird das Bild, bevor das Gleichgewicht erreicht werden kann.

Was im Gleichgewicht zu passieren scheint, ist, dass der DCT-Koeffizient vor der Quantisierung alle (oder die meisten) der Quantenwerte teilbar sein muss. Wenn Sie beispielsweise zwischen zwei DQTs wechseln, bei denen der DCT-Koeffizient abwechselnd durch 3 und 5 geteilt wird, wird das Gleichgewicht erreicht, wenn der DCT-Koeffizient durch 15 teilbar ist. Dies erklärt, warum der Qualitätsabfall viel größer ist als der Unterschied zwischen den ursprünglichen Einstellungen.

Wechseln zwischen einer größeren Anzahl von Einstellungen

Eeyore ist nicht glücklich, wenn q2sich das so ändert:

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

Verwenden Sie zum Erstellen eines Videos 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

Das Anschauen der ersten 9999-Iterationen ist fast so, als würde man zusehen, wie Wasser kocht. Möglicherweise möchten Sie die Wiedergabegeschwindigkeit verdoppeln. Hier ist Eeyore nach 11999 Iterationen:

Was ist, wenn sich die MCU-Grenzen ändern?

Wenn Änderungen nur wenige Male auftreten, wird das wiederholte erneute Komprimieren wahrscheinlich den stabilen Zustand erreichen. Wenn bei jeder Iteration Änderungen auftreten, wird sich das Bild wahrscheinlich auf ähnliche Weise verschlechtern, wie wenn sich DQT ändert.

• Dies geschieht in Videos, die ein Bild mit Dimensionen drehen , die nicht durch 8 teilbar sind.

Was ist mit dem Bearbeiten?

Die Auswirkung der Neukomprimierung nach der Bearbeitung hängt von der jeweils ausgeführten Bearbeitung ab. Wenn Sie beispielsweise nach dem Reduzieren von JPEG-Artefakten dieselbe Qualitätseinstellung speichern, werden dieselben Artefakte wieder eingefügt. Das Anwenden einer lokalisierten Änderung, z. B. eines Reparaturpinsels, hat jedoch keine Auswirkungen auf Bereiche, die nicht berührt wurden.

Der größte Rückgang der Bildqualität tritt auf, wenn die Datei zum ersten Mal mit einer bestimmten Qualitätseinstellung komprimiert wird. Das anschließende erneute Komprimieren mit derselben Einstellung sollte keine Änderung hervorrufen, die größer als der Rundungsfehler ist. Daher würde ich erwarten, dass Zyklen zum erneuten Speichern von Bearbeitungen bei einer bestimmten Qualitätseinstellung wie jedes andere Bild aussehen, das mit derselben Qualitätseinstellung gespeichert wurde (solange die MCU-Grenzen intakt bleiben und die Chroma-Unterabtastung deaktiviert ist ).

Was ist mit diesen Videos?

• Fehlerhafte JPEG-Implementierung? ( Mit Photoshop 500-mal um 10/12 erneut speichern. )

• Ändern der Qualitätseinstellungen. (Die meisten Videos.)

• Unterbrechung der MCU-Grenzen. (Zuschneiden oder Drehen )

• Andere Manöver, die die Bildqualität beeinträchtigen oder den JPEG-Algorithmus beeinträchtigen?

Kann ich meine Originale mit neu komprimierten JPEGs überschreiben?

Es ist ratsam, Sicherungskopien aller Originaldateien zu erstellen. Wenn Sie jedoch versehentlich eine Datei überschreiben, ist der Schaden wahrscheinlich begrenzt. Es wäre auch in Ordnung, in JPEG mit deaktivierter Chroma-Unterabtastung zu arbeiten.

JPEG kann nicht für Bilder verwendet werden, die mehr als 8 Bit pro Farbe verwenden.

Rekomprimierungsverlust ist real, insbesondere wenn mit höheren JPEG-Komprimierungsstufen gearbeitet wird.

Theoretisch sollte die Verschlechterung minimal sein , wenn Sie JPEG-Dateien mit genau den gleichen Parametern erneut speichern und Ihren Zuschnitt auf 8 × 8-Blöcke ausgerichtet haben . Wenn Sie jedoch eine hohe Komprimierungsstufe verwenden, treten weitere Verluste auf, da die durch die anfängliche Komprimierung eingeführten Artefakte dauerhafte Änderungen am Bild sind und ebenfalls erneut komprimiert werden, was zu weiteren Artefakten führt.

Wenn Sie mit einer geringen Komprimierungsstufe (hohe Qualität, z. B. "100" in Gimp oder 11 oder 12 in Photoshop) erneut speichern, sind neu hinzugefügte Artefakte kaum zu bemerken. Das Bild wird dadurch nicht besser , aber nicht wesentlich schlechter. Es werden jedoch Änderungen im gesamten Image vorgenommen.

Als schnellen Test habe ich ImageMagick verwendet, um ein JPEG-Bild immer wieder mit 75% zu komprimieren. Die folgenden Beispiele werden als PNG-Dateien hochgeladen, um eine erneute Komprimierung zu vermeiden. Ihre Größe wurde bei der Konvertierung in PNG verdoppelt, um den Effekt deutlicher zu machen. (Die im Test verwendeten Originale wurden nicht verdoppelt.) Es stellte sich heraus, dass der Effekt nach acht Neuabtastungen zu einem vollkommen stabilen Ergebnis konvergierte, bei dem die erneute Komprimierung zu einer bitweise identischen Datei führte.

Hier ist das unkomprimierte Original:

Hier ist das Ergebnis von 75% JPEG:

Und hier ist das neu gespeichert:

Diese Einsparung von einer Sekunde führt zu einer erheblichen zusätzlichen Verschlechterung!

Und hier ist das endgültige konvergierte Bild (8. Durchgang):

Wieder sind die Farben definitiv noch schlechter, einschließlich einiger falscher Farbmuster, und die blockartigen Artefakte springen mehr heraus. Der Algorithmus konvergiert, aber zu einer deutlich verschlechterten Version. Also mach das nicht.

Aber hier ist dasselbe mit einer 99% -Qualitätsstufe nach 9 Durchgängen (der Punkt, an dem es konvergiert, sodass weitere Durchgänge identisch sind):

Hier macht sich der Unterschied kaum bemerkbar. (Ich meine das wörtlich; vergleiche sie Pixel für Pixel mit der nicht komprimierten Version und die Abweichung ist nur ein sehr geringes zufälliges Rauschen.) Und wenn ich zu diesem ersten 75% -Bild zurückkehre und es dann bei 99% speichere? Nun, dies (nach nur einem Mal):

In hohen Qualität zu sparen ist auf jeden Fall sichtbar besser als mit den gleichen Parametern resaving, Art der zu meiner Überraschung. Aber es gibt eine offensichtliche neue Verschlechterung um das rosa Trimmen und die Augen. Mit der recycelten Version derselben Einstellungen werden die JPEG-Artefakte bei jeder erneuten Komprimierung übertrieben. Bei der von mir gewählten niedrigen Auflösung und Qualität ist das schlimmer, als alles anders zu komprimieren.

Zu diesen Videos: Ich fand diesen als Top-Google-Hit. Beachten Sie, dass in der Beschreibung steht:

Dies ist der Fall, wenn Sie ein JPEG-Bild mehrmals mit zufälligen Einstellungen für hohe Qualität (85 oder höher) neu codieren .

Hervorhebung hinzugefügt - dies erklärt, warum es keine Konvergenz gibt, da anstelle des Speicherns mit denselben Einstellungen oder des Speicherns mit höchster Qualität jedes Mal zufällige Einstellungen verwendet werden .

Das zweite Video, das ich gefunden habe, sagt:

Ein JPEG-Bild wurde kopiert und für jedes Bild um eine volle Umdrehung gedreht. [...] (596 Aktionen "im Uhrzeigersinn drehen")

Es wurde also wieder etwas unternommen, um die Fehler weiterhin zu akkumulieren.

Auf jeden Fall für die praktische Fotobearbeitung , zu erwähnen , es wert ist, dass 75% Einsparung einer Zeit ist viel schlimmer als bei 99% ein resaving Millionen mal . In meinem Beispiel sind die Artefakte bei 75% so offensichtlich, dass die weitere Verschlechterung dem Ablassen von Wasser in den Ozean gleicht. Wenn Sie so hoch speichern, dass diese Artefakte nicht wirklich sichtbar sind, ist das erneute Speichern mit den ursprünglichen Einstellungen eine gute Strategie. Natürlich, wenn Sie sich daran halten können, immer von unkomprimierten Originalen zu arbeiten, sind Sie besser dran.

Wenn Sie aus irgendeinem Grund nur mit JPEG arbeiten müssen (oder möchten), stellen Sie Ihre Kamera so ein, dass sie in der höchstmöglichen Qualität speichert , auch wenn Sie den Unterschied in den ursprünglichen Dateien nicht bemerken. Siehe Lohnt es sich, die Premium JPEG-Qualitätseinstellung von Pentax zu verwenden? Mehr dazu - nicht unbedingt Pentax-spezifisch.

Die Rekomprimierung wirkt sich messbar auf die Bildqualität aus, und dieser Effekt ist beim Ändern der Komprimierungsraten viel ausgeprägter.

Zur schnellen Überprüfung hier einige SSIM- Werte für Operationen, die an einem Testbild ausgeführt werden, das eine Kombination aus Linienmerkmalen und kontinuierlichen Merkmalen enthält. Ich habe JPG95 ausgewählt, weil mir das an der Ad-Photo School beigebracht wurde, und JPG83, weil das bei Anbietern von digitalen Inhalten üblich ist.

• Speichern Sie das Tiff-Bild als JPG95 - .9989
• Speichern Sie das Tiff-Bild als JPG83 - .9929
• Speichern Sie das JPG95-Bild 10-mal als JPG95 - .9998
• Speichern Sie das JPG83-Bild 10-mal als JPG83 - .9993
• Speichern Sie JPG95 erneut als JPG83 und anschließend als JPG95 - .9929
• Speichern Sie JPG95 erneut als JPG83, dann JP83 bis JP92, dann JPG92 bis JPG86 - .9914

Die Menge an struktureller Ähnlichkeit, die durch das zehnmalige Speichern bei derselben Komprimierung verloren geht, ist 1/10 der Menge, die durch das Speichern bei der Qualität von tiff verloren geht. Der Qualitätsverlust durch einmaliges Ändern der JPG-Komprimierung entspricht jedoch dem Qualitätsverlust beim Speichern dieses Bildes von Tiff in JPG.

Ich werde diesen Test auf einige weitere Arten ausführen und aktualisieren.

Methodik : In ImageJ:

1. Konvertieren Sie Tiff RGB in 8-Bit-Graustufen
2. Speichern Sie JPG95 und JPG83 von Tiff Original
3. Führen Sie weitere Resave-Vorgänge wie angegeben durch
4. Laden Sie Vergleichsbilder und verwenden Sie das SSIM-Index-Plugin

HINWEIS: Viele Personen, die sich zum ersten Mal mit SSIM-Werten befassen, lesen diese als Prozentsätze und gehen davon aus, dass der Unterschied gering ist. Dies ist nicht unbedingt wahr. SSIM-Werte sollten relativ zueinander verglichen werden, anstatt als Abweichung von 1 betrachtet zu werden.

Nichts wie experimentieren. Das folgende Bash-Skript (geschrieben unter Linux, könnte unter OSX funktionieren, wenn Sie ImageMagick haben ):

• beginnend mit einem ersten Bild (benannt step000.jpg)
• Nimmt eine JPEG-Datei, fügt einen weißen Punkt hinzu (um zu beweisen, dass es sich um ein neues Bild handelt) und speichert es als (verlustfreies PNG)
• Nimmt das PNG und komprimiert es erneut als JPEG (daher komprimieren wir niemals JPEG-zu-JPEG und können nicht annehmen, dass die Software nur codierte Blöcke kopiert).
• Erstellt ein Bild, das die verschiedenen Pixel zwischen den beiden JPEGs anzeigt
• Spülen und wiederholen Sie den Vorgang mit der JPG-Ausgabe des vorherigen Schritts

Das Ergebnis ist, dass:

1. Bei hohen JPG-Qualitäten ist der Verlust gering
2. Rundungsfehler klingen schließlich ab, nach einer kurzen Anzahl von Generationen verschlechtern sich die Dinge nicht mehr.

All dies setzt natürlich voraus, dass das JPEG jedes Mal von derselben Software mit denselben Parametern gespeichert wird.

#! /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

Da ich die Ergebnisse vorerst nicht zeigen werde, lasse ich Sie lieber mit Ihren eigenen Bildern experimentieren. Mit genügend Kommentaren werde ich ein Beispiel hinzufügen.