12.3 Erweiterte Möglichkeiten

Sie haben bereits einen wesentlichen Teil der Features von ImageAnalysis und ImageConversion im Verlauf dieses Kapitels kennengelernt. So wissen Sie, wie Sie die ImageAnalysis-Komponente verwenden, um wesentliche Informationen über eine Bilddatei zu erhalten, und wie die Komponente intern arbeitet. Sie haben gesehen, welche Handler bereitstehen und wie diese zu konfigurieren sind. Ebenso haben Sie einen Großteil ihre Funktionalitäten kennengelernt.

Außerdem haben Sie erfahren, wie die Architektur der ImageConversion-Komponente aussieht, welche Teile zur öffentlichen Verwendung bereitstehen und wie Sie diese benutzen, um Bilder zu bearbeiten.

Dieser Abschnitt wird Ihnen kurz diejenigen Features vorstellen, deren detaillierte Präsentation leider keinen Platz mehr in diesem Kapitel gefunden hat. Daneben werden Sie sehen, wie Sie die Komponenten selbst erweitern und somit eigene Mechanismen integrieren können.

12.3.1 Exif-Daten

Wie Sie in Abschnitt 12.1, »Bilder analysieren«, gesehen haben, stellt Ihnen die ImageAnalysis-Komponente verschiedenste Informationen zu einem Bild bereit. Zunächst wird beim Erzeugen einer neuen Instanz von ezcImageAnalyzer nur der MIME-Type der Datei identifiziert, was notwendig ist zur Prüfung, ob der Dateityp überhaupt analysiert werden kann. Greifen Sie dann auf eine andere Information über die Datei zu, analysiert ImageAnalysis weitere Informationen automatisch, falls noch nicht geschehen.

Neben diesen Information im Attribut $data, welche sich nicht unterscheiden sollten, egal welcher Handler sie bereitstellt, kann ImageAnalysis aber auch Daten bereitstellen, die ein Handler-spezifisches Format haben. Leider kennen ImageMagick und ext/exif ein unterschiedliches Set von EXIF-Informationen und interpretieren diese oft unterschiedlich, weshalb keine Unifizierung vorgenommen werden kann.

Sollten Sie trotzdem auf EXIF-Daten – wie zum Beispiel das Kamera-Modell mit dem ein Photo aufgenommen wurde, die Lichtverhältnisse bei der Aufnahme, einen Kommentar des Photographen oder ein integriertes Vorschaubild – zugreifen wollen, so müssen Sie die Unterschiede in den Handlern selbst beachten. Möglich ist der Zugriff mittels des Attributs $exif der Klasse ezcImageAnalyzerData, das ein assoziatives Array mit den gewünschten Informationen bereitstellt.

Achten Sie darauf, dass die EXIF-Daten beim PHP-Handler nur bereitstehen, falls die PHP-Erweiterung ext/exif verfügbar ist. Der ImageMagick-Handler unterstützt EXIF von Natur aus, allerdings muss für diesen Handler das ImageMagick-Programmpaket installiert sein. Außerdem ist zu beachten, dass EXIF nur von wenigen Bildformaten wie JPEG und TIFF unterstützt wird.

12.3.2 Weitere Filter

Im Verlauf des Kapitels sind Ihnen bereits einige Filter der ImageConversion-Komponente begegnet. So kennen Sie bereits Filter des Interfaces ezcImageGeometryFilters und einige andere. An dieser Stelle wollen wir einen kurzen Überblick über alle mitgelieferten Filter-Interfaces und deren Unterstützung durch die beiden Handler geben. In beinahe jeder Version von ImageConversion werden dem Paket neue Filter hinzugefügt. Es lohnt sich also, wenn Sie ab und zu mal einen Blick in die Onlinedokumentation werfen, um auf dem Laufenden zu bleiben.

ezcImageColorspaceFilters

Dieses Interface bestimmt Filter zur Konvertierung zwischen verschiedenen Farbräumen und wird von beiden Handlern implementiert. Die einzige Filter-Methode heißt colorspace() und nimmt einen Parameter entgegen, der den Ziel-Farbraum bestimmt. Sie haben bereits die Konstante ezcImageColorspaceFilters::COLORSPACE_GREY als validen Wert kennengelernt, neben der noch COLORSPACE_SEPIA für einen Sepia-Farbraum und COLOSPACE_MONOCHROME existieren. Der Sepia-Farbraum wird häufig benutzt, um den Effekt eines alten Photos zu erzeugen, wie es oft in Western-Filmen zu sehen ist. Monochrome Bilder sind in Schwarz-Weiß gehalten.

