[Gelöst] Speicherplatz von JPG-Bildern reduzieren.

[wanne]

Ich würde auf keinen Fall die Kamera stark komprimieren lassen. Die billigen haben grauenhafte Encoder.
Da ist 2 mal encoden weit weniger schlimm.
Wenn du so viel wert auf kleine Dateigrößen legst kannst du dir mal jpeg 2000 (.jp2) oder webp (.webp) angucken. Beide sollen besser komprimieren als jpeg sind aber beide nicht sonderlich verbreitet. jpeg 2000 war wegen Patenten eine Totgeburt und webp ist noch zu neu um in den typischen Debian Programmen drin zu sein. Kommt aber zumindest in den OpenSource Programmen (KDE,Firefox,Chrome) gerade überall.

Sonnst ist aus chroma subsampling einiges herauszuholen. 4:2:2 oder 4:2:0 braucht weit weniger Speicher als 4:4:4

mit dem ffmeg:

Code: Alles auswählen

ffmepg -i ein.jpeg -pix_fmt yuvj420p -q [QUALITÄT] out.[ENDUNG]

Aber ich glaube die libjpeg ist da eher besser als der ffmpeg mit Motion JPEG.
Programme mit der werden aber ähnliche einstellungen haben.

[hikaru]

Ich würde auf keinen Fall die Kamera stark komprimieren lassen. Die billigen haben grauenhafte Encoder.
Da ist 2 mal encoden weit weniger schlimm.

Der "grauenhafte Encoder" kommt aber so oder so zum Einsatz. Also kann man ihn auch die ganze Arbeit machen lassen und dabei nur ein grauenhaft codiertes Ergebnis erzeugen, anstatt ein grauenhaftes Ergebnis mit all seinen (unnötigen) Artefakten durch noch einen zweiten Encoder zu jagen der, auch wenn er besser ist, zusätzliche Artefakte erzeugt.
Könnte die Kamera RAW ausgeben, dann wäre es eine andere Geschichte, aber das kann sie nicht.

Abgesehen davon sieht das Ergebnis in Anbetracht des 1/2,3"-Sensors gar nicht so grauenhaft aus. [1] Verglichen mit einer Canon Powershot S110 mit 1/1,7"-Sensor, ist zumindest bei Tageslicht nur wenig mehr Rauschen zu sehen.


[1] http://www.dkamera.de/testbericht/nikon ... itaet.html

[wanne]

Der "grauenhafte Encoder" kommt aber so oder so zum Einsatz. Also kann man ihn auch die ganze Arbeit machen lassen und dabei nur ein grauenhaft codiertes Ergebnis erzeugen, anstatt ein grauenhaftes Ergebnis mit all seinen (unnötigen) Artefakten durch noch einen zweiten Encoder zu jagen der, auch wenn er besser ist, zusätzliche Artefakte erzeugt.

Nope. Auch der dümmste encoder produziert keine Artefakte, wenn du ihn nach lossless ziehst. Und wenn du ihn nach fast lossless ziehst ist das so ähnlich. Dann hast du fast keine sichtbaren Artefakte. Genauso, wie du nen besseren nimmst und gut komprimierst. Und 2 mal fast keine Artefakte ist halt oft um Größenordnungen weniger, wie ein Klotz im Bild, den dir der erste Encoder erzeugt.
Das aus krampfhaft nicht 2 mal encoden ist absolut bullshit, wenn du mit verschiedenen Encodern (oder unterschiedlichen Einstellungen) arbeitest.
Ich hatte z.B. mal ne Samsung kompakte als gerade Digitalkameras auf kamen. Die hat wenn man die Qualität ganz runter gestellt hat konstant 2MiB große jpegs erzeugt, die einfach nicht anzugucken waren. Hat man die Qualität dagegen auf gut gestellt war man bei ca. 5MiB und hatte keine sichtbaren Artefakte. Und selbstverständlich hat man die dann (je nach Motiv) auf 0.4 bis 2MiB runter komprimieren können ohne dass man da Artefakte gesehen hat.
Genauso sieht es aus für Bildschirmaufnahmen: Du machst zuerst mpeg2 bei horrenden Bitraten, damit du keine Artefakte reinbekommst und dann kompremierst du mit x265/VP9. Würdest du das preset sofort so runter ziehen, dass du live VP9 encodieren kannst, hättest du auf den meisten CPUs halt nur Matsch.

[wanne]

