Nach so vielen Jahren tritt immer noch ein Feature von „convert“ zutage, das ich nicht gekannt habe, und bei dem ich mich frage, wie das überhaupt sein kann. Ich musste ein Batch-Skript mit ImageMagick prototypen, das nebst anderem Bilder auf eine vorgegebene Größe skalieren kann. Es seien also folgende Eingaben gegeben:

Pixmap "image_in": das originale Bild
int "width": geforderte Breite in Pixeln
int "height": geforderte Höhe in Pixeln

Als Ausgabe zu erstellen ist:

Pixmap "image_out": das skalierte Bild

Also schreibt man ja wohl

convert -resize ${width}x${height} $image_in $image_out

Das funktioniert auch, mit der merkwürdigen Einschränkung, dass „convert“ mit diesem Aufruf das Seitenverhältnis nicht ändert, sondern stattdessen … naja, prinzipiell irgendwelche Breiten bzw. Höhen liefert. Es funktioniert genau genommen überhaupt nicht, bzw. in fast keinem Fall, ausser in denen, in denen das Verhältnis originaler Höhe zu originaler Breite (zufällig) genau dem Verhältnis von geforderter Höhe zu geforderter Breite entspricht. Um genauer zu sein, gibt es eine Systematik darin, wie die Eingabe-Geometrie in die Ausgabe-Geometrie umgesetzt wird, aber diese ist an einer unerwarteten Stelle dokumentiert [1] (wieder so eine Schnitzeljagd-Dokumentation, der man hinterher Googlen muss). Komisch eigentlich! Was ist also zu tun? Nun, wie [1] goldrichtig erklärt, muss der Geometrie-Spezifikation ein „!“ nachgestellt werden. An derselben Stelle heisst es auch:

By default, the width and height given in a geometry argument are maximum values unless a percentage is specified.

Aha! 🙂 Also schreiben wir:

convert -resize ${width}x${height}\! $image_in $image_out

Beachte, dass das „! mit einem Backslash vor der Interpretation durch die Bourne Again Shell selbst geschützt werden muss, da „!“ zumindest dort eine spezielle Bedeutung hat (nicht aber beispielsweise in der „dash“, der Debian-Auslegung der „POSIX-Shell“, dort bewirkt der Backslash in diesem Zusammenhang nichts, muss also nicht weggelassen werden).

Nicht gerade vereinfacht wird die Sachlage dadurch, dass „convert“ in der mir vorliegenden Version bei einem „-resize“ von und nach JPEG die EXIF-Orientierung durcheinanderbringt, das heisst, je nach deren Wert kann das Bild um 90 oder 180 Grad gedreht oder gar spiegelverkehrt erscheinen! Hilfreich bei der Auswertung des Wertes von EXIF:Orientation sind [2] und [3], den Wert erhältman mit dem ImageMagick-Befehl „identify“:

identify -verbose "$image_in" | fgrep exif:Orientation

Konkret geschieht bei einem Test-JPEG „IMG_0948.JPG“ mit der EXIF-Orientation „6“ bei oben beschriebenem Aufruf folgendes (getestet mit ImageMagick Version 6.6.0 auf Debian experimental):

Wie man sieht, verrafft es schon die WordPress-Vorschaufunktion, das Bild ist nämlich von meiner Kamera mit der korrekten EXIF-Orientation ausgestattet worden. Eigentlich sollte es um 90 Grad im Uhrzeigersinn hochkant dargestellt werden. Da ich am Rechner mit dem Original arbeite und einen EXIF-fähigen Viewer verwende (z.B. gliv), bekomme ich davon nichts mit, bis es zu spät ist.

Ich beschäftige mich erstmal mit der Skalierung: Ich will dieses Bild „plattdrücken“, das heisst, unter Berücksichtigung der EXIF-Orientierung soll die Höhe kleiner sein als die Breite. ich sage also:

convert -resize 200x100\! IMG_0948.JPG out.jpg

Das Ergebnis ist:

Das ist jetzt auch ungeachtet der Frage, ob mein Viewer EXIF-Orientation kann oder nicht, falsch. Es wurde nicht die tatsächliche Höhe kleiner als die tatsächliche Breite, sondern es wurden die Ausdehnungen des Bildes ohne Berücksichtigung derer Bedeutung unter Anwendung von EXIF-Orientation verändert: das Ergebnis ist also tatsächlich in die Höhe langgestreckt.

Was ist zu tun, damit dieser Effekt vermieden wird? Zum Glück hat „convert“ die Option „-auto-orient“. Diese nimmt die EXIF-Orientierung, dreht und spiegelt das Bild entsprechend und setzt exif:Orientation dann immer auf „1“ (TopLeft), was gerade dem Fall entspricht, dass gar keine Orientation angegeben wäre (also kompatibel mit Viewern ist, die keine Orientation berücksichtigen können). Wichtig ist, diese Operation vor dem „-resize“ auszuführen, damit dieses dann bereits auf den tatsächlichen Bedeutungen von „Breite“ und „Höhe“ operiert und nicht auf denen, die EXIF-Orientation noch nicht eingerechnet haben:

convert -auto-orient -resize 200x100\! IMG_0948.JPG out2.jpg

Jetzt prüfe ich das Ergebnis nach:

identify -verbose out2.jpg | fgrep exif:Orientation
exif:Orientation: 1

Es sieht jetzt so aus:

Das ist richtig bzw. der gewollte Effekt.

[1] ImageMagick Website: ImageMagick Command-line Processing: Basic adjustments to width and height; the operators %, ^, and !
URL (10.05.2011): http://www.imagemagick.org/script/command-line-options.php#resize

[2] sylvana.net: Exif Orientation Tag (Feb 17 2002)
URL (10.05.2011): http://sylvana.net/jpegcrop/exif_orientation.html

[3] ImpulseAdventure: Digital Photography Articles: JPEG Rotation and EXIF Orientation
URL (10.05.2011): http://www.impulseadventure.com/photo/exif-orientation.html