ezcImageEffectFilters

Das Filter-Interface ezcImageEffectFilters wird ausschließlich vom ImageMagick-Handler implementiert. Die hier definierten Methoden erlauben es Ihnen, ein Bild mit Effekten zu versehen, wie Rauschen (noise()), Strudel (swirl()) oder Rahmen (border()). Da insbesondere der Strudel-Filter größere Mengen an Rechenzeit verschlingen würde, wenn man ihn mit dem GD-Handler emulieren würde, wurde darauf verzichtet, diesen hier zu implementieren. Sie können diese Filter also nur verwenden, falls Sie die ImageMagick-Programme installiert haben.

noise() erwartet den Namen eines Rauschtyps, der von ImageMagick unterstützt wird und swirl() erhält die Intensität des Strudels als Integer-Wert. Die Parameter des Rahmenfilters sowie die Breite und Farbe des Rahmens, haben Sie bereits im vorherigen Abschnitt kennengelernt.

ezcImageGeometryFilters

Geometrische Filter, wie sie dieses Interface bereitstellt, finden erfahrungsgemäß die häufigste Anwendung. Neben dem bereits bekannten Filter scale() sind noch weitere Methoden zur Skalierung von Bildern enthalten: Die Methoden scaleWidth() und scaleHeight() erhalten jeweils nur zwei Parameter, im Gegensatz zu scale(). Der erste repräsentiert die neue Breite (scaleWidth()) oder Höhe des Zielbildes, das passende Gegenstück wird jeweils entsprechend skaliert. Der zweite Parameter ist, Sie kennen es bereits von scale() her, der Richtungsindikator, welcher bestimmt, ob immer skaliert werden soll oder lediglich größer oder kleiner.

Die Methode scalePercent() arbeitet nicht mit Pixel-Werten, sondern erhält Prozentangaben für die neue Breite und Höhe in Bezug auf die Ursprungsgröße. Die letzte Skalierungsmethode trägt den Namen scaleExact() und erhält ebenfalls Breite und Höhe als Parameter. Sie arbeitet ganz ähnlich wie scale(), allerdings skaliert diese Methode ohne Beachtung des Seitenverhältnisses jedes Bild in exakt die gleich Größe. Diese Methode erlaubt somit interessante Verzerrungseffekte.

Schließlich gib es den Filter crop() in ezcImageGeometryFilters, der ein Bild beschneidet. Seine Parameter bestehen aus der X- und der Y-Koordinate des Punktes, an dem der Ausschnitt beginnen soll, sowie dessen Breite und Höhe. In dieser Reihenfolge, als Integer-Werte in Pixeln gemessen. Das Koordinatenkreuz befindet sich (wie in den meisten Graphik-APIs) in der oberen linken Ecke des Bildes.

Bei allen Positionsangaben in ImageConversion besteht die Möglichkeit, auch negative Werte anzugeben. Dies spiegelt sozusagen den Koordinatenursprung auf die gegenüberliegende Ecke; der Betrag der Koordinaten wird also von unten rechts aus in das Bild hinein gemessen.

ezcImageThumbnailFilters

Eine Methode dieses Interfaces, welches von beiden Handlern implementiert wird, haben Sie bereits im letzten Abschnitt kennengelernt: croppedThumbnail() erwartet die Breite und Höhe des zu erstellenden Vorschaubildes und führt alle notwendigen Schritte aus. Konkret bedeutet dies, dass zunächst eine Skalierung erfolgt, sodass eine Kante des Bildes in die angegebenen Maße passt. Allerdings wird hier nicht so skaliert, dass das entstehende Bild im Zweifelsfall zu klein ist, sondern umgekehrt: es stehen Kanten über. Diese werden anschließend abgeschnitten, womit alle Vorschaubilder die gleiche Größe haben. Teile des Bildes gehen dabei allerdings verloren.