So hier mal ein schönes Beispiel:
Ich habe ein Bild mit webp encodiert. Target size war 81kiB.
Dazu habe ich 2 verschiedene encodieroptionen genutzt. einmal -compression_level 6 (CPU-Intensiv) und einmal -compression_level 1 (möglichst schnell => energiesparend also das was die Kamera macht.)
Hier was passiert wenn man den 6er auf 81kiB (klar die beste Qualität):
https://balja.org/pub/out2.webp
Und hier was passiert wenn man den 1 auf 81kiB runter komprimieren lässt (Man achte auf die Farben. Das Rauschen, dass man sieht dürfte eher mein mein Handy sein):
https://balja.org/pub/out1.webp
Und jetzt wenn man den 1er auf 200kiB komprimieren lässt und dann den 6er auf 81kiB:
https://balja.org/pub/out2.2.webp
Das Ergebnis ist vom ein mal encodieren fast nicht zu unterscheiden sehr wohl aber von dem wenn man den schlechten Encoder das direkt machen lässt.

Edit: öffnet die Bilder im Chromium/Chrome. Der hat den vernünftigen webp support.

[wanne]

Hier nochmal mit jpeg. Gleiches Bild Target size 423K (kleiner schafft der ffmpeg nicht)
Encoder ein mal ffmpeg (Motion JPEG) und convert (k.p. was der nutzt)
Zuerst direkt mit convert (ein schritt scheiß encoder):
https://balja.org/pub/out1.jpeg
dann mit convert auf 2MiB und dann mit ffmpeg auf 423K (zuerst scheiß encoder auf gute Qualität dann guter encoder zum runterkomprimieren):
https://balja.org/pub/out2.2.jpeg

PS: Zwschenergbnisse heißen je 2.1.

Ich denke damit ist endgültig widerlegt, dass es sinnvoll ist, mit einem schlechten encoder stark zu komprimieren um sich einen konvertierungsschritt zu sparen.

[hikaru]

Auch der dümmste encoder produziert keine Artefakte, wenn du ihn nach lossless ziehst. Und wenn du ihn nach fast lossless ziehst ist das so ähnlich.

Das ist Unsinn.
Natürlich produziert eine verlustfreie Codierung keine Artefakte. Aber wir reden hier von Jpeg (was anderes kommt nicht aus ottonormals Kamera), was immer verlustbehaftet ist. Also hat man auch immer Artefakte.
Ein prinzipbedingt verlustbehafteter Argorithmus lässt sich nicht nach verlustfrei "ziehen".

Deine Tests sind außerdem praxisfern. Keine halbwegs aktuelle Kamera codiert so schlecht wie du es hier darstellst. Du hast in allen drei Bildern deutliche Artefakte im Gras. Wenn man sich die Beispielbilder für die Nikon auf dkamera.de anschaut, dann ist da Nichts zu sehen, das auch nur vergleichbar wäre.

[MSfree]

Ich würde auf keinen Fall die Kamera stark komprimieren lassen. Die billigen haben grauenhafte Encoder.

Was aber nicht am "grauenhaften" Encoder sondern an der Vorverarbeitung wie Glättung und Schärfung liegt, bevor der Kompressor angeschmissen wird.

[Lord_Carlos]

Warum die Qualitaet direkt auf der Kamera verschlechtern, wenn man vorher nicht weis ob das Bild wichtig ist oder nicht?

OP hat doch eine Loesung fuer sich gefunden

[wanne]

Aber wir reden hier von Jpeg (was anderes kommt nicht aus ottonormals Kamera), was immer verlustbehaftet ist.

Nein. Die wenigsten Schritte sind prinzipbedingt losssy. Das ist z.B. Unterabtastung von nach 4:4:4 nach 4:2:0 aber die ist in jpeg optional und vor allem kannst du die so oft du willst über ein Bild laufen lassen. Eine Umwandlung von 4:2:0 nach 4:2:0 ist nicht lossy. Behältst du das ursprüngliche Farbsubsampling bei hast du keine Verluste, weil keine Umwandlung.
Das gleiche Spiel gilt für den Farbraum. jpeg beherrscht schon alle üblichen Farbräume. Umwandlungen sind nicht nötig. Nur hilfreich. Wobei man sich da in beireichen bewegt, die sowieso abwegig sind. Den Bildschirm macht eh nochmal eine Farbraumtransformation.
Der eigentliche Teil wo Verlust stattfindet ist die Quantisierung da teilst du und rundest dann. Teilst du aber nur durch vielfache von 2 musst du nicht mehr runden. 3/4=0.75. Das ist exakt. Wenn du durch 4 teilst brauchst du nie mehr als 2 Nachkommastellen. Rundest du auf 2 Nachkommstellen bist du lossless. Und so kannst du überall durchlaufen und jeden Schritt lossless machen oder ist es eh schon (Huffman) das wird im Standard sogar extra erwähnt. Daneben gibt es im aktuellen jpeg-Standard noch JPEG-LS das wohl sogar extra auf lossless optimiert ist. (Aber ebenfalls lossy verwendet werden kann.)

