Ich beschäftige mich mit einem großen Archiv von Satellitenbildern der Erde, die jeweils im Abstand von 15 Minuten über demselben Gebiet aufgenommen wurden. Daher sind sie einander recht ähnlich. Zwei zusammenhängende Bilder sehen so aus:
Videoalgorithmen komprimieren mehrere ähnliche Bilder sehr gut. Allerdings sind diese Bilder zu groß für Videos (10848 x 10848) und die Verwendung von Video-Encodern würde die Metadaten der Bilder löschen. Daher wäre das Extrahieren und Wiederherstellen der Metadaten mühsam, selbst wenn ich einen Video-Encoder bekomme, der mit so großen Bildern arbeitet.
Um einige Tests durchzuführen, habe ich die 96 Bilder eines Tages auf 1080 x 1080 Pixel (insgesamt 40,1 MB) reduziert und verschiedene Komprimierungsmethoden mit den folgenden Ergebnissen ausprobiert:
- pdf: 39,8 MB
- rar: 39,8 MB
- 7z: 39,6 MB
- tar.bz2: 39,7 MB
- zpaq v7.14: 38,3 MB
- fp8 v2: 32,5 MB
- paq8pxd v45:30,9 MB
Die letzten drei sollen den Kontext besser ausnutzen und tatsächlich besser funktionieren als die herkömmliche Komprimierung, aber die Komprimierungsrate ist immer noch ziemlich schlecht im Vergleich zu MP4-Videos, bei denen die Größe auf 15 MB oder sogar weniger reduziert werden kann, wobei die Bildqualität erhalten bleibt.
Allerdings scheint keiner der von diesen Komprimierungsdienstprogrammen verwendeten Algorithmen die Ähnlichkeit der Bilder so auszunutzen, wie dies bei der Videokomprimierung der Fall ist. TatsächlichpackJPG, die jedes Bild einzeln komprimieren, wird der gesamte Satz auf 32,9 MB verkleinert, was recht nahe an fp8 und paq8pxd liegt, ohne jedoch die Ähnlichkeiten zwischen den Bildern im Geringsten auszunutzen (da jedes Bild einzeln komprimiert wird).
In einem anderen Experiment habe ich in Matlab die Differenz der beiden obigen Bilder berechnet und sie sieht folgendermaßen aus:
Durch Komprimieren beider Originalbilder (219,5 + 217,0 = 436,5 kB insgesamt) mit fp8 werden sie auf 350,0 kB (80 %) reduziert, aber durch Komprimieren eines der beiden und des Differenzbilds (als JPG in derselben Qualität und mit 122,5 kB) entsteht eine Datei mit 270,8 kB (62 %), also scheint fp8 (wie der Vergleich von mp4 und packJPG zeigt) die Ähnlichkeiten nicht besonders auszunutzen. Sogar komprimiert mit rar, schneidet ein Bild plus das Differenzbild bei den Originalbildern besser ab als fp8. In diesem Fall reduziert rar es auf 333,6 kB (76 %).
Ich denke, es muss eine gute Komprimierungslösung für dieses Problem geben, da ich mir viele Anwendungen vorstellen kann. Abgesehen von meinem speziellen Fall denke ich, dass viele professionelle Fotografen aufgrund von Serienaufnahmen oder Zeitrafferbildern usw. viele ähnliche Aufnahmen haben. Alles Fälle, die von einer solchen Komprimierung profitieren würden.
Außerdem verlange ich keine verlustfreie Komprimierung, zumindest nicht für die Bilddaten (Metadaten müssen erhalten bleiben).
Also... Gibt es ein Komprimierungsverfahren, das die Ähnlichkeiten zwischen den komprimierten Bildern ausnutzt?
Die beiden Bilder des obigen Tests können heruntergeladen werdenHierund die 96 Bilder des ersten TestsHier.
Antwort1
Ich kenne keine spezielle Software, die dies tut, aber es gibt einige Untersuchungen zu diesem Thema. Siehe zum Beispiel die ArtikelKomprimieren von Sätzen ähnlicher Bildervon Samy Ait-Aoudia, Abdelhalim Gabis, Amina Naimi undKomprimieren von Sätzen ähnlicher Bilder mithilfe eines hybriden Komprimierungsmodellsvon Jiann-Der Lee, Shu-Yen Wan, Chemg-Min Ma, Rui-Feng Wu.
Auf einer praktischeren Ebene könnten Sie Ihre Subtraktionstechnik erweitern, zum Beispiel indem Sie ein Skript schreiben, dasBildMagickum die Differenz zwischen aufeinanderfolgenden Bildern zu berechnen und das Ergebnis als JPEG zu speichern (oder als komprimiertes PNG, wenn Sie es verlustfrei haben möchten). Sie erhalten ein Basisbild und einen Satz komprimierter „Delta“-Bilder, die viel kleiner sein sollten. So berechnen Sie die Differenz mit ImageMagick:
convert image2.png image1.png -compose MinusSrc -composite -depth 24 -define png:compression-filter=2 -define png:compression-level=9 -define png:compression-strategy=1 difference-2-1.png
So berechnen Sie neu durch Zurückaddieren:
convert image1.png difference-2-1.png -compose Plus -composite image2-reconstructed.png
(Sie können dasselbe stattdessen mit JPG tun und viel Platz sparen).
Antwort2
In der Hoffnung, dass andere Leute, die ähnliche Bilder/PNGs komprimieren möchten und über die Suche hierher gefunden haben:
Ich bin mir nicht sicher, wie der Anwendungsfall, an dem ich gearbeitet habe, auf Ops-Fotos anwendbar wäre, da der Link nicht mehr funktioniert. Mein Anwendungsfall war ähnlich, aber nicht derselbe – ich wollte Screenshots von Computerprogrammen komprimieren, die sehr ähnlich sind und sich daher möglicherweise viel besser komprimieren lassen, als wenn ich die PNG-Dateien einfach komprimiere. Ich konnte beim Suchen keine Lösung finden, also habe ich mir eine eigene ausgedacht und bin bei einer wahnsinnigen Komprimierungsrate von 4,4 % gelandet (im Gegensatz zu 96 % bei naiver Verwendung der einfachen Komprimierung der PNGs):
Mein Datensatz bestand aus 300 PNG-Dateien mit 1920 x 1080 und einer Rohgröße von 431,8 MB, die sich mit den besten Einstellungen, die ich für bz2, 7z und ähnliche Tools finden konnte, auf nur 417,4 MB komprimieren ließ. Meines Wissens wurden die Quelldateien auf PNG-Ebene nicht optimal komprimiert, da verschiedene PNG-Minimierungstools die Rohgröße von etwa 1,4 MB auf 900 KB pro Datei reduzieren konnten.
Meiner Meinung nach bestand das Problem darin, dass die Komprimierungstools nicht erkennen konnten, dass die Daten bereits komprimiert waren, und dass kleine Änderungen an den Rohdaten zu völlig unterschiedlichen komprimierten Dateien führen konnten. Daher habe ich die Dateien ffmpegmit Einstellungen dekomprimiert, die meines Wissens nach zu keinem Datenverlust führen:
for FILE in screenshot-2024*; do ffmpeg -loglevel error -i $FILE -vframes 1 -compression_algo raw -pix_fmt rgb24 $FILE.tiff; done
Dadurch erhöhte sich die Größe der einzelnen Dateien von 1,4 auf 6 MB, die Komprimierung mit 7z/LZMA2 führte jedoch zu einer Datei mit einer wahnsinnig kleinen Größe von 19.175.127 Bytes, was einer Komprimierung auf nur 4,4 % der Originalgröße entspricht.
Die Rückkonvertierung der .tiffDateien ist wie folgt .pngmöglich:
for FILE in screenshot-2024*.tiff; do ffmpeg -loglevel error -i $FILE $FILE.png; done
Die doppelten Dateiendungen können natürlich korrigiert werden, allerdings werden auf diese Weise beim Testen Ihre Originalquellen nicht überschrieben.
Für die Komprimierung haben wir die folgenden Einstellungen verwendet. Die Solid block sizeEinstellung scheint den größten Einfluss auf die Ausgabegröße zu haben:
- Komprimierungsstufe: 9/Ultra
- Komprimierungsmethode: LZMA2
- Wörterbuchgröße: 512 MB
- Wortgröße: 256
- Solide Blockgröße: 512 MB
- Speicherverbrauch zum Komprimieren: 12 GB
Da unser Ziel die langfristige Lagerung war, spielten die zusätzlichen Reifen und die Komprimierungszeit keine große Rolle. Bei Ihnen kann die Laufleistung natürlich abweichen.