Möchten Sie diesen Verlust bei der Erzeugung eines Vorschaubildes nicht in Kauf nehmen, so greifen Sie eher zu filledThumbnail(). Diese Methode erwartet ebenfalls Breite und Höhe des Vorschaubildes in Pixeln sowie ein Array mit Farbwerten. Das Bild wird von dieser Methode soweit skaliert, dass es komplett in den angegebenen Bereich passt. Entstehen dabei freie Flächen, werden diese mit den übergebenen Farbwerten gefüllt, sodass wiederum alle Vorschaubilder gleich groß sind. Der Farbwert-Parameter ist ein Array von Rot-Grün-Blau-Werten (RGB), wobei jede Farbe einen Wert zwischen 0 und 255 annehmen kann.

ezcImageWatermarkFilters

Auch von der bereits gesehenen Methode watermarkPercent() existiert ein Pendant, welches mit Pixel-Werten arbeitet statt mit Prozentangaben: watermarkAbsolute(). Beide Methoden haben eine sehr ähnliche Signatur.

Zunächst wird der Pfad zu dem Wasserzeichenbild übergeben, das dem Zielbild hinzugefügt werden soll. Dieses kleine Bild kann in einem beliebigen Format vorliegen, das ein Handler bearbeiten kann. Allerdings enthalten die gewünschten Bilder meist Transparenz- oder sogar Semi-Transparenz-Werte, die zum Beispiel im JPEG-Format nicht gespeichert werden können. Wir empfehlen daher PNG als Trägerformat für das Wasserzeichen, ähnlich wie Sie es im Beispielcode auf Ihrer Buch-CD finden.

Parameter zwei und drei sind die X- und Y-Koordinaten des Punktes im Zielbild, an dem das Wasserzeichen entstehen soll (Koordinatenursprung oben links). Im watermarkPercent()-Filter ist die Angabe ein Prozentwert, der sich auf die Seiten des Zielbildes bezieht. Zweimal der Wert 50 würde die linke obere Ecke des Wasserzeichens genau in den Mittelpunkt des Zielbildes setzen. watermarkAbsolute() erhält absolute Werte in Pixeln als Koordinaten.

Außerdem erhält diese Methode einen Parameter mehr als watermarkPercent(). Im Gegensatz zu den Letzteren erhält watermarkAbsolute() optional die Werte für die Breite und die Höhe, auf die das Wasserzeichen skaliert werden soll, falls dies gewünscht ist. Falls nicht, so übergeben Sie zweimal einfach nichts oder den Default-Wert false. Die Methode watermarkPercent() hingegen erwartet optional nur einen Parameter für die Größe: Einen Prozentwert, der sich wiederum auf die Größe des Zielbildes bezieht. Das Wasserzeichen wird somit jeweils auf einen bestimmten Anteil des Zielbildes skaliert; das Seitenverhältnis wird dabei nicht geändert.

Auch diese zwei Filtermethoden akzeptieren negative Koordinatenwerte, um statt von der linken oberen Ecke von rechts unten zu messen. Das Interface wird von beiden Handlern implementiert.

12.3.3 ImageAnalysis erweitern

Es besteht die Möglichkeit, einen eigenen Handler für die ImageAnalysis-Komponente zu schreiben. Vielleicht benötigen Sie andere oder lediglich mehr Daten zu einem Bild oder wollen einen Handler für ein neues Backend bereitstellen.

Grundsätzlich bleiben Ihnen zwei Möglichkeiten vorzugehen: Sie können einen der mitgelieferten Handler erweitern oder einen völlig neuen implementieren. Da die Möglichkeiten des ersten Falles für ImageAnalysis eine Teilmenge des zweiten darstellen und die Implementierung eines eigenen Handlers hier recht einfach ist, besprechen wir lediglich die Erstellung einer komplett eigenen Handler-Klasse.

Zur Erstellung eines eigenen Handlers reicht es aus, die abstrakte Klasse ezcImageAnalyzerHandler zu erweitern. Diese implementiert bereits einen generischen Konstruktor sowie vier abstrakte Methoden, die von Ihnen zu implementieren sind.

Die Methode isAvailable() soll testen, ob die benötigten Voraussetzungen zur Verwendung Ihres Handlers gegeben sind, wie zum Beispiel ein installiertes Programm oder eine PHP-Erweiterung. Gibt diese Methode true zurück, wird der Handler vom ezcImageAnalyzer als verfügbar gespeichert. Die Methode analyzeType() erwartet den Pfad zu einer Bilddatei als Parameter und gibt den MIME-Type des darin enthaltenen Bildes zurück. Sollte die Analyse aus dem Grund fehlschlagen, dass der MIME-Type der Datei nicht erkannt werden konnte, sollten Sie eine ezcImageAnalyzerFileNotProcessableException werfen. Für die meisten anderen Fällen sind Exceptions aus der Base-Komponente verfügbar.

