Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort des Fachgutachters
Vorwort
1 Einleitung
2 Einführung in eZ Components
3 Die Applikationsbasis
4 Fehlerbehandlung und Debugging
5 Konfiguration
6 Datenbankanbindung
7 ORM mit PersistentObject
8 Template
9 Übersetzung
10 Benutzereingaben validieren
11 Authentifizierung
12 Bildverarbeitung
13 Archive und Dateien
14 Mail
15 Logging
16 Diagramme
17 Feeds und Caching
18 Setup
A Inhalt der Buch-CD
Stichwort
Download: - ZIP, ca. 2,7 MB
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /eZ Components | vor >>
eZ Components von Tobias Schlitt, Kore Nordmann Das Entwickler-Handbuch
eZ Components geb., mit CD 454 S., 39,90 Euro Galileo Computing ISBN 978-3-8362-1073-7 |
| 12 Bildverarbeitung
|  | 12.1 Bilder analysieren
|  |  | 12.1.1 Architektur
|  |  | 12.1.2 Handler und Backends
|  | 12.2 Bilder manipulieren
|  |  | 12.2.1 Architektur
|  |  | 12.2.2 Handler und Backends
|  |  | 12.2.3 Im GP-Blog
|  | 12.3 Erweiterte Möglichkeiten
|  |  | 12.3.1 Exif-Daten
|  |  | 12.3.2 Weitere Filter
|  |  | 12.3.3 ImageAnalysis erweitern
|  |  | 12.3.4 ImageConversion erweitern
|  | 12.4 Fazit
Die Anwendungen für Bildanalyse und Bildverarbeitung sind vielfältig, egal ob Sie Benutzern erlauben, Photos einzustellen oder eine Online-T–Shirt-Druckerei betreiben wollen. In diesem Kapitel geben wir Ihnen die Komponenten ImageAnalysis und ImageConversion an die Hand, welche Sie bei solchen Aufgaben unterstützen. # 12 Bildverarbeitung eZ Components stellen im Wesentlichen zwei Komponenten zum Umgang mit bereits existierenden Bilddateien bereit. Daneben gibt es noch die Graph-Komponente, welche Thema des Kapitels 16, »Diagramme«, ist. Beide Komponenten, ImageAnalysis und ImageConversion, unterstützen Sie bei der Analyse von Bilddateien und bei deren Manipulation und Bearbeitung. ImageAnalysis erlaubt es Ihnen, Informationen wie den MIME-Typ, die Höhe und Breite oder die Farbtiefe aus einer Bilddatei zu extrahieren und zu interpretieren. Die ImageConversion-Komponente ermöglicht Ihnen die Konvertierung zwischen verschiedenen MIME-Types und stellt Ihnen eine Vielzahl von Effekt- und Manipulationsfiltern bereit.
MIME-Type
Beide Image-Komponenten verwenden das Prinzip der MIME-Types, um den Inhalt von Bilder zu identifizieren. Bei diesem Klassifizierungsschema handelt es sich um einen Standard der IANA [http://www.iana.org/assignments/media-types/], welche unter anderem für die Verwaltung wichtiger Internetstandards wie der IP-Infrastruktur zuständig ist. Die IANA definiert MIME-Types grundsätzlich zur Verwendung in E-Mails, wobei dort die Klassifizierung der Inhalte einzelner Mail-Bestandteile zum Beispiel für die Einbettung von Bildern und Anhängen nötig ist. Ein MIME-Type besteht immer aus einem Haupttyp, welcher die grundlegende Kategorie des Inhalts beschreibt, und einem Subtyp, der das konkrete Format angibt. Haupttypen sind zum Beispiel image für Bildformate, audio für Sound und application für anwendungsspezifische Inhalte. Subtypen des Haupttyps image sind unter anderem jpeg für JPEG-komprimierte Bilder sowie entsprechend png, bmp und tiff. Der komplette MIME-Type eines Inhalts setzt sich aus Haupttyp und Subtyp zusammen, die durch einen Schrägstrich getrennt werden: zum Beispiel image/jpeg für JPEG-Bilder oder application/pdf für PDF-Dokumente. Letzteres Format ist zwar dem Haupttyp application zugeordnet, es handelt sich aber dennoch um eine Art Bild. Einige Handler von ImageAnalysis und ImageConversion können entsprechend damit umgehen.
Als Feature für das GP-Blog wird in diesem Kapitel die Möglichkeit geschaffen, dass der Benutzer Bilder auf den Webserver hochladen kann, die dann automatisch verarbeitet werden. Hochgeladene Bilder werden auf drei unterschiedliche Formate skaliert, in ein einheitliches Format konvertiert und durch spezielle Links zur Verwendung in Blog-Einträgen bereitgestellt. Letzteres wird es uns später ermöglichen, die Zugriffszahlen für Bilder zu loggen und die daraus resultierenden Statistiken zu visualisieren, was Thema im darauffolgenden Kapitel 16, »Diagramme«, sein wird. Beide Aktionen, der Bild-Upload und die Bildanzeige, werden in einem neuen Action-Controller gebündelt, der den Namen gpBlogActionGallery trägt. Hier werden im Wesentlichen drei neue Slots für den Haupt-Controller des GP-Blogs registriert: create_media, der das Formular zum Senden eines Bildes anzeigt, save_media zum Speichern und view_media zum Anzeigen von Bildern. Erstere Aktion zeigt lediglich ein Formular aus einem Template an, was hier nicht Thema sein soll, da es bereits in Kapitel 8, »Template«, besprochen wurde. Die beiden anderen Aktionen werden aber ausführlich analysiert. ## 12.1 Bilder analysieren Zunächst sollen Sie die Bildanalyse mittels ImageAnalysis kennenlernen. Sie wird in den neuen Funktionen des GP-Blogs an zwei Stellen verwendet: Zum einen werden die hochgeladenen Bilddateien auf Validität geprüft, bevor mit der Manipulation begonnen wird. Zum anderen wird die Komponente bei der Anzeige von Bildern verwendet, um den korrekten MIME-Type zu ermitteln, der an den Browser zu senden ist. Der letzteren Aktion wollen wir uns zuerst widmen (was Ihnen auf den ersten Blick unlogisch erscheinen wird). Allerdings ist die Anzeige-Aktion weniger komplex als die Aktion, in der Manipulationsmechanismen verwendet werden, und macht mehr Gebrauch von ImageAnalysis. ### 12.1.1 Architektur Die ImageAnalysis-Komponente ist recht schlank: Neben der Hauptklasse ezcImageAnalyzer und den dazugehörigen Handler-Klassen existiert noch eine Struct-Klasse namens ezcImageAnalyzerData, welche die Haltung der analysierten Daten übernimmt. Sie verwenden die Hauptklasse, um die Analyse eines Bildes anzustoßen, das dann im Hintergrund verschiedene Handler benutzen kann, um ein Objekt vom Typ ezcImageAnalyzerData mit Daten zu befüllen. Beim Upload eines Bildes werden im GP-Blog drei Varianten des Bildes gespeichert. Zunächst das Bild in Originalgröße, mit lediglich kleinen Modifikationen, unter dem Varianten-Namen original. Daneben werden zwei skalierte Varianten bereitgehalten: medium wird eine Version des Bildes enthalten, welches auf annehmbare Größe zur Darstellung in einem Blog-Eintrag skaliert wurde, und die Variante thumb stellt ein kleines Vorschaubild bereit. Alle drei Varianten eines Bildes werden im Verzeichnis uploads/ gespeichert, unterschieden durch ihre Dateinamen. Lädt der Benutzer ein Bild namens bungee_jumping_in_norway.jpg hoch, werden die drei Dateien uploads/bungee_jumping_in_norway_original.jpg, uploads/bungee_jumping_in_norway_medium.jpg und uploads/bungee_jumping_in_norway_thumb.jpg daraus erzeugt. Mit Hilfe der View-Aktion, welche zwei Parameter erhält, um diese Varianten eines Bildes zu identifizieren, kann der Benutzer auf die einzelnen Varianten zugreifen. Erstens erhält die Aktion den Namen des Bildes (ohne Dateiendung), zweitens den Namen der Variante. Der zweite Parameter ist hierbei optional und standardmäßig wird die Variante medium angezeigt.
    $file = null;
    $exts = array_values( self::$fileExtMap );
    foreach ( $exts as $ext )
    {
        $path = dirname( __FILE__ ) .
            '/../../uploads/' . "{$name}_{$size}.{$ext}";
        if ( file_exists( $path ) )
        {
            $file = $path;
        }
    }
    if ( $file === null )
    {
        gpBlogController::getInstance()->mainSignals->emit(
            "error",
            "Media not found."
        );
        return;
    }
    $analyzer = new ezcImageAnalyzer( $file );
    header( 'Content-Type: ' . $analyzer->mime );
    header( 'Content-Length: ' . $analyzer->data->size );
    readfile( $file );
Listing 12.1 Rudimentäre Bildanalyse in der Bildanzeige-Aktion des GP-Blogs Das gezeigte Beispiel enthält den wesentlichen Code zur Darstellung einer bestimmten Bildvariante. Der Code zur Extraktion und Validierung der übergebenen Parameter wurde hier weggelassen. Sie können Ihn aber auf der Buch-CD im Verzeichnis stage09/ nachvollziehen und testen. Der entsprechende Action-Controller heißt ezcBlogActionGallery, wobei im Beispiel ein Ausschnitt aus der statischen Methode view() zu sehen ist. Weitere Informationen über das Testen von Aktionen erhalten Sie in Abschnitt 1.3.3, »Testen des GP-Blogs«, während die Funktionalität von Action-Controllern in Kapitel 3, »Die Applikationsbasis«, thematisiert wurde. Die beiden Variablen $name und $size enthalten den Namen des gesuchten Bildes und den Namen der Größenvariante, wobei Letzterer bereits mit dem Standardwert medium belegt ist, falls der entsprechende Parameter nicht übergeben wurde. Der erste Teil des gezeigten Codes dient dazu, die gewünschte Bilddatei aufzufinden. Hierzu wird zunächst auf das statische Attribut $fileExtMap der Action-Klasse zugegriffen. Dieses Attribut enthält eine Abbildung von MIME-Types zu Dateiendungen, die an anderer Stelle noch von größerer Bedeutung sein wird. Hier werden lediglich alle möglichen Dateiendungen extrahiert und einzeln überprüft, ob eine entsprechende Datei gefunden werden kann.
    private static $fileExtMap = array(
        'image/jpeg' => 'jpg',
        'image/png'  => 'png',
    );
Listing 12.2 Initialisierung des $fileExtMap-Attributs Wie der Codeschnipsel zeigt, wird das Attribut zur Abbildung von MIME-Types mit lediglich zwei relevanten Dateiendungen belegt, die für JPEG- und PNG-Dateien verwendet werden. Sie werden in Abschnitt 12.2, »Bilder manipulieren«, sehen, weshalb dies ausreichend ist. Wurde keine entsprechende Datei gefunden, handelt es sich offenbar um einen Fehler, der dem Controller signalisiert wird und die Aktion beendet. Im anderen Fall kommt die ezcImageAnalyzer-Klasse ins Spiel. Zwar können der MIME-Type und die Größe der Datei in Byte auch ohne dessen Hilfe bestimmt werden, denn das eben verwendete Mapping-Array enthält die gewünschte Information bereits und die Dateigröße lässt sich in PHP auch anderweitig ermitteln, allerdings sollte man sich nie auf Dateiendungen verlassen und stets prüfen, ob der Inhalt korrekt ist. Daher stellt der ezcImageAnalyzer die Information zum MIME-Type der Datei bereit und nebenbei ebenso die Dateigröße. Bei beiden Attributen des Analyzers handelt es sich um Virtual Properties, die Sie bereits in Kapitel 2, »Einführung in eZ Components«, kennengelernt haben. Der Wert des Attributs $mime wird bereits im Konstruktor des Analyzers bestimmt und lediglich zurückgeben. Es handelt sich dabei um einen String der einen Standard-MIME-Type darstellt, zum Beispiel image/jpeg für JPEG-Bilder. Kann der MIME-Type der Datei während der Konstruktion nicht bestimmt werden, so wird eine Exception vom Typ ezcImageAnalyzerFileNotProcessableException geworfen. Außerdem erhalten Sie eine Exception für den Fall, dass die gewünschte Datei nicht existiert, ezcBaseFileNotFoundException, oder nicht lesbar ist, ezcBaseFilePermissionException. Beide Exception-Typen haben Sie bereits in Kapitel 2, »Einführung in eZ Components«, kennengelernt. Die weiteren Analysedaten, welche im Attribut $data bereitgestellt werden, werden allerdings nicht sofort bei der Erzeugung des Objekts generiert, sondern beim ersten Zugriff darauf. Der Grund hierfür ist, dass die Analyse des MIME-Types am häufigsten gebraucht wird, denn sie stellt die Grundlage für weitere Analysen dar. Außerdem ist diese Analyse des MIME-Types im Gegensatz zur Analyse der weiteren Daten relativ schnell erledigt. Der Prozess dauert länger als die reine Bestimmung des MIME-Types und kann aufgeschoben werden, bis die Daten tatsächlich benötigt werden. Der erste Zugriff auf $data erzeugt in diesem Attribut eine Instanz von ezcImageAnalyzerData und befüllt dieses mit Informationen über die Dateigröße, die Breite und Höhe des Bildes sowie den Farbraum und Transparenz-Informationen. Das $data-Attribut stellt Ihnen eine Vielzahl von Informationen aus verschiedenen Quellen bereit, wie dem EXIF-Standard [http://de.wikipedia.org/wiki/EXIF ] zur Beschreibung von Bild-Metadaten. Dabei sind Informationen zur Breite, Höhe, Dateigröße und dem MIME-Type für jedes unterstützte Bildformat verfügbar. Alle weiteren Werte sind, abhängig vom MIME-Type und dem verwendetem Handler, verfügbar. Näheres dazu erfahren Sie im folgenden Abschnitt 12.1.2, »Handler und Backends«. Der gezeigte Beispielcode verwendet die von ezcImageAnalyzer bereitgestellten Daten letztendlich, um korrekten Content-Type- und Content-Length-Header an den Browser zu senden und anschließend die Bilddaten auszugeben. Die Arbeit mit ImageAnalysis ist also nicht kompliziert und mit wenigen Aufrufen können Sie interessante Metainformationen aus einem Bild extrahieren. Was hierbei im Inneren der Komponente passiert, werden wir im Folgenden vorstellen, um Ihnen einen Vorgeschmack auf die komplexeren Interna der ImageConversion-Komponente zu geben und Ihnen die Erweiterung der Komponente zu ermöglichen. ### 12.1.2 Handler und Backends Im letzten Abschnitt haben Sie gesehen, wie die ezcImageAnalyzer-Klasse verwendet wird, um eine Bilddatei zu analysieren und Ihnen verschiedene Informationen zu einem Bild bereitzustellen. Es stellt sich die Frage, wie die Komponente intern arbeitet und was Sie benötigen, um die entsprechenden Informationen von ihr zu erhalten. ImageAnalysis basiert auf dem Konzept der Backend-Handler, das Sie bereits von verschiedenen anderen Komponenten wie Database oder Configuration her kennen. Die Klasse ezcImageAnalyzer bringt von Hause aus zwei Handler-Klassen mit: Der ezcImageAnalyzerPhpHandler verwendet PHP-interne Mechanismen zur Extraktion von Metainformationen aus einem Bild. Hierbei wird die im PHP-Kern enthaltene Funktion getimagesize() [http://php.net/getimagesize ] benutzt, um die Basisdaten über ein Bild zu extrahieren, also den MIME-Type sowie die Breite und Höhe des Bildes. Für die Dateigröße werden ebenfalls Bordmitteln herangezogen, sodass auch für diese Information keine PHP-Erweiterung benötigt wird. Zur weiteren Analyse verwendet der Handler optional die Erweiterung ext/exif [http://php.net/exif ] , welche mit PHP zusammen geliefert wird, sowie einige eigene Algorithmen für die Analyse von GIF-Dateien. Der zweite Backend-Handler ezcImageAnalyzerImagemagickHandler geht einen anderen Weg. Zwar werden auch hier die initialen Daten mittels getimagesize() ermittelt, da die Funktion in allen PHP-Installationen zur Verfügung steht, für alle weiteren Analysen wird aber das externe Programm identify der Konsolen-basierten Bildbearbeitungssuite ImageMagick [http://imagemagick.org/ ] herangezogen.
ImageMagick
ImageMagick ist ein Satz von Programmen, die zur Analyse und Bearbeitung von Bildern auf der Konsole verwendet werden. Für die in diesem Kapitel vorgestellten Komponenten sind die Programme identify zur Analyse von Bildern und convert für ImageConversion wesentlich. Das ImageMagick-Paket ist für alle gängigen Unix-Derivate als auch Mac OS X und Linux sowie Windows verfügbar. Die entsprechenden Backend-Handler in den beiden Komponenten sind in der Lage, den Pfad zu den entsprechenden Programmen selbstständig zu finden, sofern das Paket korrekt installiert ist.
Der ezcImageAnalyzer kennt beide Klassen per Voreinstellung. Da jede Erweiterung von ezcImageAnalzyerHandler der abstrakten Basisklasse für Handler-Implementierungen eine Methode isAvailable() bereitstellt, ist der Analyzer in der Lage, selbstständig auf die Verfügbarkeit von Handler-Backends zu testen. Natürlich erfolgt dieser Check nur ein Mal in jedem Request, bei der ersten Benutzung von ezcImageAnalyzer, und wird für jeden weiteren Zugriff auf das Paket gespeichert. Wie Sie selbst einen eigenen Handler implementieren, erfahren Sie in Abschnitt 12.3.3, »ImageAnalysis erweitern«. #### Handler konfigurieren Über die Methode getHandlerClasses() der Klasse ezcImageAnalyser können Sie die Konfiguration der Handler abfragen und entsprechend mit der Methode setHandlerClasses() setzen. Bei dem ImageMagick-basierten Handler können Sie zum Beispiel eine Konfiguration mitgeben: $binary. Ist dieser Wert nicht gesetzt, so versucht der Handler selbst herauszufinden, wie die aus dem ImageMagick-Paket benötigten Programmdateien heißen und wo sie zu finden sind. Dazu sucht der Handler in der übergebenen Systempfadvariablen $PATH nach dem systemspezifischen Namen identify in Unix-Umgebungen oder identify.exe unter Windows-Systemen. Befindet sich Ihre ImageMagick-Installation nicht im Pfad oder heißt das benötigte Programm auf Ihrem System anders, so sollten Sie den Konfigurationswert $binary für den ImageMagick-Handler auf den absoluten Pfad zu identify setzen. Vergessen Sie hierbei auch nicht, dass der Benutzer, mit dessen Rechten Ihr PHP-Interpreter läuft, entsprechende Zugriffsrechte auf die Programmdatei benötigt. Welche Konfigurationseinstellungen ein neuer Handler erwartet, entnehmen Sie der jeweiligen Dokumentation. Achten Sie darauf, das Sie die Qualität des Quellcodes sorgfältig überprüfen, falls Sie Handler-Klassen Dritter verwenden. Insbesondere bei der Implementierung von konsolenbasierten Handler-Klassen wie dem ImageMagick-Handler kann durch Fehler in schlecht getestetem Code ein hohes Sicherheitsrisiko entstehen. Die an dieser Stelle fiktive Initialisierung von Handler-Klassen sieht praktisch wie folgt aus:
    ezcImageAnalyzer::setHandlerClasses(
        array(
            'ezcImageAnalyzerImagemagickHandler' => array(
                'binary' => '/home/foo/bin/identify'
            ),
        )
    );
    $image = new ezcImageAnalyzer( 'some/image.jpg' );
Listing 12.3 Initialisierung von ImageMagick als einzigem Handler mit vorgegebenem Pfad In diesem Beispiel wird ein neues Einstellungs-Array definiert und gesetzt, statt dazu zunächst die Default-Konfiguration anzufragen und diese zu bearbeiten. Da der ezcImageAnalyzerPhpHandler in diesem Array nicht auftaucht, ist er bei der ersten Benutzung der ezcImageAnalyzer-Klasse dieser nicht bekannt und wird somit nicht verwendet. Selbst auf die Verfügbarkeitsprüfung verzichtet ezcImageAnalyzer, da die Hauptklasse kein Wissen über die Existenz dieses Handlers hat. Die Prüfung auf Verfügbarkeit des konfigurierten ezcImageAnalyzerImagemagickHandler läuft ebenfalls schneller ab als in der Standardkonfiguration: Lediglich die Existenz und Ausführbarkeit der angegebenen Programmdatei werden überprüft. Die Handler-Konfiguration des Bildanalysierers enthält daneben die Möglichkeit, Prioritäten für die zu verwendenden Handler-Klassen zu vergeben. Erhält die Komponente ein Bild als Eingabe, so werden die Handler, also solche, die bekannt und als verfügbar markiert sind, der Reihe nach befragt, ob sie die Datei analysieren können. Der erste Handler, der dazu in der Lage ist, wird verwendet. Die Reihenfolge der Befragung entspricht der Reihenfolge der Einträge im Konfigurations-Array. Es ist also sinnvoll, die Handler nach verschiedenen Kriterien zu sortieren, wie zum Beispiel nach der Zugriffsgeschwindigkeit, was standardmäßig auch der Fall ist: Der PHP-Handler wird vor dem ImageMagick-Handler definiert. Zwar ist das ImageMagick-Paket in der Lage, wesentlich mehr Dateiformate zu analysieren, der Zugriff über den PHP-Handler ist aber eindeutig schneller, da kein Umweg über die Konsole erfolgen muss. Letzterer bringt entsprechende Startzeiten für den neu zu erzeugenden Prozess sowie Zeit- und Speicherverlust bei Kopieroperationen mit sich. Mit dieser Reihenfolge wird also in der Konfiguration sichergestellt, dass bei einem idealen System, in dem sowohl der PHP-Handler als auch die ImageMagick-Variante funktionieren, für die gängigsten Formate der schnelle PHP-Handler verfügbar ist, und für seltenere Exemplare dagegen ImageMagick bereitsteht. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück | <top> | vor >>
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchempfehlungen
| PHP 5.3 und MySQL 5.1
| Besser PHP programmieren
| Webshops mit Magento
| Sichere Webanwendungen
| PHP 5.3 und MySQL 5.1 - Videotraining
| Apache 2
| Suchmaschinen- Optimierung für Webentwickler
| Joomla! 1.5
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de