¨uber das Internet an den Bilddatenbank-Server anmelden k¨onnen, f¨uhrten zu der Entschei-dung ein Client-Server-System zu entwerfen. Implizit ist durch diese Maßnahme eine klare Trennung von Suchsystem und nat¨urlicher Bedienung durch multimodale Interaktionskan¨ale gegeben. Da der Bilddatenbank-Server zweigeteilt ist, entsteht die abgebildete dreischichtige Gesamtsystemstruktur.
Multimodaler Bilddatenbank-Client
Der Benutzer wird lediglich mit dem Datenbank-Client, der auf der linken Seite der Ab-bildung plaziert ist, konfrontiert. Die Ablaufsteuerung bildet hier das zentrale Element. Die Steuerung der Bedienoberfl¨ache mit der Pr¨asentation der Suchergebnisse geh¨ort ebenso zur Aufgabe dieses Systemteils wie der Verbindungsauf- und -abbau zum Datenbank-Server. Die Ablaufsteuerung koordiniert die asynchron eintreffenden Ereignisse der angeschlossenen Mo-dalit¨atenerkenner. Dabei werden zwei Arten der Synchronisation unterschieden. Zum einen m¨ussen Ereignisse unterschiedlicher Erkenner, die in einem Kontext stehen, als solche de-tektiert und als gemeinsames Ereignis weiterverarbeitet werden. Zum anderen m¨ussen akti-onsausl¨osende Ereignisse, die im aktuellen Systemzustand aber unsinnig oder verboten sind, verworfen werden. Die akzeptierten Ereignisse werden auf Aktionen abgebildet und in Aufrufe von Datenbankdiensten und Oberfl¨achenaktionen umgesetzt. Diese Dienste sind oft daten-abh¨angig, so dass hier eine entsprechende Koordination vorzunehmen ist. Das vom Server gelieferte Suchergebnis erfordert beispielsweise das anschließende Laden der im Suchergebnis angegebenen Bildobjekte f¨ur die Anzeige in der Bedienoberfl¨ache.
An dieser Stelle soll nicht n¨aher spezifiziert werden, ob die eingesetzten Erkenner als ei-genst¨andige Applikation mit den dann notwendigen Schnittstellen fungieren oder ob die Er-kenner als Ganzes in die Client-Applikation eingebunden werden. Als Interaktionsmodalit¨aten f¨ur den nat¨urlichen Zugang sollen Gestik und Sprache eingesetzt werden. Da die Benutzung einer grafischen Bedienoberfl¨ache die Modalit¨at Maus als standardm¨aßig anbietet und dieser als bereits bestehender Interaktionskanal f¨ur die Entwicklung des Systems enorm wertvoll ist, soll die Maus ebenso zur Interaktion einsetzbar sein.
CRPU
Die ausgew¨ahlte Inter-Prozess-Kommunikation, basierend auf TCP/IP, pr¨agt die Struktur des Konfigurations- und Suchmoduls (engl.:Configuration and Retrieval Processing Unit, CRPU).
Der administrative Teil erledigt den Verbindungsauf- und -abbau sowie die Entgegennahme von Anfragen, die Ausf¨uhrung der entsprechenden Dienste und das Generieren einer Antwort an den Client. Neben den Diensten, wie beispielsweise dem Entgegennehmen von Bildobjektbewertun-gen oder dem Anfordern eines Bildes zur Anzeige, bildet die intelliBildobjektbewertun-gente Suche den Hauptteil dieser Applikation, der aber aus Architektursicht lediglich einen von vielen Diensten darstellt.
Die Referenzierung von Regionen ist ebenfalls ein besonderer Dienst, der das wahrscheinlichste Bildobjekt eines Bildes entsprechend der angegebenen Attribute liefert.
Die bildverarbeitenden Teile dieser Applikation, wie Segmentierer und Merkmalsberechnung, sind kein fester Bestandteil der Applikation sondern je nach Wunsch ladbar. Diese Module
3.6 Gesamtsystem
werden sowohl zur Initialisierung des Datenbestandes als auch zur Laufzeit f¨ur das Hinzuf¨ugen neuer Bildregionen oder zur Suche mit einem extern eingebrachten Beispielbild ben¨otigt.
Lediglich diese Applikation h¨alt eine Verbindung zu dem angeschlossenen Datenbank-Management-System.
SQL-Datenbank-Server
Die Verwaltung und das Ablegen der zum Betrieb der Bilddatenbank notwendigen Daten wird einem angeschlossenen SQL-Datenbank-Management-System ¨uberlassen [Lan95]. Da die Distanzbildung zweier Repr¨asentantenvektoren dann sehr teuer ist, wenn sie außerhalb des Datenbank-Management-Systems stattfindet, soll diese Funktionalit¨at in diesen Systemteil in-tegriert werden. Hierf¨ur werden nachladbare Module, so genannte Plugins, mit der gew¨unschten Funktionalit¨at erstellt, die beim Starten des SQL-Datenbank-Servers geladen werden. Die Funktionalit¨at wird dem SQL-Client durch eine Erweiterung des SQL-Funktionsumfangs be-reitgestellt.
Die Realisation der in diesem Abschnitt vorgestellten Konzepte wird in den nachfolgenden zwei Kapiteln nach Bilddatenbank-Server und -Client getrennt erl¨autert.
Kapitel 4
Datenbank-Server
Der in diesem Kapitel n¨aher vorgestellte Bilddatenbank-Server bildet das R¨uckgrat des Bildda-tenbanksystems. W¨ahrend der Datenbank-Client die Interaktion mit dem Benutzer durchf¨uhrt, um eine Suchanfrage zu formulieren und Relevanzbewertungen entgegenzunehmen, und Su-chergebnisse anzeigt, wird die eigentliche Bildsuche im Server des Datenbanksystems durch-gef¨uhrt. Die zur Suche geh¨orenden Daten werden vom Server gehalten und iterativ modifiziert.
4.1 Datenhaltung
Die Datengrundlage eines Bilddatenbanksystems stellen die Bilder dar, die f¨ur eine Suche herangezogen werden sollen. Bei dem hier dargestellten inhaltsbasierten Suchsystem st¨utzt sich jede Suchanfrage auf die aus den Bildern extrahierten Vektoren der unterschiedlichen Merkmalsrepr¨asentanten. Die Dimension der erzeugten Vektoren variiert von Repr¨asentant zu Repr¨asentant (siehe Abschnitt 4.2.2). In diesem Abschnitt wird zun¨achst beschrieben, welche Daten f¨ur den Betrieb der Datenbank notwendig sind und wie auf diese zugegriffen werden muss. Daraus ergibt sich die notwendige Datenhaltung bzw. -generierung.
4.1.1 Bildobjekt
Da ein Bild im Allgemeinen nicht als Ganzes wahrgenommen wird, sondern sofort Objekte erkannt und in einen semantischen Zusammenhang gebracht werden, ist es sinnvoll, diese Un-terteilung im System ebenfalls vorzunehmen. Das Bilddatenbanksystem muss mit Bildregionen arbeiten k¨onnen, die im Idealfall einzelne oder gruppierte Objekte beinhalten.
F¨ur die Generierung solcher Bildregionen, die von Segmentierern durchgef¨uhrt wird, gibt es unterschiedliche Ans¨atze, die je nach Anwendung unterschiedlich gut geeignet sind. Die au-tomatisch bestimmten, aber auch die manuell markierten Regionen eines Bildes werden im Folgenden als Bildobjekte bezeichnet.
4.1.2 Bilddatenhierarchie
Abbildung 4.1 veranschaulicht den Verarbeitungsprozess, der f¨ur den Betrieb der Bilddatenbank f¨ur jedes Bild durchgef¨uhrt werden muss. Das Bild wird im ersten Schritt durch den Einsatz mindestens eines Segmentierers in Bildobjekte zerlegt. Der sich anschließende
Verarbeitungs-Repr¨asentantJ Repr¨asentantJ
~ rJn=
0 B B B
@ rnJ1 rnJ2 .. . rnJ dJ
1 C C C A
~ r1m=
0 B B B
@ rmJ1 rmJ2 .. . rJ dJm
1 C C C A Repr¨asentant2
Repr¨asentant2
Segmentierung Merkmalsberechnung
Bildebene Objektebene Merkmalsebene
Repr¨asentant1
Repr¨asentant1
~rm1 = 0 B B B
@ rm11 rm12 .. . rm1d
1 1 C C C A
~ r1n=
0 B B B
@ rn11 rn12 .. . rn1d
1 1 C C C A
Abb. 4.1:Abh¨angigkeiten der Bilddaten:Jedes Bild der Datenbank wird durch Segmentierer in unterschiedlich viele Bildobjekte zerlegt. Das ganze Bild stellt ebenfalls ein Bil-dobjekt dar, wobei f¨ur jedes Bildobjekt die Vektoren aller Merkmalsrepr¨asentanten berechnet werden.
schritt besteht in der Berechnung der Merkmalsvektoren der einzelnen Repr¨asentanten. Auch hier ist f¨ur den korrekten Betrieb der Datenbank gefordert, dass mindestens ein Repr¨asentant verwendet wird, da dies die Grundlage f¨ur die ¨Ahnlichkeitsbestimmung von Bildobjekten ist.
Die berechneten Merkmalsvektoren sind f¨ur den Suchbetrieb zwingend erforderlich und m¨ussen daher in geeigneter Art und Weise gespeichert werden. Gleiches gilt f¨ur die Bilddaten und die Ergebnisse der Segmentierer, die Bildregionen, die zwar nicht f¨ur die inhaltsbasierte Suche, je-doch f¨ur die Interaktion mit dem Benutzer auf der Ebene des Bilddatenbank-Clients erforderlich sind.
4.1.3 Speichern der Daten
Die im vorherigen Abschnitt aufgezeigten, automatisch generierten Daten bilden den Hauptteil der zu speichernden Daten. Zus¨atzlich m¨ussen Konfigurationsdaten ¨uber die zu benutzenden Segmentier- und Merkmalsmodule gespeichert werden, was f¨ur den Erhalt der Flexibilit¨at des Systems erfordert ist.
4.1 Datenhaltung
Generell stellt sich die Frage, wie der Zugriff auf diese Daten erfolgen soll. Zum einen ist zu bedenken, dass es sich um eine Datenbank mit nicht herk¨ommlichen Daten wie zum Beispiel Bildern handelt, die nicht in traditionellen Datentypen gehalten werden k¨onnen. Zum anderen ist die hier bestehende Datenabh¨angigkeit sehr unkompliziert und flach.
Auf eine n¨ahere Untersuchung, welche Vorteile durch den Einsatz eigener Datenhaltungsme-chanismen zu erzielen sind, wurde im Rahmen dieser Arbeit verzichtet. Der Grund liegt in dem sehr hoch anzusetzenden Aufwand, eine robuste Datenhaltung mit effizientem Datenzugriff sowie Sortierungsm¨oglichkeiten zu entwickeln.
FeatureData tblFeatureRep1
tblRegions
RegSpecData Creator tblSegmentations
Type
SegSpecData
tblVisualFeatures TableName
FunctionName tblImage
FileName
tblThumbnail JpegData
tblDomains
DomainName tblDistances DistFnName
tblFeatures FeatureName tblRepresentants
TableName FunctionName
RepName Dimension
tblLibraries
LibName
LibType
SegName tblSegmentators
1
n
1
1 n
1 1
n 1
1 1
1
1
1
n 1
n 1
1 n
Abb. 4.2: Entity Relationship Diagram: Datenorganisation in der verwendeten Datenbank.
Zu beobachten ist die Zweiteilung der Daten entsprechend der Betriebsart in Onli-ne (links) und OffliOnli-ne (rechts). Der ¨Ubersicht halber hier sind nur die wichtigsten Attribute aufgezeigt
In Vorarbeiten wurden verschiedene Alternativen von verwendbaren Datenbankprodukten dis-kutiert [K¨as01]. Im Gegensatz zu der dort vorgestellten L¨osung beschr¨ankt sich der Einsatz der selbst implementierten Funktionen zur Erweiterung des SQL-Sprachumfangs bei dem hier vorgestellten System auf die Berechnung des Abstands von Merkmalsvektoren (siehe 4.2.3, Distanzfunktionen). Die Implementierung der Datenbankanbindung ist so ausgelegt, dass sie weitestgehend unabh¨angig von dem benutzten Datenbankprodukt ist. Um das zu erreichen, ist das Abspeichern von bin¨aren Daten zwingend notwendig. Da bin¨are Daten von der verwendeten Rechnerarchitektur abh¨angig sind, muss hier eine architekturunabh¨angige Datenrepr¨asentation eingesetzt werden (siehe Abschnitt 6.1.1). Auch hier wird die NDR-Datenrepr¨asentation, die bereits bei der Kommunikation zwischen Client und Server verwendet wird, eingesetzt. Es fiel wie in [K¨as01] die Wahl auf das Datenbankprodukt MySQL, das sich als frei verf¨ugbare Applikation durch eine hervorragende Performanz auszeichnet.
Alle Daten werden in der Datenbank entsprechend der Abbildung 4.2 gespeichert. Allein die zugrunde liegenden Bilder werden wie in [K¨as01] im Dateisystem gehalten. Der Grund hierf¨ur besteht darin, dass eine SQL-Datenbank prim¨ar nicht auf das Speichern von bin¨aren Daten ausgelegt ist und mit Einbußen der Performanz beim Zugriff zu rechnen ist, wenn eine Tabelle in großem Maße Bin¨ardaten enth¨alt. Aus diesem Grund wurde auf referentielle Integrit¨at in diesem Punkt verzichtet.