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

29

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:

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.)

xiota
quelle
Relevant .
Mehrdad
2
@MonkeyZeus Einige (kleine) Bilddaten gehen durch Rundungsfehler bei Qualität 100 verloren. Eine erneute Komprimierung bei derselben Einstellung (z. B. 80) führt nicht zu einem progressiven Datenverlust. Dies ist das "allgemeine Wissen", das in dieser Frage und Antwort behandelt werden soll.
Xiota
1
@MonkeyZeus Die Werte "100" und "80" (oder "10, 11, 12" in Photoshop) sind willkürlich - 100% sind nicht verlustfrei.
Mattdm

Antworten:

32

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):

versuche mattdm zu replizieren

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):

versuche ths-montage zu replizieren

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

ths-Farbverschiebung

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:

11999 Iterationen, zufällige DQT

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.

xiota
quelle
5
Bei Load- Edit- Save-Loops sieht das Bild jedoch ganz anders aus . In diesem Fall führt eine wiederholte Quantisierung zu einer Verschlechterung.
Donnerstag,
2
Ich habe gerade einen Test mit dem gleichen Skript wie in der Antwort gemacht. Hier ist eine Montage von jedem 20. Bild bis 100: i.stack.imgur.com/xtob6.jpg , die von Bedeutung ist.
Donnerstag,
2
Ah. habe das problem mit meinem bild gefunden. Wenn Sie die Chroma-Unterabtastung aktiviert haben, führt dies zu einer fortschreitenden Verschlechterung.
Donnerstag,
2
Fand das auch. Durch Aktivieren der Chroma-Unterabtastung wird die Farbe im Bild erheblich verändert, bevor der stationäre Zustand erreicht wird.
Xiota
2
Wiederholtes Laden und Speichern mit genau den gleichen Parametern würde wahrscheinlich nicht zu einem unbegrenzten Qualitätsverlust führen, da die meisten Eingabedateien geladen und erneut gespeichert werden könnten, ohne dass ein zusätzlicher Rundungsfehler auftritt, und Dateien, die von Rundungsfehlern betroffen wären, würden wahrscheinlich in umgewandelt Dateien, die nicht würden. Andererseits können wiederholte Lade- / Speicherzyklen, die zwischen ähnlichen, aber nicht identischen Komprimierungsparametern wechseln, zu Rundungsfehlern bei jedem Zyklus führen.
Supercat
20

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:

Original, keine JPEG-Komprimierung

Hier ist das Ergebnis von 75% JPEG:

erstes JPEG

Und hier ist das neu gespeichert:

zweiter Durchgang

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

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

konvergiertes jpeg

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):

99% 9 mal

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):

Einmal 75% und dann einmal 99%

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.

mattdm
quelle
(1) Sie sparen 75%. Bei dieser Einstellung wird ein Verlust der Bildqualität erwartet. (2) Dieses Bild wurde ausgewählt und geändert, um JPEG-Komprimierungsartefakte zu übertreiben. (3) Das Bild konvergiert nach 8 Komprimierungsrunden, wonach die Bildqualität nicht mehr verringert wird. (4) Ein Video dieses Bildes, das "Generationsverlust" zeigt, würde nach der ersten 1/4 Sekunde eine ganze Menge nichts mehr passieren.
Xiota
5
(1) ja (2) "Ausgewählt" als typisches Foto, auf dem sich jemand für so etwas interessiert. "Geändert" nur zum Vergrößern. Beachten Sie, dass dies nur hier angezeigt wird - ich habe die Größe des Bildes, mit dem ich gearbeitet habe, nicht verdoppelt. (3) Ja, aber in der Praxis sind es die ersten Runden, die Sie interessieren könnten. (4) Das ist wahr, aber es bedeutet nicht, dass es in irgendeiner Weise nützlich ist, sich dem schlimmsten Fall anzunähern und dort zu bleiben.
Mattdm
Nehmen Sie zum Replizieren das erste Bild und ändern Sie die Größe auf 256 × 256, ohne erneutes Abtasten oder Interpolieren.
Mattdm
Ich kann nicht sehen , zwischen den Bildern viel Unterschied es Ihnen zeigen. Wenn ich jedoch den Unterschied zwischen einem einfach neu komprimierten und einem mehrfach neu komprimierten Bild nehme und es verstärke, um es sichtbar zu machen, erhalte ich das (viel überzeugendere) Ergebnis: i.stack.imgur.com/57uaY.png (siehe mein gelöschtes Bild) Beantworten Sie, was genau getan wurde.) Es ist überzeugender, weil die Leute nicht ständig auf das Bild starren müssen, um winzige Unterschiede zu erkennen.
Szabolcs
Die Unterschiede sind ziemlich klein. Wenn Sie einen großen LCD-Bildschirm haben, kann das unterschiedliche "Gamma", das sich aus geringfügig unterschiedlichen Betrachtungswinkeln ergibt, dazu führen, dass Artefakte stärker hervorgehoben werden.
Xiota
5

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.

