Geometrie erzwingen und EXIF-Orientation korrekt anwenden mit „convert -resize“

11. Januar 2015 in GNU/Linux, Multimedia, Programmierung.

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

Facebook Reloaded

27. April 2014 in Sonstiges.

Free Speech

25. April 2011 in Gesellschaft.

Friends

25. Februar 2011 in Gesellschaft.

Computer gewinnt bei Jeopardy

11. Januar 2015 in Gesellschaft.

Ein riesiges Team von IBM-Ingenieuren hat es nach mehrjähriger intensiver Forschungs- und Entwicklungsarbeit mithilfe eines Supercomputers geschafft, mehrere Fernseh-Quizshow-Kandidaten bei einem Wettbewerb der Abfrage lexikalischen Wissens zu übertreffen.

Hurra.

Spass mit „awk“

20. August 2023 in Administration.

Heute: wir wollen alle unvollständig deinstallierten Debian-Pakete vollständig löschen (das geht mit „dpkg --purge $Paketname„). Der erste Ansatz lautete:

dpkg -l | grep ^rc | awk '{print $2}' | xargs dpkg --purge

Dies lässt sich vereinfachen zu

dpkg -l | awk '/^rc/{print $2}' | xargs dpkg --purge

Damit ist schon mal das „grep“ gespart. Aber das „xargs“ braucht man auch nicht, sondern verwendet stattdessen die Kommando-Substitution mit „Back-Ticks“ („`„):

dpkg --purge `dpkg -l | awk '/^rc/{print $2}'`

Und das war’s. 🙂

IPv6

11. Januar 2015 in Gesellschaft, Technik.

Stellen wir uns vor, es gäbe ein Gesetz, nachdem alle Hausnummern drei Stellen haben müssen.

Detailliertere Gesetzgebung beträfe die Reservierung spezieller Hausnummern für Infrastruktur (wie die Wasserwerke, Polizei o.ä.), und es gäbe „invalide“ Hausnummern ausschliesslich für den privaten Gebrauch usw. Auch die Hausnummer 0 (Null) wäre unzulässig. Natürlich wären drei Stellen in allen Diensten vorgesehen, die irgend etwas mit Hausnummern zu tun haben. Die Post zum Beispiel würde intern mit dreistelligen Dezimalfeldern arbeiten, wann immer eine Hausnummer nieder zu schreiben ist.

Irgendwann wird jedenfalls das Haus mit der Nummer 999 gebaut, und das war’s. Ab jetzt können keine weiteren Häuser mehr gebaut werden. Finito.

Was macht man jetzt?

Es ist völlig klar, dass die Lösung eine vierte (oder fünfte) Stelle bei Hausnummern zuzulassen, so trivial und augenscheinlich sie einem vollkommenen Laien erscheinen mag, absolut nicht in Frage kommt. So stellte sich ja dann schon die unmöglich zu beantwortende Frage, ob diese zusätzlichen Stellen links oder rechts hinzugefügt werden sollen! So geht das nun wirklich nicht!

Stattdessen kommen bereits in der Frühzeit der „dreistelligen Ära“, als es ca. 55 Häuser gibt, sehr kluge Menschen auf die Idee, ein neues, zusätzliches Hausnummernsystem zu entwerfen, das 12-stellig ist. Viele Wissenschaftler und Techniker finden diese Betätigung sehr zukunftsträchtig und interessant und gesellen sich dazu. Recht bald ist ein System zu Papier gebracht worden, das  mit Hausnummer-Präfixen arbeitet, von denen manche reserviert sind, andere rückwärts geschrieben werden oder werden dürfen, ausserdem darf man jedes beliebig vielmalige Auftreten der Zahl „6“ zu einer einzelnen „6“ zusammen kürzen, und man darf die Ziffer 0 auch weglassen, somit wird aus der Hausnummer  666066606660 ein einfaches „666“. Diese neuen Hausnummern sollen zusätzlich zu den alten Hausnummern an den Häusern angebracht werden. Jeder Postbote bekommt eine Schulung darin, wie er einen Brief, der nach dem alten Format adressiert ist, an eine neue Adresse ausliefert und umgekehrt, und die Post schafft sich intern eine zweite EDV an, so dass sie gleichzeitig das alte und das neue Format verwalten kann. Die Erfinder des neuen Systems bauen sich einen acht Kilometer hohen Turm aus Ebenholz voller kerzenbestückter Kronleuchter, Ritterrüstungen und  nach Möbiusart verschlungener Gänge, und jeder, der etwas von ihnen will, muss erst mit dem Pförtnerdrachen sprechen.

Das ist dann die Lösung. lol.

Array-Arithmetik in PHP

11. Januar 2015 in Programmierung.

Wirklich komisch finde ich das Ergebnis einer „Addition von Arrays“ in PHP.

<?php
$a = array(101,20,31);
$b = array(19,42,300,101);
$c = $a + $b;
$d = array_merge($a,$b);

echo
   '[a=('.implode(',',$a).')] + '.
   '[b=('.implode(',',$b).')] = '.
   ''."\n";

echo
   'array_merge(a,b) = '.
   '[d=('.implode(',',$d).')]'."\n";
?>