Ein prinzipbedingt verlustbehafteter Argorithmus lässt sich nicht nach verlustfrei "ziehen".

Wie gesagt: Die wenigsten Algorithmen sind wirklich prinzipbedingt lossy. jpeg gehört nicht dazu. Genauso gibt es lossless Varianten von h.264, h.255 und VP9.

[scientific]

Die einzige Veränderung der Originale mache ich lediglich im Dateinamen.
Leider sind die Namen von der Kameraapp, bei Dropbox, von Whatsapp-bildern, von Bildern aus Signal usw. alle etwas anders benannt.
Anhand der in den Metadaten gespeicherten Zeitstempel vergebe ich Dateinamen in einheitlicher Nomenklatur - Skriptgesteuert.
Aber ich sehe echt keinen Grund, die originalen Bildinformationen zu verändern.
Die meisten Bilder hab ich auch auf 4 Geräten gespeichert.

Als Rückfallebene hab ich noch die komprimierte und unbegrenzte Google-Bariante, falls mit unserer Wohnung etwas passieren sollte.

[ottonormal]

Warum die Qualitaet direkt auf der Kamera verschlechtern, wenn man vorher nicht weis ob das Bild wichtig ist oder nicht?

OP hat doch eine Loesung fuer sich gefunden

So isses! Das wird mir jetzt langsam auch etwas zu kompliziert, diese ganzen Einstellungen von denen hier die Rede ist habe ich doch auch gar nicht und wo nichts ist, da kann man auch nichts einstellen.
Ob der Encoder meiner Kamera "grauenhaft" ist, kann ich auch nicht beurteilen. Profis oder Kenner werden sicher über die Kamera die Nase rümpfen, für mich ist sie, nach allem was ich vorher hatte, der absolute Luxus. Für meine Begriffe macht die sehr gute Bilder (und Videos) und ist für meine laienhaften Ansprüche mehr als ausreichend.

Wenn ich, wie oben beschrieben, ein Bild in JPG mit Qualität 75 herunterkonvertiere, bekomme das was ich haben wollte: Die Größe ca. nur noch die Hälfte und die Qualität immer noch sehr gut (jedenfalls für meine Begriffe). Wenn ich dieses Bild mit dem Original vergleiche, sehe ich keinen Unterschied. Wenn ich beide Bilder, das Original und das Konvertierte, gleichzeitig nebeneinander öffne, dann einen bestimmten Punkt beliebig zoome, kann ich auch keinen Unterschied erkennen. Da müsste man vielleicht etwas länger suchen um einen Punkt zu finden wo man Unterschiede findet.

[wanne]

Keine halbwegs aktuelle Kamera codiert so schlecht wie du es hier darstellst. Du hast in allen drei Bildern deutliche Artefakte im Gras. Wenn man sich die Beispielbilder für die Nikon auf dkamera.de anschaut, dann ist da Nichts zu sehen, das auch nur vergleichbar wäre.

Der Encoder ist ziemlich herausragend. Aber ich habe 4608x3456 auf 81KiB=0.081MiB komprimiert!

Offensichtliche Artefakte waren ja durchaus gewünscht. Hätte ich Irgend wo bei 2MiB rumgespielt wären die Artefakte der Kompression unter der schlechten Qualität eines Handyphotos nicht mehr aufgefallen.
Mit ausreichend guten Ausgangsmaterial und jeder anderen Variante kannst du das nachspielen. Nur musst du dann halt ordentlich Zoomen, damit du die Artefakte findest. Nur sind die dann nicht gar so offensichtlich unterschiedlich, dass du mit genug Wille das schön weiter abstreiten kannst.
So ist es offensichtlich. Deine Aussage ist widerlegt.
Zum testen ob sich Massen anziehen nimmst du auch keine Stecknadelköpfe und um zu testen ob Uhren langsamer laufen, wenn man sich schneller bewegt man sich nicht 10m/s. Man führt das ganze ins extrem damit der Unterschied offensichtlich wird und auch schlechte Messinstrumente das unzweifelhaft gemessen bekommen.
Newton hat sich Ewigkeiten Gedanken gemacht, wie man Fallexperimente so in der Zeit strecken kann, dass die bescheidene menschliche Wahrnehmung das wahrgenommen bekommt. Die Gesetzmäßigkeiten dahinter sind natürlich trotzdem weiter richtig.