Die Methode canAnalyze() erhält einen MIME-Type als Zeichenkette und soll bestimmen, ob der übergebene Typ genauer analysiert werden kann. Ist dies der Fall, so muss die Methode analyzeImage() in der Lage sein, eine Datei dieses Typs zu analysieren und eine gefüllte Instanz von ezcImageAnalyzerData zurückzugeben.

Einen so implementierten Handler müssen Sie lediglich, wie in Abschnitt 12.1, »Bilder analysieren«, gesehen, der Klasse ezcImageAnalyzer bekanntgeben, welche diesen dann verwendet. Soll Ihr Handler konfigurierbar sein, so verarbeitet der Konstruktor der Basisklasse bereits ein Array mit beliebigen Optionen und speichert es im geschützten Attribut $options. Sie können entweder einfach auf dieses Attribut zugreifen und bei Verwendung testen, ob valide Einstellungen vorhanden sind, oder den Konstruktor überschreiben und die Prüfung hier zentral vornehmen.

12.3.4 ImageConversion erweitern

Die Erweiterung der ImageConversion-Komponente gestaltet sich wesentlich komplizierter als die Implementierung eines ImageAnalysis-Handlers. Aus diesem Grund werden wir hier genau umgekehrt zum letzten Abschnitt verfahren und nur auf die Erweiterung eines bestehenden Handlers eingehen anstatt auf die Programmierung eines komplett neuen Handlers.

Abstrakte Basis

Beide mitgelieferten Backend-Handler können Sie einfach mit einer neuen Klasse erweitern und somit Methoden hinzufügen oder überschreiben. Dabei gilt es, zunächst zu unterscheiden, ob Sie einen Filter hinzufügen oder etwas an der Grundfunktionalität des Handlers ändern wollen. Im Folgenden gehen wir auf die Grundfunktionen beider Filter ein. Im Anschluss daran werden Sie sehen, was nötig ist, um einen eigenen Filter zu implementieren.

Wie Sie in Abschnitt 12.2, »Bilder manipulieren«, gesehen haben, wird jeder Handler durch die abstrakte Basisklasse ezcImageHandler gezwungen, Methoden zu implementieren, die das Laden (load()), Speichern (save()) und Schließen (close()) zulassen. Die Methoden applyFilter() zum Anwenden einer Filterdefinition in Form eines ezcImageFilter-Objekts und convert() zum Konvertieren eines Bildes in einen bestimmten MIME-Type sind ebenfalls notwendig. Beide arbeiten mit Bildreferenzen, die von der load()-Methode zurückgegeben werden müssen.

Außerdem müssen Handler die Frage nach den von ihnen unterstützten Filtern (getFilterNames()) unterstützen sowie Fragen nach einem bestimmten Filter (hasFilter()). Hinzu kommen die Methoden allowsInput() und allowsOutput(), die angeben, ob ein bestimmter MIME-Type als Eingabe- bzw. Ausgabeformat unterstützt wird.

Dieses Interface erlaubt es den anderen Teilen des ImageConversion-Pakets, alle Handler einheitlich zu verwenden. Da beide mitgelieferten Handler ähnliche Mechanismen verwenden, insbesondere was die Verwaltung von Referenzen angeht, wurde eine weitere abstrakte Klasse zwischengeschaltet, um doppelten Code zu vermeiden: ezcImageMethodCallHandler.

Die Method-Call-Handler-Klasse implementiert das komplette Handling von Referenzen für beide Handler. Eine Referenz wird intern als Array abgelegt, das Informationen zu der geöffneten Datei enthält. Später in diesem Abschnitt werden Sie die genaue Struktur noch kennenlernen. Zunächst ist wichtig, dass die interne Behandlung von Bildreferenzen einheitlich ist.

