littleutils: JPG / JPEG via Kommandozeile ohne Verluste verkleinern (opt-jpg / opt-png)
Wieder so einen Open-Source-Schatz gefunden, der da auf sourceforge.net vor sich hindümpelt. Ursprünglich war ich auf der Suche nach einem Tool, mit dem man bequem Bilder verlustfrei oder annähernd bezüglich Dateigröße verkleinern kann. Bei mir leigen da etlich Bilder auf der Festplatte, die ich nur aus Gründen der Erinnerung nicht löschen möchte. Viele davon sind nicht mal besonders toll und noch aus der Steinzeit der digitalen Fotografie.
Mit littleutils / opt-jpg lassen sich Bilder optimieren und es spart tatsächlich etwas Platz. Die Tool-Sammlung gibt es wie schon erwähnt bei sourceforge.net. Das komprimierte tar-Archiv ist gerade 200 KByte groß und so installierst Du es:
- Archiv entpacken:
tar xjvf littleutils-1.0.29.tar.bz2
cd littleutils-1.0.29
./configure --prefix=/usr
make
make install
make install-extra
Bei meinem ersten Versuch hatte ich zwar opt-jpg, aber von opt-png oder opt-gif war keine Spur zu sehen. Bekanntlich hat der einen Vorteil, der lesen kann – also an der zeit, die README-Datei zu konsultieren. Da war dann auch prompt des Rätsels Lösung: littleutils hängt von ein paar anderen Programmen ab, beziehungsweise benutzt es diverse andere Tools. Für opt-png braucht man zum Beispiel pngcrush. littleutils benutzt folgende Pakete, von denen einige oft per Standard installiert sind:
- bash: http://www.gnu.org/software/bash/
- perl: http://www.perl.com/
- file: ftp://ftp.astron.com/pub/file/
- gifsicle: http://www.lcdf.org/gifsicle/
- jpegtran: http://www.ijg.org/
- libpng: http://www.libpng.org/pub/png/libpng.html
- pngcrush: http://pmt.sourceforge.net/pngcrush/
- bzip2: http://www.bzip.org/
- lzip: http://www.nongnu.org/lzip/lzip.html
- lzma_alone: http://www.7-zip.org/sdk.html (lzma_alone is buried in the SDK)
- xz,lzma: http://tukaani.org/xz/
- 7z,7za,7zr: http://sourceforge.net/projects/p7zip/
Sehr schön ist, dass jedes der Tools eine Man-Page mit sich bringt und auch gleich vernünftige Beispiele vorhanden sind. Somit muss man nicht lange rätseln, was man damit nun anstellen kann. Hier ein Auszug daraus:
- Ein paar Bilder optimieren:
opt-jpg image001.jpg image002.jpg
- Alle Bilder innerhalbe ienes Verzeichnisbaums optimieren:
find . -name "*.jpg" -exec opt-jpg {} \;
- Alternativ:
find . -name "*.jpg" -print0 | xargs -0 opt-jpg
- Ein Quad-Core-System zum Optimieren der JPEG-Dateien voll ausreizen:
find . -name "*.jpg" -print0 | xargs -0 -n 1 -P 4 opt-jpg
oderfind . -name "*.jpg" | parallel -j+0 opt-jpg
Etwas Praxis
Ich habe zunächst ein Bild aus meiner Bibliothek genommen, es in einen separaten Ordner kopiert (man experimentiert nicht mit dem Original) und opt-jpg so darüber laufen lassen. Da gab es dann gleich mal 400 KByte Ersparnis – gar nicht schlecht.
Allerdings schrubbt mir der Befehl auch die EXIF-Dateien und die hätte ich schon ganz gerne. Also die ganze Übung noch einmal und diesmal weisen wir den Befehl an, die Informationen zu kopieren. Das funktioniert mittels Schalter -m all.
Am Ergebnis sieht man, dass das Bild mit dieser Methode nur minimal größer ist. Das nehme ich gerne in Kauf, denn EXIF-Dateien in einem Bild sind schon sehr bequem. Vergleich man die beiden Bilder, kann man mit dem bloßen Auge keinen Unterschied erkennen. Zur Information: die beiden Bilder wurden mit GIMP auf 1280×853 heruntergerechnet – 18 Megapixel hier rein zu schieben, schien mir ein bisschen übertrieben. Aber man kann auch bei den großen Bildern keinen Unterschied erkennen.
Update: Ich weiß nicht, wo etwas schief gegangen sein soll, aber manche sehen das eine Bild wohl deutlich kräftiger als das andere. Deswegen habe ich hier die Originale als ZIP-Datei zur Verfügung gestellt (12 MByte). Ich sehe bei den Originalen weder einen Unterschied in Firefox, Chrome, GIMP oder sonst wo … auf einem EIZO FlexScan S2231W.
Nehme ich nun den ganzen Ordner dieser Bilderserie und lasse opt-jpg laufen, gibt das eine ganz ordentliche Ersparnis. Bei 117 Bilder 62 MByte Ersparnis ist ganz gut. Bei einigen Tausen Fotos können schon ein paar GByte zusammenkommen.
Als Befehl habe ich find . -name "*.jpg" -print0 | xargs -0 -n 1 -P 4 opt-jpg -m all
verwendet. Also alle EXIF-Daten sind erhalten geblieben und mein Quad-Core wurde auch optmial genutzt.
Weiterhin in littleutils enthalten
Die kleinen Utilities können allerdings noch viel mehr und auch das steht in der README. Da finden sich wirklich viele kleine Helferlein, die man gut in Scripte einbauen kann. Vor einer Anwendung sollte man sich die Man-Pages der einzelnen Tools genau ansehen (man <tool>). Die Aufgaben lassen sich natürlich mit kruden Bash-Befehlen auch realisieren, aber mit littleutils ist es wesentlich angenehmer. Nich jeder ist ein Kommandozeilen-Ninja … 🙂 … Hier die Übersicht:
Basic littleutils
- filedate – Die die Zeit der Modifikation von Dateien aus
- filehash – MD5 und SHA, sowie Dateigrößen
- filemode – Zugriffsberechtigungen
- filenode – Inode-Nummer
- fileown – uid / gid / Username / Gruppenname
- filesize – Dateigröße
- lrealpath – kompletter Pfad
- randomize – Zufällige Zeilen einer oder mehr Datein aus stdin
- tempname – Einzigartige temporäre Datei
Bilder
- imagsize – alle möglichen Größen der angegebenen Datei (Größe, Abmessungen, Type …)
- jpgcom – Ausgabe der Kommentare, die in einer JPEG-Datei hinterlegt sind
- pngrecolor – PNG-Datei mit minimaler Palette neu schreiben
- pngstrip – PNG-Datei neu schreiben und alle Extra-Informationen entfernt
“Aufräum”-Utilities
- notabs – Alle Tab in Leerzeichen verwandeln – bei einer Text-Datei
- notrail – Alle Leerzeichen am Ende einer Text-Datei entfernen
- lreplace – Strings in einer Textdatei tauschen
Optimierungs- und Kompressions-Tools
- opt-gif – GIF-Dateien verlustfrei optimieren
- opt-jpg – JPEG-Dateien verlustfrei optimieren
- opt-png – PNG-Dateien verlustfrei optimieren
- recomp-jpg – JPEG-Dateien in niedrigere Qualität umwandeln
- to-gzip – wandelt Dateien der Typen .Z (compress) und .lzo (lzop) nach .gz (gzip)
- to-bzip – wandelt Dateien der Typen .Z, .lzo, und .gz nach .bz2 (bzip2)
- to-7zip – wandelt Dateien der Typen .Z, .gz, .lzo und .bz2 nach .7z (p7zip) [extra only]
- to-lzip – wandelt Dateien der Typen .Z, .gz, .lzo und .bz2 nach .lz (lzip)
- to-lzma – wandelt Dateien der Typen .Z, .gz, .lzo und .bz2 nach .lzma (lzma/lzma_alone)
- to-xz – wandelt Dateien der Typen .Z, .gz, .lzo und .bz2 nach .xz (xz)
Wartungs-Tools
- lowercase – Alle Dateien in Kleinbuchstaben verwandeln
- uppercase – Alle Dateien in Großbuchstaben verwandeln
- frenum – Umbenennen oder Numerieren von Dateien
- pren – Dateien mithilfe von Perl-Regulären-Ausdrücken umbenennen
- repeats – Duplikate suchen
- wipe-free – Sämtlichen freien Speicher einer Partition mit Nullen überschreiben
Also beim oberen Taucherbild sind die Farben schon sichtbar kräftiger...verlustfrei ist das nicht gerade. 😉
Als ich den tar-Befehl in deiner Anleitung gesehen habe, ist mir doch gleich ein anderes, leider viel zu unbekanntes Schätzchen eingefallen:
http://brettcsmith.org/2007/dtrx/ 😉
Da täuscht Dich Dein Monitor oder beim Hochladen ist etwas schief gegangen - bei mir am Bildschirm sehen die beiden Bilder genau gleich aus. Lade die beiden Bilder mal runter und vergleiche sie direkt. Der Verlauf von hellblau nach dunkelblau könnte eine optische Täuschung beim darunterliegenden Bild hervorrufen.
Ich bestätige Georg, das Original ist _deutlich_ kräftiger.
Im Browser (Fx v22.0, Chromium v28.0). In gThumb ist dieser Unterschied nicht feststellbar. Es müssen also Informationen verbogen/entfernt werden, die Browser brauchen/auslesen.
Ich versuche seit jeher auch, Ressourcen zu sparen, also beispielsweise .zip in .7z umzupacken, wo es sich anbietet. Aber von solchen "annähernd verlustfrei"-Umpack-Versprechungen bei Bildern halte ich nichts.
Mal eben 2 Browserfenster direkt nebeneinander gelegt und die beiden Fotos auf gleicher Höhe verglichen. Ich relativiere. 😉 Der Unterschied ist weniger, jedoch m.E. noch leicht sichtbar (und das liegt nicht daran, auf welcher Seite des Monitorsbildes welches Foto liegt, wie das Umgebungslicht ist, in welchem Winkel ich draufsehe 😉 ).
Vergleiche mal mit GIMP. Öffne ein Bild und leg das andere als Ebene drüber. Dann kannst Du die eine Ebene einfach Ein- und Ausblenden. Da fällt am schnellste auf, wenn etwas "hüpft" ...
So, ich habe nun die Originale mal hochgeladen (12 MByte, ZIP-Datei). Ich sehe auf einem EIZO FlexScan S2231W keinen Unterschied. Weder in Firefox, Chrome, Opera, GIMP oder sonst wo.
Entweder ist da beim Hochladen was schief gelaufen oder was weiß ich. Ich würde solche Methoden, wie im Artikel erwähnt, auch nur bei Bildern anwenden, die zur reinen Erinnerung sind - oder eben bei den JPGs, weil ich in der Regel von meinen besten Bildern die RAW-Dateien aufhebe.
Ich habe mir deine Originale mal gezogen, es sieht nun tatsächlich identisch aus. Komisch....nutzt du vielleicht eines dieser WordPress-Plugins zur Bilderkompression? Ansonsten hast du vielleicht wirklich recht, dass das Auge einen Streich spielt, wenn man den Farbverlauf in den Bildern übereinander anschaut.
Plugin, das Bilder komprimiert wäre mir jetzt nicht bewusst. Ich nehme halt das ganz normale Medien-Dingensda. Ich will nun aber auch nicht ausschließen, dass ich beim Verändern der Größe bei GIMP aus Versehen irgendwo draufgekommen bin und es deswegen einen Unterschied gibt.