[hikaru]

Der eigentliche Teil wo Verlust stattfindet ist die Quantisierung da teilst du und rundest dann. Teilst du aber nur durch vielfache von 2 musst du nicht mehr runden. 3/4=0.75. Das ist exakt. Wenn du durch 4 teilst brauchst du nie mehr als 2 Nachkommastellen. Rundest du auf 2 Nachkommstellen bist du lossless. Und so kannst du überall durchlaufen und jeden Schritt lossless machen oder ist es eh schon (Huffman) das wird im Standard sogar extra erwähnt. Daneben gibt es im aktuellen jpeg-Standard noch JPEG-LS das wohl sogar extra auf lossless optimiert ist. (Aber ebenfalls lossy verwendet werden kann.)

Du argumentierst hier im luftleeren Raum. Die Quantisierung innerhalb der Kamera hast du nicht unter Kontrolle. Daher kannst du auch kein festes Ziel definieren, wenn du den Anspruch hast, dass eine erneute Quantisierung verlustfrei sein soll.

Der Encoder ist ziemlich herausragend. Aber ich habe 4608x3456 auf 81KiB=0.081MiB komprimiert!

Ich sagte doch bereits, dass dein Beispiel praxisfern ist. Keiner komprimiert 16MPx ernsthaft auf 81kB.

[wanne]

Ich sagte doch bereits, dass dein Beispiel praxisfern ist. Keiner komprimiert 16MPx ernsthaft auf 81kB.

Ändert absolut nichts an der Aussagekräftigkeit.

Du argumentierst hier im luftleeren Raum. Die Quantisierung innerhalb der Kamera hast du nicht unter Kontrolle.

Für die Quantisierung ist das eh nicht sinnvoll. Aber bei höherer Qualität, wird die Kamera nach mehr stellen abbrechen. Wenn ich zuerst auf 8 und dann auf 5 stellen runde ist das nicht immer exakt wie wenn ich sofort auf 5 runde aber in exakt 99% der Fälle halt schon.
Für alles anderen lossy Schritte kannst du dich an das anpassen, was die Kamera macht. Das machen die meisten Encoder auch. Diese Schritte sind dann ab dem 2. mal lossless, weil der Encoder einfach beibehält, was der erste gemacht hat.
Du kannst btw. auch die Quantisierung einfach übernehmen und nur am Huffman (der lossless ist) rumspielen. Dann kompremierst du vollständig lossless von jpeg nach jpeg. jpegtrans kann das z.B.. Raus holen tust du dabei aber dann extrem wenig. Die magic die einen guten encoder aus macht ist schon die Quantisierungstabelle.

[uname]

Ich würde "convert" (Option -quality) aus imagemagick verwenden siehe z.B. folgenden Thread:

viewtopic.php?t=144513

Sei "neu" der Ordner mit den neu abzuspeichernden Bildern in Qualität 70%

Code: Alles auswählen

for i in $(ls *.JPG);do convert $i -quality 70 neu/$i;done

Unter Umständen ist es sinnvoller mit "-resize" die Auflösung absolut oder prozentual herunterzusetzen.

[2undvierzig]

Ich würde "convert" (Option -quality) aus imagemagick

Nu verrat doch nicht die Insidertricks.

[wanne]

Nu verrat doch nicht die Insidertricks.

Wie gesagt: Entgegen meiner Erwartung war die Qualität von ffmpeg bei gleicher größer deutlich besser als die von imagemagick. Das kann jetzt aber wirklich dran liegen, dass ich mich irgend wo bei extrem kleinen Dateigrößen bewegt habe.

[uname]

Ok war kein Insider-Tipp. XnConvert mag ähnlich zu convert sein und auch convert wurde irgendwo schon genannt. Und ob convert besser ist als ffmpeg weiß ich auch nicht. Die ganzen Probleme hätte man gar nicht, wenn man endlich mit dem Pixelwahnsinn aufhören würde. So oft druckt man auch keine Poster oder Wandtapeten. Bei den Farben hat man doch auch schon vor Jahrzehnten bei 16 Millionen Farben aufgehört, da der Mensch nicht mehr als ein paar Millionen Farben unterscheiden kann. Mein Smartphone hat eine hohe Pixelauflösung mit schlechter Bildqualität. Umgekehrt wäre besser.

[MSfree]

Die ganzen Probleme hätte man gar nicht, wenn man endlich mit dem Pixelwahnsinn aufhören würde.

