ubuntuusers.de

Kann man JPEG Bilder ohne Qualitätsverlust beschneiden?

Auf die Idee, das es theoretisch möglich sein könnte, bin ich durch das Programm jpegtran gekommen. Das kann, unter bestimmten Umständen Bilder verlustfrei drehen. Werden diese Bedingungen nicht eingehalten, treten am Bildrand Artefakte auf. Um diese zu vermeiden, gibt es aber die Option die überzähligen Pixels abzuschneiden. Das ist jetzt die Funktionalität, die ich suche.

Aber leider gibt es dabei einen Haken. Mein Zielformat ist 340x400 px. Die 400 ist ja ganzzahlig durch 8 teilbar, die Breite jedoch nicht. Mir geht es aber nur darum bei einigen Bildern die Höhe zu rezuzieren, die um wenige Pixel zu groß ist. Die Breite soll eigentlich nicht verändert werden.

Gibt es ein Tool mit dem so etwas geht?

Dakuan schrieb:

Kann man JPEG Bilder ohne Qualitätsverlust beschneiden?

Nein, wenn sie beschnitten sind fehlt ja was *scnr 😈

Gibt es ein Tool mit dem so etwas geht?

convert aus dem ImageMagick-Paket soll das angeblich können, wenn man 100 angibt: http://www.imagemagick.org/script/command-line-options.php#quality

Nein, wenn sie beschnitten sind fehlt ja was *scnr 😈

Deswegen hatte ich bewusst den einfachen Begriff verlustfrei vermieden.

... quality is 1 (lowest image quality and highest compression) to 100 (best quality but least effective compression).

Da ist immer noch von Kompression die Rede. Der Trick bei jpegtran basiert aber auf der Umsortierung bereits komprimierter Blöcke, wodurch eine erneute Komprimierung vermieden wird.

Aber ich schaue mir das morgen noch einmal genauer an, wenn mein Denkapparat ausgeruht ist.

Edit:

Oh man ist das peinlich! Ich habe jetzt noch einmal die man page von jpetgtran genauer durchsucht. Und es scheint, dass dieses Programm das nebenbei auch kann.

       -crop WxH+X+Y
              Crop the image to a rectangular region of width W and height  H,
              starting  at point X,Y.  The lossless crop feature discards data
              outside of a given image region but losslessly preserves what is
              inside.   Like  the rotate and flip transforms, lossless crop is
              restricted by the current JPEG format; the upper left corner  of
              the  selected  region  must  fall  on  an  iMCU boundary.  If it
              doesn't, then it is silently moved up and/or left to the nearest
              iMCU boundary (the lower right corner is unchanged.)

Muss ich morgen mal ausprobieren. Die Bilder befinden sich auf einem anderen PC.

Bericht folgt morgen.

Ich konnte es nicht abwarten und habe den anderen PC für diesen Test eben gestartet. Im TV war ja nichts, was mich wirklich ablenken könnte (kein guter Krimi und kein Snooker Turnier).

Es funktioniert perfekt. Sogar die Kommentare werden mitgenommen! Das hatte ich nicht erwartet. Ich muss da nur die MTime manipulieren.

Man muss nur darauf achten, dass die x+y Startwerte durch 8 teilbar sind (bei 8 Bit Farbtiefe denke ich).

Gut, wenn dein Tool das kann 😉

Und komprimiert ist jpeg doch immer? Das ist doch der Sinn bei diesem Format… oder bin ich da falsch informiert?

ChickenLipsRfun2eat schrieb:

Und komprimiert ist jpeg doch immer? Das ist doch der Sinn bei diesem Format… oder bin ich da falsch informiert?

Ja, aber gleich komprimiert wie vorher. Das Problem besteht ansonsten darin, dass die Bilder

1. dekomprimiert

2. bearbeitet

3. komprimiert

werden. Dadurch wird die Qualitaet zwangslaeufig immer schlechter. Das ist hier nicht der Fall, es gibt keine weiteren Verluste.

sebix schrieb:

Ja, aber gleich komprimiert…

Danke für die Aufklärung! Wie das technisch funktioniert, weiß ich natürlich nicht, aber ohne „umpacken“ geht bei convert nur ohne Optionsangaben — und wenn es automatisch zuzuordnen ist. Ob das ein Ent- und erneutes Komprimieren auslässt — keinen Schimmer. Aber interessant, dass ein Schneiden ohne Entpacken möglich ist.

