Wie könnte man in der ExpoDB nach Farben suchen?

Christof Mainberger, 21.11.2024

Vor einiger Zeit kam aus der Staatlichen Kunsthalle Karlsruhe der Vorschlag, mit der ExpoDB nach Sammlungsobjekten mit bestimmten Farben zu suchen. Leider kam es bislang lediglich dazu, dass wir uns dazu ein Konzept überlegt haben. Wir haben es noch nicht implementiert und insofern gesichert, dass es überhaupt funktioniert. Aber ich kann ja wenigstens mal dieses Konzept aufschreiben, zumal die Frage überhaupt Probleme des Indexieren und Suchens überhaupt verdeutlicht.

Ein sinnfälliges Modell für eine Suchmaschine wie Solr, das in der ExpoDB verwendet wird, ist ein Kochbuch. Stellen wir uns vor, wir hätten Rotkraut und überlegen uns, was wir nun damit kochen wollen. Außerdem haben wir den Kochbuch-Klassiker "Ich helf dir kochen". Wie würden wir vorgehen? Sicher nicht bei Seite 1 aufschlagen und Seite für Seite durchgehen, ob das Stichwort "Rotkraut" auftaucht (Besser wäre es schon, sich auf das Kapitel Gemüse zu beschränken). Nein, die Autorin hat hinten im Buch Indexe für uns vorbereitet. Wir wählen nun nicht den Index mit den Rezeptnamen. In Rezeptnamen ist "Rotkraut" ggf. vielleicht erwähnt, aber nicht zuverlässig immer, wenn Rotkraut drin ist. Sondern wir wählen den Index zu den Zutaten und richtig: Wenn wir nun statt nach "Rotkraut" nach "Rotkohl" suchen, sind dort eine ganze Reihe Seitenzahlen zu all jenen Rezepten vermerkt, wo Rotkohl verwendet wird: ein paar Gemüse-Beilagen und vielleicht noch Gerichte, wo wir es gar nicht erwartet hätten. 

Ebenso ist es bei der Indexierung für die ExpoDB: Es ist nicht möglich zum Suchzeitpunkt den Datenbestand von ersten Datensatz bis zum letzten durchzugehen und den Suchbegriff mit den Datensatz zu vergleichen. Wir müssen vorab einen Index erstellen, der uns dann später einen schnellen Zugriff auf die relevanten Datensätze ermöglicht. Dabei ist hilfreich, nicht nur Indexe "mit allem" zu erstellen, sondern spezialisierte Indexe für spezifische Aufgaben. Und es ist sinnvoll, die Begrifflichkeit eine "Normalisierung" (von Rotkraut zu Rotkohl) zu unterziehen. Dies müssen wir dann bei Suchen auch mit den Suchbegriffen machen, damit wieder alles zusammenpasst. 

Kommen wir zu den Farben: Es ist nicht möglich zum Zeitpunkt, wenn jemand eine Farbe zum Suchen eingibt, alle Bilder nacheinander hervorzuholen, sie irgendwie alle mit dieser Farbe zu vergleichen und  dann eine nach Ähnlichkeit sortierte Liste auszugeben. Auch hier müssen wir vorab einen passenden spezialisierten Index erstellen und - nachdem wir Solr einsetzen - muss sich dieser Index in die sonst eingesetzte Technologie von Solr und der ExpoDB einordnen. 

Ein digitales Bild besteht aus Pixel, die (im RGB-Farbraum) eine Farbcodierung in Form von drei Zahlen zwischen 0 und 255 tragen. Wir können nun jeder der damit kodierbaren 16 Mio. Farbwerte als unterschiedliche Wörter ansehen und das Bild sozusagen als ein Text, in dem diese Wörter verwendet werden. Mit dieser Vorstellung bewegen wir uns bereits in dem Feld, das wir in der ExpoDB sonst auch mit Solr behandeln: die Suche nach Wörtern in Texten. 

Nun können Bilder viele Pixel enthalten, also dann ziemlich langen Texten entsprechen. Trotz der Effizienz von Solr führt dies evtl. zu viel Speicherbedarf und Rechenzeit. Um diesen Aufwand zu reduzieren können wir auf die gängigen Algorithmen zur Verkleinerung von Bildern zurückgreifen. Diese "Verpixeln" zwar das Bild, so dass Konturen verzerren und verschwimmen, aber sie erhalten die Farben, um die es hier geht, bzw. reduzieren diese systematisch. Wir könnten also Kopien zu den Bildern für die Indexierung einheitlich auf 64 * 64 verkleinern - das erscheint klein, es wären dann immer noch "Texte" mit 4096 "Wörtern". Dies enthalten zu den ursprünglichen Farben ähnliche Farben und zwar in ähnllichen Mengenverhältnissen. 

Beim Suchen sind nicht die Treffer zu genau einer der 16 Mio. Farben relevant, sondern auch die zu ihr "ähnlichen" benachbarten Farben. Wie können wir Farbähnlichkeit einbauen? Wir könnten statt alle Farbwerte zwischen 0 und 255 (als Hexadezimalzahlen 00 bis FF) nur noch jeden 16sten Wert berücksichtigen und alle dazwischen auf jene 16 Werte abbilden. Das würde von Farbcodes in Hexadezimalschreibweise, z.B. A23B67 zu A36 führen, also zu kompakteren "Worten" mit 3 statt 6 Buchstaben. Es wäre auszuprobieren, ob diese Reduktion zu passenden Ergebnissen führt. Sonst wäre eine Strategie, jeden Farbwert nicht nur auf einen gemittelten Farbwert abzubilden, sondern zu mehreren in der Umgebung. 

Bei der Suche müssten die zu suchenden Farben der gleichen Behandlung unterzogen werden, wie die der Bilder bei der Indexierung. Nach dem oben skizzierten Ansatz könnte statt nach 16 Mio. Farbwerten im Hintergrund nur noch nach 4096 vielen gesucht werden. Mutmaßlich wäre dies für beabsichtigte Anwendung völlig akzeptabel. 

Wie gesagt ist all dieses bislang noch nicht implementiert. Ob die skizzierten Konzepte tragfähig sind, müsste erst noch erwiesen werden. Immerhin würden sie sich nahtlos in die bisherigen Technologien und Schnittstellen der ExpoDB einfügen. Sicherlich gibt es auch andere, spezialisierte und leistungsfähigere Ansätze für Farben in Suchmaschinen - auch diesen haben wir nicht selbst erfunden, sondern nur im Internet gefunden. Als ein Aspekt muss immer dabei beachtet werden, wie hoch sich der Aufwand in unserem konkreten Zusammenhang ExpoDB darstellt. Für die ja durchaus bunte Perspektive Farbsuche erscheint der Aufwand zu vertreten, sofern sich das oben skizzierte Konzept so verwirkichen lässt.