Projektbeschreibung 1 Inhaltsverzeichnis Das Projekt Projektbeschreibung 1 Vorverarbeitung der Daten 3 Die View der SOM-Plugin 8 Hierarchische SOM 12 Lernalgorithmus SOM 15 SOM Begriffserklärung 19 Edge-Histogramm 24 Farb-Kontexte 29 Projektbeschreibung Ziel des Projekts ist ein digitales Archiv, in dem ein- und mehrmediale Daten eingebettet, sortiert und gefunden werden. Innerhalb dieses Archivs werden SOM-Algorithmen für die Sortierung und Navigation getestet. Die SOM-Algorithmen besitzen drei Merkmale: sie finden Ähnlichkeiten zwischen Daten, clustern sie demnach und ordnen sie topologisch, also in Form einer Karte, an. Diese drei Eigenschaften bilden den roten Faden für das Projekt. Das Projekt soll Grundlagen schaffen. Da sich die SOM nicht mehr als geeignetes Werkzeug beweisen müssen, liegt der Schwerpunkt auf der Verarbeitung mehrmedialer Datenformate. Die Projektgruppe kann es nicht leisten, spezielle Verfahren und Architekturen für den SOM-Algorithmus zu entwickeln, die mehrmediale Datenformate auf gänzlich neuartige Weise verarbeiten. Es können aber Lücken in aktuellen SOM- Projekten gefüllt und Ansätze formuliert und in begrenzten Rahmen getestet werden. Darüber hinaus wird das Problem der Mehrmedialität durch die Struktur des Archivs, des Programms selber, behandelt. Das Archiv ist als Framework konzipiert, das sich an den oben genannten Eigenschaften orientiert. Der SOM-Algorithmus und auch andere Algorithmen erweitern in Form von Plugins die Fähigkeiten dieses Frameworks. Die Plugins sollen weitgehend automatisch funktionieren. Durch das Framework ist das Programm erweiterbar und stellt eine Grundlage für eine Fortsetzung und Spezialisierung dar. Das Projekt besteht aus zwei Teilen: Entwicklung eines Frameworks und Entwicklung geeigneter SO M-Algorithmen in Form von Plugins für das Framework.
2 Projektbeschreibung Zugang für den Anwender In dem Archiv befinden sich Daten verschiedener Medien, z.b. Bilder, Texte oder auch gemischte Formate (DTP-Formate). Aus den Daten werden im System Instanzen erzeugt und nach ihrem Medium sortiert. Bilder-Instanzen aus PDFs z.b kommen zu Bilder-Instanzen aus Bildern etc. Alle Instanzen eines Mediums werden unter einem bestimten Kontext, z.b. Farbe, in eine Hierarchie angeordnet. Bei der Hierarchie werden sich die Kinder immer (farb-) ähnlicher je tiefer man in den Baum navigiert. Es kann mehrere Kontext-Plugins für Bilder geben, es können auch Kontext-Plugins Text und Bild in eine Hierarchie verknüpfen. Es muss nur eine bestimmte Konvention über die Struktur der Ausgabe in xml eingehalten werden, damit die grafische Oberfläche den Baum darstellen kann. Eine Bild-Instanz ist so über die Kontext- Bäume mit vielen anderen Bilder-Instanzen verknüpft. Bei einem PDF stünde es sogar noch mit Text-Instanzen in Verbindung und anderen Bilder-Istanzen. Diese Verknüpfungen bilden die Grundlage für den Zugang des Benutzers zu den Daten. Kontexte Die Kontexte sind abhängig von den Medien, die der Benutzer angegeben hat. Es gibt Kontexte, die eine topologische Anordnung der Kinder eines Vaters ermöglichen, wie z.b. bei der SOM. Die SOM wird als Algorithmus zum Sortieren und zum Aufbau der Hierarchie in diesem Projekt genutzt. Es wäre aber auch ein klassischer k-means möglich oder ähnliche (nicht Vektor-basierte). Es sind Kontexte für Bilder implementiert, speziell für die Farb-Verteilung und die Kanten-Häufigkeit. Startpunktsuche Das Archiv benutzt für die Strukturierung Ähnlichkeit von Daten. Ähnlichkeit impliziert einen Vergleich. Das bedeutet ein Benutzer muss am Anfang bereits eine geeignete Instanz finden können, mit der verglichen wird und die Informationssuche beginnt. Es wird also eine Startpunktsuche benötigt, z.b. eine explorative Suche über die Cluster/Hierarchie. Dabei wird der Benutzer vom Großen zum Kleinen geleitet. Die Daten sind in jedem Kontext hierarchisch strukturiert. Der Benutzer beginnt auf der obersten Ebene und navigiert an Hand von Beispiel-Instanzen (Prototypen) aus den jeweiligen Clustern nach unten. Die Prototypen-Suche funktioniert nur innerhalb einem Medium und einem Kontext. Navigation Die Navigation folgt dem Prinzip des Vergleichs einer aktuell betrachteten Instanz oder Clusters mit ähnlichen Nachbar-Instanzen oder Clustern. Die Herausforderung besteht in der Kombination mehrerer Netze (möglicher unterschiedlicher Medien) und der Topologie-Option. Wichtig ist, dass der Wechsel der Kontexte immer möglich ist. Der Benutzer kann auch den Bereich der betrachteten Nachbarn einstellen und auf das Cluster-Niveau, bzw. in der Hierarchie aufwärts navigieren. Die Instanz ist durch ihre Quelldatei möglicherweise mit anderen Medien und Kontexten verbunden. Der Benutzer kann von der Instanz über die Quelldatei auf eine andere Instanz eines anderen Mediums wechseln. Letzteres ist nicht impementiert.
Projektbeschreibung 3 Die Vorverarbeitung der Daten- Preprocessing Das Preprocessing bereitet die Daten im Archiv so vor, dass der Benutzer mit den für ihn wichtigen Informationen versorgt wird, seine Aktivitäten ausführen und nach angegebener Weise navigieren kann. Das System soll von einem Administrator erweiterbar und individualisierbar sein. Daher werden Plugins benutzt, die die Fähigkeiten des Frameworks verbessern. Das eigentliche Framework bietet nur die nötige Infrastruktur um Plugins und Daten einzubinden. Das Preprocessing wird in Java implementiert. Plugins Die Plugins verarbeiten die eingefügten Daten. Sie untersuchen die Daten auf Ähnlichkeit, erstellen Hierarchien und ordnen sie (unter Umständen) topologisch an. Dabei können sie auch die gleichen Daten benutzen, wenn sie die Ähnlichkeit zu unterschiedlichen Kontexten herstellen. Die Daten müssen dabei für die sortierenden Algorithmen vorverarbeitet werden. Um Redundanz zu verhindern wird die Vorverarbeitung der Daten von der Sortierung getrennt. Es gibt demnach Parser-Plugins und Kontext-Plugins. Die Plugins sollten ohne Veränderung des Codes eingebunden werden können. Die Kontext-Plugins stehen in Abhängigkeit zu den Parsern, da diese die benötigten Informationen generieren. Falls ein Kontext-Plugin sehr exotische Informationen braucht, so kann es notwendig sein einen Parser zu implementieren, der nur diesem Plugin nutzt. Die Parser teilen sich ebenfalls nochmals in zwei Gruppen, die einen Parser produzieren die Instanzen für die Suche mit der GUI und die anderen erzeugen aus den Instanzen für die Kontext-Plugins spezialisierte Daten. daher gibt es: Source-Parser und Instance-Parser. Für die Kommunikation von System und Plugins muss eine einheitliche Kommunikationsform definiert werden. Es gibt für den Datenfluss Komponenten des Frameworks ein Protokoll (Kommunikations-Ob jekt). Die Daten werden in der Vorverarbeitung in bestimmte Medien einsortiert. Das kann Bild, Text oder Audio sein.
4 Projektbeschreibung Die Medien bilden die erste Selektierungshilfe für den späteren Benutzer. Um die Darstellung der Medien-Instanzen im GUI zu vereinfachen, werden sie in gängigen Formaten im database Ordner abgespeichert z.b. als JPG. Für die Algorithmen der Kontext- Plugins ist es oft notwendig die Medien-Formate nochmals zu parsen, um z.b. Bilder im HSV-Farbmodell zu erhalten. Es entstehen genormte Datentypen. Die Daten der genormten Datentypen werden durch die Instanzparser erzeugt und ebenfalls gespeichert. Für einen effektiven Zugang zu den Quelldaten, den genormten Daten und deren Metainformationen wird eine Datenbank genutzt. Um einem Adminisnistrator des Systems das Einpflegen neuer Plugins zu erleichtern werden die Informationen zu vorhandenen Plugins und von ihnen erzeugten Daten in einem meta.xml gespeichert und in einem (noch rudimentären) Admin-GUI dargestellt. Dieses xml definiert auch die erforderliche Ordnerstruktur, um die Konsistenz der Datenbank und das dynamische Einbinden neuer Klassen zu garantieren. Die Ordnerstruktur sieht folgendermaßen aus: SOMProjekt database kontextdescriptions instances sources guimeta.xml source1 (dtp) medium1 (image) medium2 (text) source2 (image) medium1 (image) delivarables (class Dateien) libraries (alle jars) newsource source (java Dateien) meta.xml log.txt In database werden die eingepflegten Daten gespeichert, geordnet nach Quell-Kategorien, z.b. DTP oder Image. In den jeweiligen Ordner liegen die von den Source-Parsern erzeugten Medien-Instanzen in Unterordnern. Die Verarbeitung und die Darstellung der Daten sind getrennt. Außerdem erzeugen viele Kontext-Module Ausgaben, die sich auf Grund unterschiedlicher Algorithmen auch unterscheiden würden. Daher ist es sinnvoll die Ausgaben der Kontext-Plugins ebenfalls zu normieren. Das geschieht durch eine genormte Kontext-Beschreibungen. Diese wird im Ordner kontextdescriptions auf mehreren xmls verteilt abgespeichert. Die xmls beinhalten alle Daten, die die GUI braucht, um Navigation und Darstellung zu ermöglichen. Es ist kein Zugriff auf die Datenbank nötig. Die xmls sind: guimeta.xml- beschreibt alle Kontext-Plugins (wird automatisch erzeugt). Für jedes Kontext-Plugin wird eine kontexpluginname.xml (z.b. ColorHisto.xml) erzeugt, die die eigentliche hierarchische Anordnung definiert. Für jeden Quelldatentyp (z.b. DTP oder Image) eine quelltypsource.xml (z.b. dtpsource.xml). Für jedes Medium eine instancemedium.xml (z.b. instanceimage. xml). Architektur und Verlauf Die Applikation Preprocessing durchläuft mehrere Zustände: Aufbau der Applikation, Einbinden neuer Daten, Parsen neuer Daten, Kontexte erzeugen, Daten in Datenbank eintragen, xmls für die GUI erzeugen.
Projektbeschreibung 5 Die einzelnen Aufgaben werden von Manager-Objekten übernommen: InitManager, SourceManager, ParserManager, KontextManager, XMLManager. Dadurch wird auch die Architektur bestimmt. Ein Verwaltungsobjekt (Switch), das auch das JFrame für die Admin-GUI erzeugt, aktiviert die Manager und gibt Informationen von einem Manager zum anderen weiter. Die Plugins werden vom User explizit in der Admin-GUI aktiviert. Es ist auch möglich alles automatisch ablaufen zu lassen. Dabei werden alle Daten mit allen Plugins getetstet, was aber zu Speicherproblemen führt. Die eingegeben Daten werden von den Parsern selber nochmals geprüft, ob sie sie verwenden können. Wenn nicht, dann geht nur ein leeres Protocol-Objekt zurück, keine Exception. Ein Parser oder Kontext-Plugin kann mehre Datenarten akzeptieren, z.b. Bild und Text. Programmiersprache und Tools Es wurde Java (Eclipse und Poseidon) für das Preprocessing und Flash für das GUI benutzt. Für die Datenbankanbindung wird jdbc benutzt für die Datenbank selber mysql. Init-Manager Switch Admin gibt Datenpfade an initiiert Zustand 1 initiiert Zustand 2 initiiert Zustand 3 Source- Manager Parser-Manager Parser- Plugin Kontext-Plugin- Manager Kontext- Plugin Rohdaten genormte Daten Kontext- Beschreibungen Protokoll Datenbank xml-dateien XML-Manager Kontext-Beschreibungen Grafische Schnittstelle interagiert Anwender Grobes Objektmodell
6 Projektbeschreibung Init-Manager Prüfen der Pfadstruktur, Einbinden aller Plugins an Hand der meta.xml. Source-Manager Einbinden der Quell-Daten in die Datenbank als SourceData Objekte mit Metainfos. Parser-Manager Admin wählt Source-Parser für die Quell-Daten. Entsprechende SourceDatas werden in Instance-Objekte umgeformt und in einem einheitlichen Format gespeichert (jpg) und mit Verweis auf die Quell-Datei in die DB übertragen. Die Instance-Parser werden automatisch gestartet. Die entstandenen NormedDatas werdenabgespeichert und in die DB übertragen. Kontext-Manager Der Admin wählt ein Kontext- Plugin. Die View des Plugins wird aufgebaut. Die vom User akzeptierte Ausgabe wird als xml abgespeichert. GUI Die GUI liest die xmls zu den Instanzen, den Quell-Dateien ein und stellt die Hierarchien dar.
Projektbeschreibung 7 Was umgesetzt wurde Das Framework ist funktionsfähig programmiert. Es fehlen noch eine gute Exceptionund Fehlerbehandlung (mit dem log.txt z.b.), die dynamische Einbindung neuer Plugins mit ClassLoader und ein erweitertes Wartungs-GUI zum Einbinden neuer Daten und Aktivierung der Plugins (zu finden unter Implementation/SOMProjekt). Es besteht ein beschränkt funktionsfähiges Wartungs-GUI in Java. Desweiteren eine hierarchische SOM Implementation (plugins.kontextplugins.sommodul) und mehrere Kontext-Plugins, die eine hierarchische SOM mit den Eigenschaften Farbe und Kantenverteilung von Bildern erstellen. Jedes Kontext-Plugin ist über eine View in der Wartungs-GUI steuerbar. Die Daten für die Kontext-Plugins werden von einem ImageIOParser (nutzt das java interne ImageIO-Objekt) und ein PDF-Parser (nutzt das C-Programm pdftohtml). Die Texte aus den PDFs werden nicht weiter genutzt und liegenals plain-texte im text-ordner der DTP- Kategorie. Die Datei zum Anlegen der Tables für das Preprocessing liegen im Ordner Feinentwurf/Datenbank. Ein vollständiges uml-dokument (Poseidon) liegt im Ordner Feinentwurf/uml. Die KontextDescriptions werden von einem Flash-GUI eingelesen und die hierarchischen Strukturen dargestellt. Das GUI stellt nur den Gedanken dar, mit dem durch die Hierarchien navigiert werden könnte, also ein funktionsfähiger Prototyp (zu finden unter GUI/gui/gui.swf). Das Framework ist nicht mehrmedial einsetzbar, da nur Kontext-Plugins für Bilder vorhanden sind. Es liegt eine API für die Java-Programmierung vor: Implementation/doc SOM und Testdaten Die hierarchischen SOM-Plugins behandeln nur Bilder. Um den Erfolg der Plugins abschätzen zu können haben wir 3 Hauptklassen gebildet, die wiederrum unterteilt sind: Fotos Architektur Landschaft Menschen künstliche, gegenständliche Bilder 3D-Renderings Comics Grafiken Diagramme Graphen techische Zeichnungen Die Testdaten liegen im Ordner Testdaten. Starten des Preprocessings Implementation/SomProjekt/run.bat oder unter eclipse. Einbinden neuer Daten In den Ordner newsource können pdf, jpg, png und tif Dateien abgelegt und über das Java-GUI in die Datenbank übertragen werden. Dazu kann die Datenbank vorher gelöscht werden via erase Database. Die Daten werden über infuse Source eingelesen. Durch Auswahl eines Parsers und Parse Data werden die Daten geparst, erst dann sind sie für die Kontext-Module nutzbar. Danach sollten die Dateien wieder aus dem Ordner entfernt werden, weil erneutes Einlesen gleicher Daten vom System nicht erkannt wird. Wenn ein Kontext-Modul ausgewählt wurde kann es durch Start Plugin mit seinen Daten gefüttert und gestartet werden. Durch Accept Result wird das Ergebnis des Kon-
8 Projektbeschreibung text-moduls übernommen und eine entsprechende Kontext-Plugin-xml geschrieben. Einbinden neuer Plugins Neue Plugins müssen derzeit noch im Init- Manager unter addkontext() für KontextModule und unter addsourceparser() oder addinstanceparser() hart eingetragen werden. Darüber hinaus muss die meta.xml um das Plugin erweitert werden. Für ein Kontext-Plugin: Ein package im Verzeichnis plugins.kontextplugins mit deim Packagenamen, der in die xml eingetragen ist. Die Klasse, die vom InitManager erzeugt wird muss die Klasse KontextPlugin beerben. Alles weitere in den Docs von KontextPlugin. Für einen Parser: Ein package in plugins.parsers. Je nach Parser Art muss InstanceParser oder Source- Parser beerbt werden. Alles weitere in den Docs. Möglichkeit vorandene Plugins zu nutzen Das implementierte HSOM kann weiterverwendet werden. Dazu kann die SomModul Klasse in projectlogic.plugins.kontextplugins. sommodul beerbt werden. Es wird nur ein Vektorisierungs-Objekt verlangt, dass das Interface Vectorizer implementiert. Der Vectorizer erhält alle Daten, die das Kontext-Plugin akzeptiert und verwandelt sie in Vektoren. Der ErrorManager ermöglicht es Nachrichten vom Plugin aus in das log.txt zu schreiben. Die View der SOM-Plugins Die Admin-View Ergebnis Das Projekt konnte leider nicht das Problem der Mehrmedialität befriedigend behandeln. Dazu fehlt noch ein Kontext-Plugin, dass z.b. Text verarbeitet. Dadurch könnten z.b. PDF-Dokumente mehrmedial zugänglich gemacht werden. Der Versuch mehrere Algorithmenformen zu zulassen, die Daten in hierarchische Cluster einordnen, egal ob mit Vektoren, topologisch oder nicht, konnte auch nicht getestet werden, da nur SOM-Algorithmen vorliegen. Die SOM-Algorithmen sind in jedem Fall ein sehr leicht zugängliches Werkzeug und bieten viel Raum für Spielereien. Entscheidend sind die Vektorisierungen der Daten. Hier ist nach wie vor noch großer Bedarf, was Ideen zur Informationsextraxtion angeht und der Berücksichtigung des Anwendungsfalls für den die SOM-Sortierung vorgenommen wird. Vor allem für das EdgeHistogramm lassen sich viele Ansätze zur Verbesserungen finden. Der Konstruktor sollte wie folgt aussehen: public class NewModul extends SomModul { public NewModul (ErrorManager manager) { super(manager, vectorizer); } }
Die View der SOM-Plugins 9 Beschreibung zum Admin Panel
10 Projektbeschreibung Beschreibung zum SOM Panel
12 Hierarchische SOM Hierarchische SOM Einleitung Hierarchische SOMs basieren auf der Benutzung einzelner Karten, die nicht unabhängig voneinander und in einer hierarchischen Form einer Pyramide organisiert sind. Die zugrundeliegende Idee hierbei ist die Reduzierung des Berechnungsaufwands beim Training des Netzes durch die Verteilung der Anordnung der Cluster auf verschiedene Karten. Architektur Diese Form der SOMs bestehen aus einer Anzahl von Karten, welche die Form einer Pyramide aufweisen. Beginnend auf der höchsten Ebene wird für jeden weiteren Knoten eine neue Karte hinzugefügt. Die Beispielarchitektur in der unteren Abbildung besteht in der ersten Ebene aus einer Karte mit vier Knoten. Jeder Knoten in dieser Karte ist mit einer weiteren 2x2 Karte in der zweiten Ebene verbunden. Jeder Knoten Schematische Darstellung einer Beispielarchitektur
Hierarchische SOM 13 in der zweiten Ebene ist mit einer 3x3 Karte in der dritten Ebene verbunden. Diese Architektur impliziert eine strikte Hierarchie und Nachbarschaftsrelation. Auch in dieser Architektur ist keine dynamische Anpassung der Kartengröße vorgesehen. Die Anzahl der Knoten ist in den oberen Ebenen dieser Architektur weitaus geringer als bei anderen hierarchischen Varianten, welche auch mehrere Ebenen verwenden. Beim Training der Pyramide werden die Eingabevektoren in der Hierarchie komprimiert. Die, besonders auf den höheren Ebenen, auf die gleichen Knoten abgebildeten Vektoren zeigen keine oder nur eine geringe Varianz zueinander und enthalten keine weiteren Informationen für die darunter liegenden Karten. Daher werden diese für das Training der Pyramide nicht gebraucht. Der Trainingsprozess führt dann zu unterschiedlichen Gewichtsvektoren für jede Karte. Während des Trainings der Pyramide ist die Erweiterung durch weitere Ebenen möglich. Trainings- bzw. Lernalgorithmus Das Training erfolgt sequentiell ausgehend von der obersten Ebene der Pyramide. 1. setze Trainingsebene auf n = 0 2. setze momentane Ebene c auf die oberste Ebene 3. wähle beliebigen Eingabevektor mit 4. berechne den Zustand jedes einzelnen Knoten auf der momentanen Karte c in Abhängigkeit zum gewählten Eingabevektor mit Hilfe der Aktivierungsfunktion 5. wähle die Best Matching Unit (BMU) als Gewinner 6. wenn die momentane Ebene kleiner als die Trainingsebene ist, also c < n gilt, dann wähle die nächste darunter liegende Ebene des Gewinners als momentane Ebene c und mache weiter mit Schritt 4 ansonsten, also wenn c = n oder c > n gilt, dann ist die Ebene er reicht, welche trainiert werden soll, also Anpassung der Gewichtsvektoren der BMU und der benachbarten Knoten 7. wiederhole die Schritte 2 bis 6 bis der Trainingsprozess sich der Ebene n nähert 8. wenn die unterste Ebene der Hierarchie nicht erreicht wurde, dann wiederhole den Algorithmus ab dem Schritt 2 mit der folgenden Ebene, also n = n + 1 Der Anpassungsprozess wird auf jede Ebene beginnend mit der obersten Ebene angewendet. Für jede Karte können unterschiedliche Trainingsparameter festgelegt werden. Wenn der Trainingsprozess für alle Karten einer Ebene abgeschlossen ist, dann kann ein neuer Eingabevektor gewählt werden. In jeder Ebene beginnend mit der obersten Ebene wird der Gewinner gesucht, der die geringste Varianz in Bezug auf den Eingabevektor aufweist. So können die richtigen darunter liegenden Karten identifiziert und in Bezug auf den Eingabevektor trainiert werden. Nach der Annährung an eine bestimmte Ebene kann ein bestimmter Fall wiederholt vorkommen, bei dem alle Eingabesignale, welche auf einen bestimmten Knoten abgebildet werden, keine oder nur eine geringe Varianz in Bezug auf einen oder mehrere Eingabevektoren aufweisen. Das sind meist solche Vektoren, welche in der Hierarchie über diesen Knoten absteigen. Diese enthalten keine Informationen über den folgenden spezifischen Baum von Karten und können beim Training der Karte ausgelassen werden. Das Ergebnis sind dann kürzere Gewichtsvektoren für die darunter liegenden Karten. Verschiedene Strategien werden zur Ermittlung der Gewichtsvektorenreduktion angewendet. Angefangen von der Eliminierung der Vektoreingänge mit keiner Varianz bis zur für die Erreichung einer maximalen
14 Hierarchische SOM Genauigkeit dynamischen Berechnung von verschiedenen Grenzwer-ten für jede Karte unter Verwendung der Komponenten der Eingabevektoren. Weiterhin müssen Knoten in den unteren Ebenen, welche nur eine Eingabe abbilden, nicht weiter trainiert werden. Das Gleiche gilt auch für den Fall, wenn die Varianz verschiedener Eingabevektoren, welche auf einem Knoten abgebildet werden, unter einem gewissen Grenzwert bleibt und diese somit als identisch betrachtet werden können und keine weitere Verteilung nötig wird. Beispielsweise wenn keine höhere Auflösung für die Präsentation gebraucht wird. Literatur 1. Andreas Rauber, Hierarchical SOM, 1998 http://www.ifs.tuwien.ac.at/ifs/research/ pub_html/rau_masterth96/node33.html
Lernalgorithmus SOM 15 Lernalgorithmus SOM Eingabevektor aus Einführung Hauptsächlich besteht der Lernalgorithmus von SOMs aus vier Schritten : 1. wähle einen beliebigen Eingabevektor mit aus dem Eingabedatenraum 2. mit Hilfe einer Aktivierungsfunktion wird der Zustand jeder Einheit in Abhängigkeit zum gewählten Eingabevektor berechnet Der Begriff Einheit sei hier für ein einzelnes Neuron der Ausgabeschicht verwendet, dessen Position durch einen entsprechenden Vektor dargestellt wird. 3. wähle die Best Matching Unit (BMU) als Gewinner c 4. berechne die Anpassung des Gewichts vektors der BMU und der Gewichtsvektoren aller Einheiten in der Nachbarschaft an den gewählten Eingabevektor Dieser iterative Prozess führt zu einer topologieerhaltenden Abbildung der Eingabesignale, welche die Menge der Eingabevektoren darstellen, auf einer entsprechenden Karte bis der Lernalgorithmus sich dem Ende nähert. Im Folgenden wird jeder Iterationsprozess mit einem Zeitstempel t bezeichnet, um den Lernprozess algorithmisch zu präsentieren. Erklärungen und Bemerkungen Gegeben ist eine Menge von Eingabesignalen mit 1 k p aus einem beliebigen komplexen Eingaberaum. der Menge der Eingabesignale frei gewählt, wobei jeder Eingabevektor die gleiche Dimension aufweisen muss. Ohne den Algorithmus zu beeinflussen, werden die Eingabevektoren häufig normiert. Mit der Vektorlänge definiert als kann der Eingabevektor durch die zusätzliche Veränderung seiner Komponenten normiert werden. Damit wird der Eingaberaum zu einer n dimensionalen Hyperkugel mit Radius 1 begrenzt. Im zweiten Schritt wird häufig die Euklidische Distanz zwischen dem Eingabevektor und dem zur Einheit i gehörenden Gewichtsvektor als Aktivierungsfunktion verwendet. Die Berechnung des Zustands des zur Einheit i gehörenden Gewichtsvektor in Abhängigkeit zum gewählten Eingabevektor im Iterationsschritt t mit Hilfe des Euklidischen Abstandes wird durch die Formel beschrieben. Eine andere Aktivierungsfunktion stellt das sogenannte Innere Produkt des gewählten Eingabevektors und dem Gewichtsvektor der Einheit i dar und wird durch die Formel, In jedem Iterationsschritt t wird ein
16 Lernalgorithmus SOM beschrieben. Voraussetzung für die Anwendung ist aber ein normalisierter Eingabevektor. Im dritten Schritt wird die Best Matching Unit c als Gewinner gewählt. Wenn der Euklidische Abstand als Aktivierungsfunktion genutzt wird, wird die Einheit als BMU ausgewählt, welche den geringsten Abstand zum Eingabevektor besitzt. Dies drückt sich in der folgenden Formel aus. Matching Unit in Hinblick auf den gleichen Eingabevektor passen wird. Um die Beendigung des Lernprozesses in endlicher Zeit sicherzustellen, muss die Anzahl der Anpassungen hinsichtlich der Iterationsstufen stetig abnehmen. Dies wird durch die geeignete Wahl einer Funktion für die Lernrate erreicht. Diese Funktion muss auf dem abgeschlossenen Intervall [0, 1] monoton fallend sein und am Ende des Lernprozesses Werte nahe oder bei 0 produzieren. Ein Beispiel für eine solche Funktion ist mit > 1 In dem Fall der Anwendung des Inneren Produkts als Aktivierungsfunktion, sollte das folgende Kriterium beachtet werden. Im letzten Schritt ist der Gewichtsvektor der Best Matching Unit c wie auch die Gewichtsvektoren der Einheiten der Nachbarschaft Kandidaten für eine Anpassung, welche von folgenden drei Faktoren bestimmt wird. - Der Lernrate, welche abhängig von der Iterationsstufe t ist. - Der Nachbarschaftsfunktion, welche ein laterales Feedback zwischen der Einheit i und der Best Matching Unit c implementiert. - Dem Unterschied zwischen dem Gewichtsvektor der Einheit i und dem momentan gewählten Eingabevektor. Die Anpassung des Gewichtsvektors hat einen neuen Gewichtsvektor zum Ergebnis, welcher in späteren Iterationsstufen wahrscheinlicher als Best Der Wert beschreibt die frei wählbare Initiierung der Lernrate. Die Erklärungen für die Wahl des Parameters learn und die daraus resultierenden Auswirkungen sollen an dieser Stelle mit Hinweis auf das bessere Verständnis bei einer Erklärung in Bezug auf die Nachbarschaftsfunktion zurückgestellt werden. In Hinblick auf die biologische Funktionsweise von Gehirnen von Säugetieren wird häufig die sogenannte Mexican Hat Funktion als Beschreibung der Reaktion von neuronalen Zellen, dem Zusammenspiel von Sternzellen und Pyramidenzellen, auf einen Reiz gewählt. Die sogenannte laterale Inhibition umschreibt dabei die Umfeldhemmung, welche entsteht wenn die von einer Einheit, gemeint ist dabei die Best Matching Unit, ausgehende Erregung oder Reaktion der umliegenden Einheiten, von weiteren Einheiten im weiter entfernten Umfeld gehemmt wird. Dabei existiert im Zentrum der Stimulierung ein kleiner Bereich der Stimulierung, gefolgt von einem Bereich von gehemmter Aktivität. Danach folgt dann ein Bereich der Erregung, welche dann nur noch sehr schwach ausgeprägt ist.
Lernalgorithmus SOM 17 Mexican Hat Funktion Für die Implementierung dieser Reaktion wird eine skalare Funktion definiert, welche die Nachbarschaft der BMU c beschreibt. Das zeigt auch den größten Unterschied zum Winner Takes All Prinzip. Diese Funktion kann explizit als eine Menge von Einheiten definiert werden, welche in einem spezifischen Bereich um den Gewinner liegen. Dieser Bereich kann die Form eines Kreises oder Rechteckes besitzen. Der Radius des Bereichs wird auch als Blase der Aktivität bezeichnet und umfasst am Anfang des Lernprozesses die gesamte Karte. Mit jeder Iterationsstufe wird diese Blase kleiner, bis am Ende nur noch der Gewichtsvektor des Gewinners für die Modifizierung übrig bleibt. Aus Gründen der Vereinfachung wird manchmal nur der primäre Bereich der Erregungsaktivität implementiert. Für diesen Fall ist die folgende Äquivalenz für alle Einheiten i anwendbar, welche in der spezifizierten Nachbarschaftsumgebung liegen. Die folgende deskriptive Form der Definition von ist ähnlich zur Definition einer Aktivitätsblase. Wobei folgendes gilt : und das Verhältnis zwischen Stimulierungsaktivität und Hemmungsaktivität definiert den Radius des Bereiches im Ausgaberaum Die Einheiten welche in der nahen Umgebung des Gewinners liegen, werden durch den positiven Faktor aktiviert.
18 Lernalgorithmus SOM Während den Bereich der gehemmten Aktivität beschreibt. Die Einheiten welche weiter als entfernt sind, werden nicht mehr durch die Reize beeinflusst. Eine andere Möglichkeit der Definition der lateralen Reaktion basiert sowohl auf dem Iterationszyklus t als auch auf die topologische Distanz von jeder Einheit zum Gewinner auf der Grundlage der Abschwächung der Stimulierung und Hemmung mit zunehmender Distanz. Es gibt numerische Funktionen mit diesen Eigenschaften und mit ähnlichen Abstandsdefinitionen wie in der zuletzt beschriebenen Formel über komplexere Beschreibungen wie bei der folgenden Funktion bis hin zur Mexican Hat Funktion. Die folgende Möglichkeit für die Definition von berücksichtigt den Iterationszyklus und die topologische Distanz. In diesem Fall wird die Menge der Reaktionen sowohl durch die Distanzen zwischen dem Gewinner c und den in der Nachbarschaft befindlichen Einheiten i als auch durch den Iterationszyklus bestimmt. mit gilt für BMU Die Sinusfunktion garantiert eine stetige Veränderung der Menge der Reaktionen durch den Parameter, welcher das Verhältnis von Reizung und Hemmung bestimmt, während das Verhalten der Zeitveränderung garantiert und am Ende mit der monoton fallende Eigenschaft gegen 0 konvergiert. Die folgende von der Eigenschaft her auch monoton fallende Funktion ist wie die schon verwendete Lernfunktion aufgebaut. Auch diese Funktion berücksichtigt die Distanz und den Iterationszyklus t, doch nicht die laterale Inhibition wie in der Mexican Hat Funktion. mit mit Wieder bezeichnet Nachbarschaftsbereichs. den Anfang des Die Bedeutung der beiden Parameter learn in der Lernfunktion und neighbor in der gerade beschriebenen Nachbarschaftsfunktion ist von einer wichtigen Bedeutung. In der Quelle auf der dieser Bericht aufbaut, werden diese Parameter in Abhängigkeit von den Dimensionen der Karte initialisiert. Die Auswahl der Exponenten reduziert die Nachbarschaftsrate schneller als die Lernrate. Anders ausgedrückt, die Nachbarschaftsfunktion ist durch die Wahl dieses Parameters stärker monoton fallend als die Lernfunktion. Numerische Simulationen zeigten, dass diese Strategie bessere Ergebnisse aufweist als bei der gleichen Wahl der Exponenten der beiden Parameter. Literatur 1. Andreas Rauber, The Learning-Algorithm, 1998 http://www.ifs.tuwien.ac.at/ifs/research/ pub_html/rau_masterth96/node13.html 2. Manfred Nölte, Laterale Inhibition, 1997 http://home.zait.uni-bremen.de/~mn/old/ glossar/g/node159.html
SOM Begriffserklärung 19 SOM Begriffklärung Einführung Die Abkürzung SOM steht für Self-Organizing-Map. Diese sogenannten selbstorganisierenden Karten stellen ein spezielles neuronales Netz dar, bei denen das Training oder Lernen ohne externe Kontrolle, wie es bei einem Perzeptron nötig wäre, auskommt. Aufgrund dieser Eigenschaft ist die netzeigene autonome Organisation gewährleistet. Eine weitere wichtige Eigenschaft besteht in der festgelegten räumlichen Anordnung der Neuronen des Netzes. Eine SOM erstellt aus Eingaben eine topographische Karte, wobei der Grad der Ähnlichkeit dieser Eingaben direkte Auswirkung auf die räumliche Nutzung der vorhandenen Neuronen hat. Dadurch werden ähnliche Eingabemuster in einer SOM auch räumlich äquivalent dargestellt. Architektur Die Architektur einer SOM besteht aus der Eingabeschicht und der Ausgabeschicht. Beide Schichten bestehen aus einer endlichen Menge an Neuronen. Die Neuronen der Eingabeschicht sind jeweils voll mit den Neuronen der Ausgabeschicht verbunden. Die Verbindungen zwischen den Schichten sind durch spezifische Gewichte gekennzeichnet. Die angesprochene räumliche Anordnung der Neuronen der Ausgabeschicht, und nur in dieser Schicht ist diese räumliche Anordnung von Bedeutung, ist während der Lernphase besonders wichtig und wird durch nicht veränderbare Koordinatenvektoren jedes einzelnen Neurons bestimmt. Architektur einer SOM SOM Algorithmus Jedes Neuron der Eingabeschicht schickt über die vorhandene Verbindung zu den Neuronen der Ausgabeschicht einen Eingabewert. Die Menge der Eingabewerte werden in einem sogenannten Eingabevektor zusammen gefasst. Die Menge aller Gewichte, welche die Verbindungen der Neuronen zwischen den Schichten kennzeichnen, werden in einem sogenannten Gewichtsvektor zusammen gefasst und bestimmen die Netzstruktur der SOM. Für jedes Eingabemuster wird nun die Ähnlichkeit zu jedem Gewichtsvektor der Verbindungen zwischen den Ebenen be-wertet. Dabei wird ein sogenanntes Sieger-neuron bzw. Prototyp bestimmt, welches die Eingabe von allen Neuronen der Ausgabeschicht am besten repräsentiert.
20 SOM Begriffserklärung Wichtigkeit ist. Die sogenannte Lernrate wird mit jeder Epoche, die den Zeitraum umschreibt bis alle Eingabemuster einmal präsentiert worden sind, sukzessive verkleinert. Dabei wird der Lernfortschritt der SOM bis zum Ende der Epoche im Verlauf des Trainings verringert. Das Ende des Trainings ist erreicht, wenn die Lernrate 0 erreicht hat oder eine angegebene Abbruchbedingung erfüllt ist. Prototypen mit Topologieerhaltung Als eine Möglichkeit der Bewertung einer Ähnlichkeit bezüglich der Gewichtsvektoren kann jeweils die minimale Euklidische Distanz, also die Entfernung zwischen dem Eingabevektor und dem Gewichtsvektor dienen. Diese Möglichkeit findet auch am meisten Verwendung. Eine weitere Möglichkeit zur Bestimmung des Siegerneurons bzw. des Prototypen ist jeweils das maximale Skalarprodukt des Eingabevektors und des Gewichtsvektors. Sollte der Fall eintreten, dass zwei Gewichtsvektoren die gleiche euklidische Distanz zum zugehörigen Eingabevektor aufweisen, dann wird entweder zufällig oder ein beliebiger Vektor aus dieser Gruppe gewählt und dessen Neuron als Sieger bestimmt. Nach der erfolgreichen Bestimmung des Siegerneurons bzw. des Prototypen wird die Ausgabe dieses Neurons auf 1, die aller anderen Neuronen der Ausgabeschicht auf 0 gesetzt. Das eigentliche Training beginnt mit der Anpassung der Gewichtsvektoren des Siegerneurons und der Gewichtsvektoren seiner umliegenden Neuronen an den Eingabevektor durch eine Lernvorschrift, wobei der Grad der Nachbarschaft von größter Durch die Kombination verschiedener Funktionen, wie der Nachbarschaftsfunktion und der Lernratenfunktion, werden auch Neuronen der Ausgabeschicht in der unmittelbaren Nachbarschaft des Siegerneurons in den Lernprozess einbezogen. Dadurch wird die Topologie, die benachbarte Anordnung ähnlicher Eingabewerte erhalten. Die Nachbarschaftsfunktion berechnet den Grad der Nachbarschaft eines Neurons der Ausgabeschicht zum Siegerneuron. Diese Funktion, dessen Werte zwischen 0 und 1 liegen, ist abhängig von den Werten einer Distanz und Radiusfunktion, welche beruhend auf der euklidischen Norm wiederum den Abstand der Neuronen der Ausgabeschicht zum Siegerneuron bestimmt. Für das Siegerneuron ist der Wert der Radiusfunktion also 0. Beispiele für Nachbarschaftsfunktionen ist die Rechteckfunktion, bei der alle Neuronen der Ausgabeschicht in der unmittelbaren Nachbarschaft des Siegerneurons den Grad 1 erhalten, während die Gewichte der übrigen Neuronen keine Veränderung erfahren, sowie die Gauß sche Glockenkurve und die Mexican Hut Funktion. Da im Laufe des Trainings nach jedem Eingabemuster der Einflussbereich des Siegerneurons abnehmen soll, wird eine monoton fallende Distanzfunktion benötigt. Dies ist sinnvoll, da sich die Karte so besser entfalten kann und schneller konvergiert. Beispiele für solche Funktionen ist die lineare und die exponentielle Distanzfunk
SOM Begriffserklärung 21 tion sowie die Wurzeldistanzfunktion. Die Ergebnisse der Radius- und Distanzfunktion werden der Nachbarschaftsfunktion als Parameter übergeben. Die Ergebnisse dieser Funktion bestimmen dann den Grad der Anpassung der Gewichte der Neuronen der Ausgabeschicht. Die Lernratenfunktion verhält sich ähnlich zur Distanzfunktion. Für den Lernalgorithmus müssen zwei verschiedene Lernmethoden unterschieden werden. Beim am häufigsten verwendeten musterweisen Lernen erfolgt die Adaption der Gewichtsvektoren nach jedem Eingabemuster, das an die Eingabeschicht angelegt wurde. Beim epochenweisen Lernen erfolgt die Gewichtsanpassung erst nach Durchlaufen einer kompletten Epoche, also nach Eingabe aller vorhandenen Eingabemuster. Algorithmus des musterweisen Lernens 1. Initialisierung der Verbindungsgewichte zwischen der Eingabeschicht und der Ausgabeschicht 2. Bestimmung des Siegerneurons für jedes Eingabemuster 3. Bestimmung des Nachbarschaftsgrades zum Siegerneuron für jedes Neuron der Ausgabeschicht während der Epoche 4. Anpassung der Gewichtsvektoren der betreffenden Neuronen der Ausgabeschicht 5. Wenn Abbruchbedingung erfüllt, wie beispielsweise die Epochenzahl, dann Abbruch des Trainings. Wenn Abbruchbedingung nicht erfüllt, dann Iteration der Epochenzahl und Weiterführung des Algorithmus bei Schritt 2. Danach muss eine angemessene Neuronenzahl festgelegt werden, wobei die Dimension der Eingabedaten gleich der Anzahl der Neuronen der Eingabeschicht ist, während die Anzahl der Neuronen der Ausgabeschicht zu diesem Zeitpunkt noch unbekannt ist. Das Problem der unbekannten Anzahl der Neuronen der Ausgabeschicht umgeht ein der SOM verwandtes neuronales Netz. Die Growing Cell Structures haben die Fähigkeit während des Trainings neue Neuronen zu bilden bzw. alte Neuronen zu entfernen. Literatur 1. Technische Anwendungen von Selbstorganisierenden Karten, Universität Passau; http://lrs2.fmi.uni-passau.de/online/ SOM/index.html 2. Selbstorganisierende Karten, Jochen Weiß, 27. Mai 2004, Universität Ulm, Bemerkungen Bevor die SOM trainiert werden kann, ist es von eminenter Wichtigkeit, die Eingabedaten geeignet aufzubereiten, also passend zu kodieren.
22 SOM Begriffserklärung Implementierte H-SOM Innerhalb des Projekts wurde eine hierarchische SOM implementiert mit einer rechteeckigen Karte. Der hierarchie-algorithmus wurde vereinfacht. so wird die oberste Ebene mit allen Eingabe-Vektoren vollständig trainiert. Danach werden die Eingabe-Vektoren auf ihre BMUs verteilt. Jedes BMU besitzt wiederum eine SOM-Karte, die nächst tiefere Ebene in der Hierarchie. wenn alle Vektoren verteilt sind werden alle SOM-Karten der BMU mit ihren Eingabe Vektoren trainiert. Dies wiederholt sich, bis kein BMU auf eine SOM-Karte mehr verweist, also die unterste Ebene erreicht wurde. Dieser Algorithmus ist zeitaufwendiger, aber simpler, als der oben diskutierte. Für die SOM liegen zwei Lernratenfunktionen (euklidisch und linear) und drei Nachbarschaftsfunktionen (euklidisch, gauss, mexican hat) vor. Für jede Ebene kann im java-gui des Kontext-Plugins ein eigener Satz Parameter definiert werden. Alle Kontexte des Projekts nutzen den gleichen H-SOM-Algorithmus. Probleme Das Kontext-GUI ist noch sehr rudimentär. Die Eingabemöglichkeiten müssen noch erklärt werden und die Ergebnis-Karte sollte sich noch an die Größe des Fensters anpassen. Die implementierte SOM ist sehr spezifisch. Sie ist nicht ohne weiteres durch z.b. growingcell-structure oder eine Hexakarte erweiterbar. Packages hsom hsom.jsom
24 Edge-Histogramm Kontexte Edge-Histogramm Das Edge-Histogramm codiert die räumliche Anordung von Kanten innerhalb eines Bildes. Da bei der Verarbeitung das Bild in ein 4x4-Raster aufgeteilt wird und diese Teilbilder dann tiefergehend aber einzeln weiter untersucht werden und die Anzahl bestimmter Kantenarten ermittelt wird, kann der Algorithmus mit unterschiedlichen Bildgrößen/Auflösungen zusammenarbeiten. Der Algorithmus Das Bild wird über das 4x4-Raster in 16 Teilbilder (sog. Subimages) unterteilt. dürfen. Das bedeutet, daß Ursprungsbild muß bereits vor der Aufteilung in die 16 Subimages so beschnitten werden, daß die Pixelanzahl (in Höhe und Breite) durch 4 teilbar ist (wegen der Subimages) und die Subimages wiederum durch die Größe der Blöcke. Die Blöcke müssen sich in ein 2x2-Raster teilen lassen, wobei die feinste Stufe 2x2- pixel große Blöcke wären. Diese werden dann auf Kanten überprüft. Es gibt 5 Typen von Kanten. Die Blöcke sind entweder 2x2-Pixel groß so daß sie direkt anhand der 4 Pixel auf Kanten untersucht werden können, oder sie werden in ein 2x2-Raster geteilt und die Untersuchung auf Kanten geschieht anhand der ermittelten durchschnittlichen Helligkeit pro Rasterfläche. Insgesamt gibt es 4² = 16 unterschiedliche Anordnungen der Rasterflächen, wovon aber nur 14 auf die 5 Kantenarten verteilt werden, da Blöcke mit monotoner Farbe nicht in der Zählung berücksichtigt werden. Aufteilung in 16 Subimages Jedes Subimage wird nun einzeln untersucht. Dafür wird es in eine feste Anzahl Blöcke aufgeteilt, die sich nicht überlappen Zum Untersuchen auf Helligkeit eignet sich der HSV-Farbraum (auch HIS oder HSB abgekürzt) (Hue; Saturation; Value Brightness Intensity) am besten, da es hier sehr einfach möglich ist, nur den Helligkeitwert (Value) zu betrachten. Das Bild wird dabei faktisch in ein Schwarzweiß-Bild umgewandelt. Der V-Wert wird in Prozent zwischen 0 und 100 angegeben. Der Farbraum wird häufig als Kegel dargestellt, wobei die Farbtöne (Hue) so in Kantenarten: a) vertikal b) horizontal c) 45 d) 135 e) ungerichtet
Edge-Histogramm 25 einem Kreis angeordnet sind, daß Komplementärfarben (die in der Summe weiß ergeben) um 180 verschieden sind. Die Sättigung (Saturation) gibt an, wieviel weiß zur Aufhellung hinzugemischt wird (Verringerung der Sättigung), bzw. wieviel schwarz zum Abdunkeln (Erhöhen der Sättigung). Die Helligkeit ist der Abstand von der Spitze zur Basis des Kegels. Wenn jeder Block des Subimages in dieser Weise auf Kanten untersucht worden ist, lässt sich daraus ein Histogramm erstellen. Jedes Bin dieses Histogramms stellt die Häufigkeit der entsprechenden Kantenart innerhalb dieses Subimages dar. Der Edge Histogram Deskriptor (EHD) beschreibt ein Kantenhistogramm, welches die räumliche Verteilung der Kanten im untersuchten Bild wiedergibt. Er stellt in einem Vektor die pro Subimage gezählten Kantentypen dar (die Länge des Vektors beträgt also 16 Subimages * 5 Kantentypen = 80 Werte) Da der Deskriptor so einfach aufgebaut ist, können damit schnelle Berechnungen durchgeführt werden und die Leistung beim Bildervergleich bleibt auch bei wenig texturiertem Material gut. Zuordnung eines Blocks zur passenden Kantenart
26 Edge-Histogramm Kantenwerten sondern prozentualen Angaben über alle Kanten besteht. Edge-Varianten Neben dem oben beschriebenem Vorgehen, können auch Varianten implementiert werden. Beispiel Edge-Improved: An den 80-wertigen Vektor mit den Häufigkeiten der Kanten werden jeweils pro Kantenart Durchschnitt und Varianz angefügt, so daß der Vektor dann aus 90 Werten besteht. Der HSV-Farbraum Der Vergleich der Bilder Über eine Distanzberechnung der Bins pro Histogramm werden zwei Bilder miteinander verglichen, das heißt es wird die Differenz der Kantenhäufigkeiten ermittelt. Die dabei errechneten Differenzen werden aufsummiert und durch die Anzahl der Bins geteilt, so daß man einen Wert zwischen 0 und 1 erhält. Kleine Werte bedeuten dabei, daß sich Bilder sehr ähnlich sind, große Werte sagen aus, daß die Bilder entweder sehr unterschiedlich sind, oder ihre Texturen sehr unterschiedlich verteilt sind. Neben dem globalen Vergleich aller Subimage-Histogramme ist es auch möglich, nur einzelne Subimages zum Vergleich heranzuziehen. Beispielsweise wäre es möglich, darüber nach Landschaftsbildern mit klarem Himmel zu suchen, da hierbei in der oberen Hälfte des Bildes wahrscheinlich nur wenige Kanten gefunden werden. Dadurch, daß über die Helligkeit und nicht über den Farbwert gesucht wird, spielt es auch keine Rolle ob sich auf den Bildern ein roter Abendhimmel oder ein tiefblauer zur Mittagszeit befindet. Um auch unterschiedlich große Bilder sinnvoll miteinander vergleichen zu können, sollte der Histogramm-Vektor normiert werden, so daß er nicht aus den absoluten Beispiel Centered: Hierbei wird der Vektor auf die Größe140 erweitert indem der Bereich der inneren 4 Subimages nochmals in 16 Subimages aufgeteilt und untersucht wird. Dadurch ergibt sich eine stärkere Beachtung der Bildmitte, die ja im allgemeinen bei der menschliche Wahrnehmung auch eine größere Rolle als die Randbereiche spielt. Um die Kanten zu erkennen, wird ein Schwellwert (Threshold) festgelegt, der bestimmt, welche Pixel als weiß und welche als schwarz gesehen werden. Die zuerst angedachte Lösung, einen festen Wert in der Mitte des Werte-Intervalls zu benutzen funktionierte bei allgemein hellen oder dunklen Bildern nicht. So wurde auf eine dynamische Threshold-Berechnung umgestellt. Hierbei lässt sich eine Kante finden, wenn die einzelnen Pixel eine genügend große Varianz untereinander besitzen. Unterschiede ergeben sich je nach Berechnungsgrundlage des Schwellwerts. Beispiel Block: Nur die Pixel des gerade untersuchten Blocks bestimmen den Theshold. Beispiel Subimage: Je Subimage wird ein Threshold berechnet, der für die darin untersuchten Blöcke gilt. Beispiel Ganzes Bild: Es wird ein Threshold über das ganze Bild errechnet und zur Untersuchung der Blöcke verwendet.
Edge-Histogramm 27 Beispiel-Bilder Dann wurde überprüft, wie der Algorithmus in den unterschiedlichen Varianten die Bilder verarbeitet und in eine monochrome Darstellung überführt, um herauszufinden, welche Version sich am besten für die Weiterverarbeitung im SOM eignet. Ergebnis und Probleme Die Entscheidung wann zwische zwei Pixeln eine Kante vorliegt stellt das größteproblem dar. Nur die Helligkeit zu nehmen funktioniert nicht für alle Blder, besonders bei künstlich erzeugten. Oft gibt es auch Unterschiede in der Farbe oder in der Sättigung, die vom Menschen als deutliche Kante erkannt wird. Deswegen wurden ansatzweise alle drei HSV-Werte berücksichtigt, wobei auch hier keine generelle Lösung gefunden werden konnte. Die Schwellenwerte, ab wann ein S- oder V-Wert zu einer 0 oder 1 im Block führt hängen von den vorhandenen Unterschieden der S- und V-Werte im gesamten Bild ab. Wie diese Abhängigkeit im Detail aussieht ist nicht geklärt. Ein weiteres Problem stellt die Definition einer Kante dar. Eine Kante nur durch vier Pixel zu defninieren führt augenscheinlich zu dem Eregebnis,dass nur untersucht wird, wo ist etwas auf dem Bild und wo nicht. Wirkliche Kanten müssten länger sein. Auch das wurde nicht im Detail gekärt. Das edgecentered liefert die besseren Ergebnisse Parameter Die vorhandenen Edge-Algorithmen benötigen relativ wenig Iterationen, von 5000 bis 20000 je nach Größe des Netzes. Die Nachbarschaftsrate sollte deutlich unter 1 laufen, bevor die Lernrate unter 0 geht. Die vorandenen packages sind: edgeimproved edgecentered Kantenvektor eines Subimages - Er gibt die Häufigkeit der verschiedenen Kanten an.
28 Edge-Histogramm Original: Centered-Block Centered-Sub Centered-Total Bei der blockweisen Bestimmung des Thresholds werden nur wenige Umrisslinien des Fisches erkannt, die Erkennung bei der Festlegung über Subimages ist deutlich verbessert, allerdings ist die Variante über das ganze Bild am brauchbarsten. Total erkennt gegenüber den anderen beiden keine Wolken, bildet aber das Stadtbild ausreichend differenziert ab. Sub liefert hierbei das beste Ergebnis, gefolgt von Total. Das Portrait wurde von allen Varianten am schlechtesten erkannt. Total liefert noch das beste Ergebnis.
Farb-Kontexte 29 Farb-Kontexte ColorHisto-Kontext Der ColorHisto-Kontext codiert die Häufigkeit von 6 festgelegten Farben und den Grau-Anteil innerhalb eines Bildes. Nachdem die Bilder für das Edge-Histogramm bereits von RGB nach HSV umgewandelt wurden, wird dieses auch für den ColorHisto-Kontext verwendet. Dafür wurde eine diskrete Aufteilung im Farbkreis definiert und Grenzwerte bei den Saturation- und Value-Werten festgelegt, innerhalb derer eine Farbe zuordnebar sein sollte. Der Hue-Wert bezeichnet eine Gradzahl zwischen 0 und 360 auf dem Farbkreis. Folgende Einteilung wurde getroffen: Rot = 341-360 und 0-35 Gelb = 36-70 Grün = 71-160 Cyan = 161-200 Blau = 201-270 Magenta = 271-340 Der Saturation-Wert bezeichnet die Farbsättigung und liegt zwischen 0 und 100, wobei 100 gesättigte Farbe (keine Schwarzbeimischung) und 0 ungesättigt bedeutet. Ein Farb-wert wird nur als solcher gewertet, wenn der S-Wert mindestens 25 beträgt und nicht -1 ist. Der Value-Wert bezeichnet die Helligkeit und liegt ebenfalls zwischen 0 und 100, wobei 0 schwarz und 100 weiß darstellt. Ein Farbwert wird nur als solcher gewertet, wenn der V-Wert mindestens 15 beträgt. Bei dieser Einteilung würden schwarzweiße, beziehungsweise graue Bilder herausfallen, darum gibt es im Histogramm neben den sieben Farben noch einen Grau- Bin. Dieser wird erhöht, wenn der H-Wert -1 beträgt. Die Reihenfolge des Vektor sieht folgendermaßen aus: [rot, gelb, grün, cyan, blau, magenta, grau] [0, 1, 2, 3, 4, 5, 6] Das Bild wird auf die Häufigkeit dieser Farben untersucht und ein ColorHisto-Vektor erstellt. Farb-Layout Um analog zum Edge-Histogramm auch Bilder von unterschiedlicher Größe und Format miteinander vergleichen zu können wurden sie in 16 Subimages aufgeteilt. Die Farbaufteilung und der Vektor bleiben wie beim ColorHisto-Kontext erhalten. Jedes Subimage wird auf die Häufigkeit der Farben untersucht und die daraus entstehenden Teilhistogramme werden aneinandergefügt und normiert, so daß unterschiedlich große Bilder verglichen werden können. In zwei weiteren Variationen wurde die Farbunterscheidung verfeinert. Statt den sechs Farb-Bins und einem Farblos-Bin unterteilt das Color-Layout-High Kontext-Plugin die Farben in zwölf Bereiche, sowie in schwarz, weiß und grau. insgesamt also 15 Bins für jedes Subimage. Die Einteilung der H-Werte erfolgt in 30 Schritten, beginnend bei rot von 345-15. Beide Farb-Layout Kontexte sind auch im Aufbau der Subimages variiert. Wie beim Edge-Algorithmus ist das Zentrum des Bildes in mehr Subimages aufgeteilt, als in der Peripherie. Als nächst höherer Detailgrad wird der gesamte HSV-Raum berüchsichtigt. Sechs Bins für die Farbe, fünf für die Sättigung und fünf für die Helligkeit. Insgesamt 150 Bins pro Subimage. Die Unterteilung der Farbe in ebenfalls zwölf Bins würde einen Vektor von 300 Stellen pro Subimage ergeben und wurde aus Performanzgründen nicht implementiert.