Aber interessant, dass ein Schneiden ohne Entpacken möglich ist.

Eine Erklärung dazu habe ich hier gefunden. Ich kann allerdings nicht behaupten, dass ich die wirklich verstanden habe.

Da steht auch:

Einige dieser Operationen verlangen daher einmalig, dass diese Randstreifen verworfen werden.

Das Verwerfen passiert bei jpegtran nicht automatisch. Da gibt es dann rechts und/oder unten Artefakte. Die gehen aber wieder weg, wenn man das Bild zurück dreht. Man kann dann die Operation mit der Option -trim wiederholen.

Ich habe gestern beim Beschneiden übrigens auch gesehen, dass die gewünschten Offsetwerte nicht immer genau übernommen werden. Man sollte das Ergebnis also immer kontrollieren.

Dakuan schrieb:

Eine Erklärung dazu habe ich hier gefunden. Ich kann allerdings nicht behaupten, dass ich die wirklich verstanden habe.

Ich auch nicht. Aber so ungefähr reicht ja. Falls man ein durch 8 Pixel teilbares Seitenverhältnis hat, ist verlustfreies bearbeiten möglich, ansonsten nicht. So wie ich das verstanden habe, werden da Blöcke von komprimierten Daten bewegt, anstatt dekomprimierte Bitmaps, weswegen das auch auf die angegebenen Aktionen beschränkt ist und auch nur, wenn es eine passende Matrix gibt. Was bei nicht durch 8 teilbaren Bildgrößen passiert, sieht man ja ganz gut am Rotationsbeispiel und kann sich das dann vorstellen. Die Randgebiete werden wohl automatisch hinzugefügt (vermutlich ein array aufgefüllt) und sind bei Rotation und Spiegelung problematisch, weil diese nur rechts und/oder unten sein dürfen.

Die Randgebiete werden wohl automatisch hinzugefügt (vermutlich ein array aufgefüllt) ...

Da wird nichts hinzugefügt oder aufgefüllt. Dann müsste man ja wieder dekodieren.

Ich stelle mir das so vor. Ein Bild mit unvollständigen Blöcken auf der rechten Seite wird gegen den Uhrzeigersinn gedreht. Dann liegen die unvollständigen Blöcke oben, was nicht erlaubt ist. Also werden sie nach unten verschoben. Da passen sie vom Bildinhalt aber nicht hin, was dann als Bildfehler wahrgenommen wird.

Zwei Absätze höher steht übrigens folgendes:

Ein JPEG-Bild besteht aus Koeffizienten. Diese speichern keine Pixel, sondern Annäherungen des gesamten Bildinhalts eines 8×8-Bildblocks.

Wahrscheinlich ist das der Grund, warum man das so machen kann. Aber hauptsache es funktioniert.

Einfache Lösung: Kein JPG mehr benutzen. Ist völlig überflüssig geworden, dieses Format. Falls man eines in die Finger bekommt: Sofort in lossless umwandeln. Ich nehme da erstmal PNG. Und schon hat man keinerlei Probleme beim Bearbeiten mehr. Das Mehr an Speicherplatz ist be den Speichergrößen heutzutage vernachlässigbar, auf eine einfache 8-Tbit-SSD passen hundertausende lossless-Bilder.

Einfache Lösung: Kein JPG mehr benutzen. Ist völlig überflüssig geworden, dieses Format.

Das ist praxisfremd. Ich habe auch nicht in jedem Fall Einfluss auf die Zulieferung.

Ich habe auch wenig Lust ca. 400000 Dateien nur mal so zu konvertieren. Die Kamerahersteller haben PNG noch gar nicht auf dem Schirm. Die in JPG eingebetteten Metadaten lassen sich kaum vollständig in PNG einfügen.

Man kann zwar eigene chunks erfinden (libpng ermöglicht das), aber das ist dann zu nichts kompatibel.

Das geht auch mit dem Tool Converseen. Das hat deine gewünschten Funktionen. Damit kann man auch im Batch-Modus mehrere Bilder verarbeiten.

https://wiki.ubuntuusers.de/Converseen/