Passend zu diesen beiden Methoden, implementiert die gemeinsame Basis der Backend-Handler hasFilter() und getFilterNames() beide auf Basis der Reflektion aller öffentlichen Methoden des Objekts bis auf das Basis-Interface. Das ist zu beachten, wenn Sie eigene Methoden hinzufügen: Jede öffentliche Methode, die nicht dem Basis-Interface entspricht, wird als Filter angesehen. Zur MIME-Type-Konvertierung werden noch die Methoden allowsInput() und allowsOutput() bereitgestellt. Beide arbeiten wie convert() auf zwei Objekt-Arrays, die in den Erweiterungen befüllt werden müssen. $inputTypes muss die MIME-Types als String enthalten, die der Handler als Eingabe verarbeiten kann, analog dazu $outputTypes.

Zum Schluss überschreibt der Method-Call-Handler den Konstruktor der ursprünglichen Basisklasse und fügt einen Destruktor hinzu. Letzterer sorgt dafür, dass alle offenen Referenzen beim Zerstören des Konverters ordnungsgemäß geschlossen werden, um keine »Datenleichen« zu hinterlassen.

Gemeinsamkeiten

Bedingt durch die gemeinsame Basis, den Method-Call-Handler, der bereits einen großen Teil des Interfaces definiert, ist die Erweiterung beider Handler sehr ähnlich – in Details unterscheiden sie sich dennoch. Welche Gemeinsamkeiten es gibt und worin die Unterschiede liegen, werden Sie im Folgenden sehen, während wir weiter in das Interface des Methode-Call-Handlers aus dem letzten Abschnitt eindringen.

Bisher haben Sie die öffentlichen Methoden kennengelernt, die der Method-Call-Handler bereitstellt. Daneben implementiert er eine Vielzahl geschützter Hilfsmethoden, von denen in den Erweiterungen Gebrauch gemacht wird. Um den Rahmen nicht zu sprengen, verzichten wir hier darauf, alle Methoden vorzustellen und beschränken uns auf die wichtigsten.

Dies sind zunächst diejenigen zum internen Zugriff auf Bildreferenzdaten. Zu jedem geöffneten Bild hält der Method-Call-Handler den Pfad zur Bilddatei (file), den MIME-Type des Bildes (mime) und eine beliebige Ressource (resource) bereit. Letztere kann von der Erweiterung beliebig genutzt werden und findet intern in der Basisklasse keine Verwendung.

Zum Zugriff auf diese Daten gibt es eine Reihe von Methoden: getReferenceData() erwartet als ersten Parameter den Referenz-String des Bildes. Wird der zweite Parameter nicht angegeben, gibt die Methode das komplette Daten-Array zurück. Übergeben Sie in ihm den Namen eines der Referenz-Details, so wird lediglich dessen Wert zurückgegeben. Analog dazu können Sie setReferenceData() verwenden, um Details zu ändern, wobei diese Methode drei Parameter erwartet. Der erste Parameter gibt wiederum die Bildreferenz an, für die ein Detail geändert werden soll. Der zweite Parameter kann zum einen ein einzelner Wert für ein Detail sein oder wiederum das komplette Daten-Array. Ist Ersteres der Fall, so muss der optionale, dritte Parameter das zu ändernde Detail bestimmen.

Einige weitere Methoden werden Ihnen wenig später noch begegnen. Nicht beschäftigen werden uns allerdings die Methoden loadCommon(), saveCommon() und closeCommen(), welche die Referenz-Behandlung einheitlich beim Laden, Speichern und Schließen von Dateien lösen.

Damit haben Sie die letzte gemeinsame Basis der beiden Handler-Klassen kennengelernt: Ab hier ändert sich einiges.

Unterschiede

Äußerst gravierend sind die Unterschiede zwischen dem ImageMagick-Handler und dem ext/gd-Handler nicht. Allerdings enthalten sie gerade bei der Implementierung neuer Filter einige Fallstricke.

Bedingt durch ihren strukturellen Unterschied, erfolgen Filter-Manipulationen in beiden Klassen völlig unterschiedlich. Während der GD-Handler einfach die Ressource vom Typ GD in den Referenzdaten hinterlegt und Filtermethoden darauf arbeiten lässt, muss die ImageMagick-Variante andere Wege gehen. Bei ihr werden Filter erst ganz zuletzt, beim Speichern der Datei, ausgeführt. Denn es handelt sich um einen Konsolenaufruf, der Parameter für alle Filter und Konvertierungen enthält.