PhotoScientist
quelle
@xiota, ich verwende ein SSIM-Plugin für ImageJ. Es ist eine der wenigen SSIM-Implementierungen, die die Anpassung von Parametern ermöglicht (ich stelle die Filterbreite auf 8 ein, damit Änderungen innerhalb der 16px-JPEG-Blöcke wahrscheinlicher erkannt werden.) Ich bevorzuge SSIM, da es empfindlicher auf Energieunterschiede reagiert Umverteilung. Ein Differenzbild kann irreführend sein, wenn sich Unterschiede aufheben oder sich die Unterschiede auf einen kleinen Bereich konzentrieren.
PhotoScientist
Und zu Ihrer zweiten Frage: Der Unterschied zwischen JPG95 und JPG83 und JPG95 ist der gleiche wie zwischen Tiff und JPG83. Wenn Sie Tiff-JPG95-JPG83-JPG95 möchten, ist das .9923
PhotoScientist
Es wurde ein Versuch mit vier verschiedenen Komprimierungen hinzugefügt. Der Verlust ist immer noch größer, aber es ist klar, dass die "Konvergenz", die über mehrere Generationen der gleichen Komprimierung beobachtet wird, auch vorhanden ist, wenn mehrere verschiedene Komprimierungen versucht werden. Ich würde das immer noch gerne in einem App-zentrierten Workflow ausprobieren, aber das erfordert etwas mehr Beinarbeit.
PhotoScientist
Ein weiteres Problem ist, dass es keine Standardzuordnung von "Qualitätseinstellungen" zu SSIM-Schwellenwerten gibt und auch keine Möglichkeit besteht, festzustellen, welche Qualitätseinstellungen erforderlich wären, um einen erheblichen Informationsverlust zu vermeiden. Wenn ein JPEG geladen und mit einer ausreichend hohen Einstellung gespeichert wird, kann ein zusätzlicher Qualitätsverlust vermieden werden, die Datei wird jedoch wahrscheinlich größer. Wenn man nicht weiß, welche Einstellung bei der Erstellung einer Datei verwendet wurde, kann es schwierig sein, zu bestimmen, welche Einstellung beim erneuten Speichern verwendet werden soll.
Supercat
4

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.

Magnet
quelle
1
Ich war neugierig auf die verschiedenen Software-Sachen. Ich habe versucht, 7x von 7 verschiedenen Software zu speichern. Der Unterschied war ziemlich groß, also habe ich ihn aufgeschlüsselt, um zu sehen, ob jede Anwendung den gleichen Verlust hatte. 1 der Apps war für die gesamte Variation verantwortlich. Nachdem ich den roten Hering entfernt hatte, waren 6-
fache
Es gibt wahrscheinlich schlecht codierte Software. Es ist auch möglich, dass das Mischen der Algorithmen aus verschiedenen Apps verhindert, dass sich auch die Rundungsfehler einstellen.
Xenoid
@xiota, es war ein seltsames kleines Programm namens FLEMinimizer. Ich erinnere mich nicht einmal, warum ich es überhaupt hatte. Die anderen waren ImageJ, Matlab, Photoshop, FastStone Image Viewer, Ifranview und CameraRaw. Zwischen diesen sechs Schritten gab es fast keine Abweichungen.
PhotoScientist