Beim OP ging es um Bilder mit 4608x2596 Pixel, also 12 Megapixel. Das ist zwar mehr als die typische Optik der Kameras mit 1/2.33"-Sensor auflösen kann, aber meinem Empfinden nach bewegt sich das eher am unteren Ende des Auflösungswahns. Es gibt Kameras, die über 20 Megapixel auf so einen 1/2.33"-Sensor quetschen.

So oft druckt man auch keine Poster oder Wandtapeten.

Es ist erstaunlich, wie wenig Pixel man eigentlch wirklich braucht, um schöne Poster zu drucken. Auf 100*75cm² reichen z.B. 5 Megapixel.

Bei den Farben hat man doch auch schon vor Jahrzehnten bei 16 Millionen Farben aufgehört, da der Mensch nicht mehr als ein paar Millionen Farben unterscheiden kann.

8 Bit pro Farbkanal sind leider nicht genug. In einigen Fällen sieht man z.B. statt eines glatten Farbverlaufs Abstufungen. Die Sensoren der Digitalkameras kann man, wenn man mal vom untersten Ramschsegment absieht, immer mindestens mit 10 Bit pro Kanal auslesen (sogar der Raspberry Kamerasensor liefert 10 Bit), typischerweise bekommt man sogar 12-14 Bit.

Warum die Hersteller die Fähigkeit von JPEG nicht ausnutzen, 12 Bit pro Farbkanal speichern zu können, ist mir allerdings ein Rätsel.

[TomL]

Ich würde "convert" (Option -quality) aus imagemagick verwenden

Genau so mach ich das auch. Und vor dem Hintergrund, dass irgendwer in 20-30 Jahren alle Fotos, die nur mir und der Chefin als Erinnerung dienen, sowieso löschen wird, resize ich die auch alle gnadenlos auf Bildschirmgrösse. Für uns zum ansehen und erinnern "ach, guckma, weisse noch?" reicht uns die Größe 500 kb bis 1 mb immer aus. Sind eh alles nur Smartphone-Fotos.

[ottonormal]

Ich würde "convert" (Option -quality) aus imagemagick verwenden...

Danke für den Tipp, das funktioniert gut und erspart auch noch das nachträgliche Umbenennen der konvertierten Bilder.

Für uns zum ansehen und erinnern "ach, guckma, weisse noch?"

Genau so sehe ich das auch; denn dafür reicht es doch allemal.

Ich wusste noch gar nicht, dass mit ffmpeg auch Bilder verarbeitet werden können. Dachte immer, das ist nur für Audio/Video. Würde ich auch gerne ausprobieren. Wie müsste der Befehl lauten wenn ich z.B. alle Bilder in einem Ordner in einen "neu"-Ordner konvertieren will mit Qualitätsstufe 75?

Wirklich überrascht bin ich nicht, aber ich finde es schon erstaunlich in einem Debianforum so viel Kompetenz in Sachen Fotobearbeitung zu finden. Das Thema hat ja eigentlich nur entfernt, wenn überhaupt, eine Beziehung zu Linux/Debian.

[scientific]

Graphicsmagick ist ein Fork von Imagemagick und soll noch besser funktionieren, daher kommt es oft auf Webservern zum Einsatz.
Lässt sich aus den Debianwuellen installieren.

Lg scientific

[rodney]

Ich würde "convert" (Option -quality) aus imagemagick verwenden[...]

Sei "neu" der Ordner mit den neu abzuspeichernden Bildern in Qualität 70%

Code: Alles auswählen

for i in $(ls *.JPG);do convert $i -quality 70 neu/$i;done

Sollte auf Metadaten kein Wert gelegt werden kann eine weitere Dateigroessenreduzierung durch die Option -strip erreicht werden. Auch -interlace holt noch ein paar Bytes raus. Abgeaenderter Befehl von @uname:

Code: Alles auswählen

for i in $(ls *.JPG);do convert $i -strip -interlace Plane -quality 70 neu/$i;done

P.S. Bilddateiverkleinerung ohne "Ruecksicht auf Verluste" ist eigentlich nicht so mein Ding (habe halt gern die Originale auf Halde), bin aber trotzdem erstaunt was da rauszuholen ist. Und die Ergebnisse mit 70% haben mich positiv ueberrascht.

[Lord_Carlos]

Oh Gott, wenn OP anfaegt die meta Daten wegen Speicherplatz zu loeschen werde ich wütend.

[rodney]

Oh Gott, wenn OP anfaegt die meta Daten wegen Speicherplatz zu loeschen werde ich wütend.

Warum wuetend? Es ging doch um den Speicherplatz von JPG-Bildern und nicht um irgendwelche Komfortmerkmale wie Qualitaet oder auch Meta-Daten. Anfaenglich wurde ja sogar die Bildgroesse reduziert.