Dementsprechend sind auch das Öffnen, Speichern und Schließen in beiden Handler-Klassen unterschiedlich gelöst, was aber an dieser Stelle zu weit führen würde. Diese Funktionalitäten wurden der Übersichtlichkeit halber für beide Handler in eine weitere Klassen-Ebene ausgelagert: ezcImageGdBaseHandler und ezcImageImagemagickBaseHandler. In diesen beiden Klassen werden alle Handler-spezifischen Basisfunktionalitäten realisiert, während die Filter-Methoden getrennt in den eigentlichen Handler-Klassen residieren.

Wie sich die Unterschiede zwischen den Handler-Implementierungen praktisch bemerkbar machen, erfahren Sie im folgenden Abschnitt, wo die Implementierung eigener Filter erläutert wird. An diesem Punkt können Sie entscheiden, wie Sie bei der Erweiterung eines bestehenden Handlers vorgehen wollen: Wollen Sie keinen der eZ Components-eigenen Filter benutzen, können Sie eine der Base-Handler-Klassen erweitern. Falls Sie nicht auf die bereits existierenden Filter verzichten wollen, erweitern Sie einfach die eigentlichen Handler-Klassen.

Referenzdaten

Filtermethoden erfahren nicht direkt etwas von der Referenz, auf deren Bild sie angewendet werden sollen, das sehen die Filter-Interfaces nicht vor. Hingegen wird stets eine einzelne Referenz als aktiv markiert und jegliche Manipulation auf dieser Referenz ausgeführt.

Sie können jederzeit auf den Pfad der Datei, ihren MIME-Type und auf eine vom Handler definierte Ressource zugreifen. Da der GD-Handler intern eine Ressource verwendet, greifen Sie bei der Erweiterung ebenfalls darauf zu und verwenden sie mit beliebiger Funktion aus ext/gd. Allgemein können Sie zum Zugriff auf das zu bearbeitende Bild die Methoden getReferenceData() und setReferenceData() verwenden.

Dazu benötigen Sie allerdings die ID des Bildes, auf dem Sie arbeiten wollen. Diese bringen Sie mit Hilfe der Methode getActiveReference() in Erfahrung. Um also in einer Erweiterung des GD-Handlers auf die GD-Ressource zuzugreifen, verwenden Sie zum Beispiel den folgenden Code:

$res = $this->getReferenceData(
    $this->getActiveReference(),
    'resource'
);

Listing 12.17 Lesen von Informationen zur aktiven Bildreferenz

Das Setzen von Informationen erfolgt ganz ähnlich. Allerdings können Sie hier auch ein Array von Daten angeben, die überschrieben werden sollen, statt eines einzelnen Parameters. Dies ist hier dargestellt:

$this->setReferenceData(
    $this->getActiveReference(),
    $res,
    'resource'
);

Listing 12.18 Schreiben von Informationen zur aktiven Bildreferenz

Bei der Erweiterung des GD-Handlers sowie bei der Implementierung eines eigenen Handlers, der ressourcenbasiert ist, haben Sie die Möglichkeit, direkt auf die Ressource des aktiven Bildes zuzugreifen: mittels getActiveResource() und setActiveResource(). Letztere Methode ist besonders wichtig, wenn Sie die GD-Ressource komplett austauschen wollen, was im Fall von Bildkopien, Skalierung und Ähnlichem nützlich ist.

Der ImageMagick-Handler arbeitet intern nicht mit dem Ressource-Feld der Datenstruktur, da keine existiert und lediglich auf den Pfad zugegriffen werden muss. Außerdem werden Filteraufrufe in diesem Handler nicht direkt ausgeführt, sondern erst beim Speichern des Bildes. Dies trägt der Tatsache Rechnung, dass Aufrufe auf der Shell aus PHP-Programmen heraus recht »teuer« sind.

Der Aufruf an die Shell beim Speichern eines Bildes im ImageMagick-Treiber enthält also alle durch Filter angewendeten Optionen auf einmal. Um aus Ihrem eigenen Filter heraus dem Shell-Aufruf weitere Optionen hinzuzufügen, verwenden Sie die geschützte Methode addFilterOption(), die vom ezcImageImagemagickBaseHandler bereitgestellt wird. Die Methode erhält als ersten Parameter die Referenz auf ein Bild. Der zweite Parameter ist diejenige Option, die an den convert-Aufruf übergeben werden soll, zum Beispiel '-resize' im scale()-Filter. Optional können Sie auch den dritten Parameter verwenden, welcher einen Parameter-String enthalten kann, der der Option beim Aufruf mitgegeben wird.

Ihr Kommentar