BVA-System

In der Zwischenzeit sind die angekündigten 2 Wochen fast um, aber ich hatte die letzten 2 Wochen auch noch alle Hände voll zu tun. Da langsam aber sicher die Anzahl der Downloads des BVASystems steigen, war es für mich plötzlich ziemlich wichtig, die Installationsanleitung für das Programm fertig zu schreiben. Ich hoffe, das dadurch die technische Hürde, die vor dem Benutzen des Programmes steht, gesenkt werden konnte.

Trotzdem ist die Version 2.0.0.24 nun fertig und kann an alt bekannter Stelle heruntergeladen werden. Neben einigen kleineren Bugfixes steckt dieses mal der größte Teil der Arbeit in dem Workertask zur Initialisierung eines Entscheidungsbaumes, der für die Zuordnungen zwischen Bild und Fotoalbum genutzt werden soll.

Direkt nachdem die Verbindung zur Datenbank hergestellt wurde, wird der Initialisierungstask angeworfen. Spätestens nach einigen Sekunden ist der Task abgearbeitet und es kann wie gewohnt mit der Datenbank gearbeitet werden. Die erfolgreiche Beendigung des Tasks kann über den Statusdialog des Workers bei Bedarf kontrolliert werden.

Aufbau des Entscheidungsbaumes

Der Entscheidungsbaum, wie er beim BVASystem zum Einsatz kommt, besitzt eine feste Struktur. Als erstes Entscheidungskriterium wird das Metadatenelement „Besitzer des Bildes“ gewählt. Als Unterknoten der dadurch entstehenden Knoten wird das Metadatenelement „Aufnahmedatum“ eingefügt. Damit der Baum nicht zu sehr in die Breite wächst, habe ich das Aufnahmedatum dreistufig zerlegt. Die erste Einteilung wird grob über das Aufnahmejahr vorgenommen, die zweite Einteilung wird durch das Aufnahmedatum definiert und erst in der dritten Ebene wird das komplette Aufnahmedatum genutzt. Den genauen Aufbau des Baumes habe ich versucht durch folgendes Bild darzustellen:

Metadaten Entscheidungsbaum des BVASystems

Sonderfälle

Auf dem Bild sieht man deutlich einige Sonderfälle, die dadurch entstehen, das der Anwender bei den Metadatendefinitionen nicht eingeschränkt ist.

Wenn der Anwender zum Beispiel kein Metdatenelement „Besitzer des Bildes“ hinzufügt, dann kann bereits die erste Ebene des Baumes nicht entschieden werden. Damit trotzdem mit dem Baum gearbeitet werden kann, wird in diesem Fall ein Knoten mit der Information: „Der Bildbesitzer ist nicht relevant“ angelegt. Die vorhandenen Aufnahmedatum Metadatenelemente werden dann als Unterknoten dieses Knotens angelegt. Im Bild ist dies bei der Metadatendefinition für Fotoalbum 2 der Fall.

Ein weiterer Sonderfall tritt ein, wenn ein Metadatenelement doppelt definiert wurde. Grundsätzlich bedeutet es ja, wenn mehrere Metadatenelemente definiert wurden, das alle erfüllt sein müssen. Es macht aber keinen Sinn, wenn man beispielsweise definiert: Besitzer des Bildes ist Max und Besitzer des Bildes ist Paul. Denn diese Bedingungen werden niemals erfüllt werden können, denn der Besitzer des Bildes ist immer derjenige, der das Bild in die Datenbank eingestellt hat. Also immer eine Person. Daher werden mehrfach vorhandene Metadatenelemente immer als „oder“  interpretiert. Im oben genanten Beispiel wäre die Bedingung erfüllt, wenn der Besitzer des Bildes Max oder Pault ist. Im Bild ist dieser Sonderfall bei Fotoalbum 3 zu sehen.

Ausblick

So langsam aber sicher befindet sich das BVASystem auf der Zielgeraden. In der nächsten Version wird dann endlich der Entscheidungsbaum genutzt um die Zuordnungen zwischen Foto und Fotoalbum automatisch herzustellen. Eigentlich mag man meinen, das dann wieder ein großer Meilenstein abgeschlossen ist, aber leider fehlen dann noch die ganzen Feinheiten. Die Metadatendefinitionen können nicht editiert werden, nicht gelöscht werden, es gibt keine Handhabung für falsche Zuordnungen, der Umfang der möglichen Metadatenelemente ist noch stark ausbaufähig … es bleibt also immernoch sehr sehr viel zu tun.

PageControl mit Hint

Ich habe ja schon viele komische Sachen in der Zeit erlebt, in der ich Delphi programmiere. Das Hint-Verhalten der TPageControl und TTabsheet Komponenten ist mir völlig unlogisch. Dem Tabsheets kann man wunderbar jeweils einen Hint zuweisen. Dieser wird aber nur angezeigt, wenn man sich innerhalb des Clientbereiches des Tabsheets bewegt. Wofür braucht man da bitte schön einen Hint? In dem Bereich liegen normalerweise weitere Oberflächenelemente mit eigenständigen Funktionen. Dort wo man den Hint bräuchte, nämlich auf dem Reiter zum wechseln der Tabsheets, erscheint er nicht. Auf den Reitern wird der Hint angezeigt, den man dem PageControl zugewiesen hat.  Also für alle Reiter der gleiche.

TBVAPageControl

Nun habe ich mir die Mühe gemacht, dieses Verhalten dahingehend zu korrigieren, das es für meine Zwecke einsetzbar ist. Ich habe eine  neue Komponente TBVAPageControl von TPageControl abgeleitet. Falls jemand das TBVAPageControl benötigen sollte: Hier ist es.

Das neue PageControl kann genauso wie das TPageControl verwendet werden, nur das Hint-Verhalten ist halt ein anderes. Beim TBVAPageControl werden die Hints nur noch auf den Reitern angezeigt. Sie sollen als Erklärung dienen, was dem Anwender beim Wechsel auf die jeweilige Seite erwartet. Die Tabsheets selber zeigen keine Hints an und auch das PageControl hat keinen eigenen Hint mehr. In der Entwicklungsumgebung setzt man seine Wunschhints einfach bei den jeweiligen Tabsheets. Der Hint des PageControls bleibt leer.

Wie funktioniert das ganze?

Eigentlich ist das TBVAPageControl ziemlich simpel. Im Mousemove Event wird überprüft, welcher der Reiter sich an der Mausposition befindet. Wenn ein Reiter bestimmt werden konnte, wird der Hint des jeweiligen Tabsheets dem PageControl zugewiesen. Befindet sich die Maus auf keinem Reiter oder verlässt die Maus das PageControl, so wird der Hint des PageControls wieder gelöscht.  Zu erwähnen ist vielleicht noch, das ich das PageControl um ein OnMouseEnter und ein OnMouseLeave Event erweitert habe, da diese in der Standardimplementierung nicht vorhanden waren.

Die Zeit vergeht wie im Fluge. Schon wieder sind die 2 Wochen um und somit steht wieder eine Aktualisierung der Programmversion an.

Leider muss ich diesmal gleich vorab einen unangenehmen Fehler beichten: Ich habe vergessen, bei einer neuen Datenbanktabelle das Häkchen zum automatischen Hochzählen des Index-Feldes vergessen. Daher gibt es diesmal wieder eine aktualisierte Datenbankstruktur, die erstellt werden muss. Es tut mir Leid, das schon wieder eine Aktualisierung notwendig ist.

Wie die korrigierte Datenbankstruktur vermuten lässt, habe ich die Metadatenverwaltung so erweitert, das die XML-Strukturen in der Datenbank abgespeichert werden können. Beim Erstellen eines neuen Fotoalbums können die Metadateneinstellungen vorgenommen werden. Diese werden dann automatisch mit dem Fotoalbum zusammen gespeichert. Für die Speicherung ist es notwendig, das die Metadaten einen eindeutigen Namen erhalten. Dieser Name muss im aktuellen Entwicklungsstand manuell festgelegt werden. Bereits verwendete Namen sind in der Auswahlliste des Namenfeldes eingetragen. Ein Editieren der gespeicherten Metadaten ist aktuell noch nicht möglich.

Neues Fotoalbum anlegen mit eingetragenen Metadaten

Die zweite riesige Änderung der letzten 14 Tagen wird wohl jedem, der das Programm benutzt, sofort ins Auge stechen. Ich habe die Funktionen in den Menüs neu geordnet. Neu hinzugekommen ist, das nun auch ebenfalls auf dem Vorschaubild ein Popup-Menü geöffnet werden kann. Jetzt sollte es möglich sein, das jede Funktion in jeder der drei Ansichtsmodi verwendet werden kann. Es hatte mich gestört, das man in der Einzelbildansicht beispielsweise kein Bild in die Datenbank importieren konnte. Ich hoffe, das die neue Anordnung klarer strukturiert ist und keine logischen Unstimmigkeiten mehr aufweist.

Ich schätze, das ich noch 2 weitere Versionen benötigen werde, um eine allererste durchgängig funktionierende Metadatenverwaltung am Start zu haben. In den nächsten 14 Tagen will ich mich damit beschäftigen, eine Worker-Aufgabe zu implementieren, die mir die gespeicherten Metadaten in einer sinnvollen Datenstruktur ablegt. Diese Datenstruktur will ich dann in der übernächsten Version nutzen, um direkt beim Import Zuordnungen zu Fotoalben zu erstellen.

An der einen oder anderen Stelle hier im Blog habe ich bereits den Begriff  Metadaten verwendet. So richtig erklärt habe ich ihn allerdings noch nicht. Da die Metadaten mit der heute veröffentlichten neuen Programmversion langsam den Weg ins Programm finden, ist es ein guter Zeitpunkt, die Erklärung  jetzt nachzureichen.

Vorweg allerdings noch der Hinweis, das mit der neuen Version eine klitzekleine Datenbankänderung vorgenommen wurde. Es ist also wieder notwendig, die Datenbankstruktur zu aktualisieren. Die neue, dafür notwendige Workbench-Projektdatei befindet sich wieder im Unterverzeichnis „db“ des Programmverzeichnisses.

Was sind also nun die ominösen Metadaten?

Normalerweise ist es bei Bildverwaltungen so, das der Anwender nachdem er Bilder in der Datenbank importiert hat, diesen Bildern Fotoalben und/oder Schlagworte zuordnen kann. Die Zuordnung erfolgt manuell durch den Anwender und erfordert viel Zeit und Ausdauer. Das BVASystem möchte genau den umgekehrten Weg gehen. Nachdem ein Fotoalbum oder Schlagwort erstellt wurde, soll der Anwender eine Reihe von Kritieren festlegen können, die beschreiben, wann ein Bild zu dem Album bzw. Schlagwort gehört. Diese Kritieren, die unterschiedlicher Struktur sein können, bezeichne ich als Metadaten.

Die festgelegten Metadaten sollen vom Programm beim Bildimport dazu dienen, das die Bilder gleich automatisch den entsprechenden Fotoalben bzw. Schlagworten zugeordnet werden. Dadurch möchte ich erreichen, das der Anwender viel Arbeit spart. Es ist nicht mehr notwendig, für jedes Bild festzulegen wohin es gehört. Schlussendlich soll der Anwender beim Betrachten seiner Bilder nur noch, eventuell vorhandene, falsche Zuordnungen korrigieren.

Im einfachsten Fall nutzt man für ein Fotoalbum nur die Metainformation des Aufnahmedatums aus. Tante Trudes Geburtstag war halt am 16. Mai 2011. Alle Bilder, die nicht am 16. Mai aufgenommen worden sind, können also nicht von Tante Trudes Geburtstag stammen. Im Umkehrschluss sind also alle Bilder, die am 16. Mai aufgenommen wurden, von Tante Trudes Geburtstag.

Kompliziertere Zuordnungen sind natürlich denkbar. Alle Fotos die im Umkreis von 52° 31′ N, 13° 24′ O aufgenommen wurden, sind in Berlin gemacht. Alle Bilder, auf denen sich ein Gesicht befindet, sind Portraits. Alle Bilder, auf denen sich eine Horizont-Linie finden lässt, sind Landschaftsbilder. Alle Bilder, die nachts aufgenommen wurden und deren vorherrschende Farbe schwarz ist, sind Nachtaufnahmen. Generell sind der Phantasie hier keine Grenzen gesetzt.

Was ist davon bisher umgesetzt?

Mit dem Dialog zum Erstellen eines Fotoalbums war ich bisher ja nicht richtig zufrieden. Daher hat dieser Dialog nun eine komplett neue Oberfläche erhalten. In der neuen Oberfläche kann nun ausgewählt werden, welche Metadaten zu dem Fotoalbum gehören. Umgesetzt habe ich 2 Metadatentypen (Aufnahmedatum und Bildbesitzer), die in beliebiger Anzahl ausgewählt werden können. In der linken unteren Ecke des Dialoges gibt es eine Testfunktion, die die Metadaten in einem XML-Format abspeichert. In der Datenbank werden die Metadaten noch nicht abgelegt.

Eine Metadatendatei könnte wie folgt aussehen:

<?xml version="1.0" encoding="ISO-8859-1"?>
<metadata>
 <name>Album_Mosel_2011</name>
 <elemente>
  <element typ="0">
   <mindate>10.05.2011</mindate>
   <maxdate>20.05.2011</maxdate>
  </element>
  <element typ="1">
   <owner>Marc</owner>
  </element>
 </elemente>
</metadata>

In der nächsten Programmversion werde ich mich darum kümmern, das das Hauptmenü und die PopUp – Menüs wieder klarer strukturiert sind. Durch die Einführung der 3 Ansichtmodi ist die klare Struktur leider verloren gegangen, so das eine Anpassung notwendig wird.

Außerdem werde ich mich natürlich darum kümmern, die Metadatenfunktionalität weiter auszubauen. Bei dem Metadatentyp Bildbesitzer muss die Auswahlliste der möglichen Bildbesitzer gefüllt werden. Die Metadaten müssen natürlich in der Datenbank gespeichert werden. Eine Auswahlliste der verfügbaren Metadatendefinitionen muss ebenfalls gefüllt werden. Beim Editieren müssen die Metadatendefinitionen wieder geladen werden …. usw. Es gibt noch viel zu tun bis die Metadaten richtig genutzt werden können. Ich hoffe, das sich der Aufwand trotzdem lohnen wird.

In der letzten Zeit scheinen sich die Delphi Problemchen wieder zu häufen. Dieses mal hat mich die TScrollbox fast 2 Tage gekostet. Aber der Reihe nach:

Ich bin gerade dabei, eine Komponente zu entwickeln, mit der Metadaten, die zu einem Fotoalbum gehören, definiert werden können. Da eine beliebige Anzahl von Metadaten definiert werden kann, ist es notwendig, die jeweiligen Steuerelemente in eine Scrollbox anzuordnen.

Da es die erste TScrollbox ist, die ich im BVASystem benutze, fiel mir gleich ein grundlegendes Problem auf: Die Scrollbars der Scrollbox sahen optisch anders aus, als die in den selbstgeschriebenen Komponenten.

In Delphi 2005  sehen  die Steuerelemente standardmäßig so aus wie unter Windows 2000. Durch das Einbinden der Komponente TXPManifest kann das Aussehen auf den XP Style umgestellt werden.

Durch die selbstgeschriebenen Komponenten habe ich bisher darauf verzichtet, das Manifest in die Bilddatenbank zu integrieren. Es gab zu viele unschöne Effekte, die ich hätte korrigieren müssen. Außerdem finde ich es unschön, wenn das komplett in Brauntönen gehaltene Design durch blaue Scrollbars gestört wird.

Das Problem bei der TScrollbox war nun, das die Scrollbars der Scrollbox automatisch im XP-Style sind, auch wenn kein Manifest eingebunden wurde. Warum das so ist, habe ich leider nicht herrausfinden können. Aber ich habe eine Möglichkeit gefunden, wie man den XP-Style der Scrollbox wieder deaktivieren kann:

SetWindowTheme(Scrollbox.Handle, '', '');

Mit diesem schnöden Einzeiler sind die Scrollbars zumindest erstmal wieder einheitlich. Früher oder später, werde ich mich allerdings damit auseinander setzen müssen, wie ich mit der Oberflächengestaltung weiter umgehen werde. Wirklich toll sehen die Scrollbars bei deaktiviertem XP-Style nicht aus. Schlussendlich bleiben 2 Möglichkeiten: 1. Eigene hübschere Scrollbars entwickeln oder 2. den XP-Style Anwendungsweit aktivieren.

Nach der letzten Bugfix-Version steht heute nun die nächste Version an, wo ich aber eigentlich ehrlich zugeben muss, das sie im strengen Sinne keine reine Bugfix-Version ist.

Bei der Einführung des Workers habe ich mir gedacht, das es sinnvoll ist, wenn der Anwender über den Status des Workers informiert wird. Welche Aufgaben stehen im Worker? Welche Aufgaben hat der Worker ausgeführt? Bei welchen Aufgaben im Worker ist ein Fehler aufgetreten?

Um die Fragen zu beantworten, hatte ich schon damals einen Dialog in das Programm integriert, der mit einem Klick auf die „Ampel“ des Workers geöffnet werden kann. Bis zum heutigen Tag war dieser Dialog allerdings leer. Von daher kann es entfernt vielleicht doch als Bugfix bezeichnt werden, wenn dieser Dialog nun nicht mehr leer ist.

Wenn der Statusdialog des Workers geöffnet wird, so wird als erstes der Worker pausiert. Solange der Dialog angezeigt wird, werden also keinerlei Aufgaben erledigt. Wenn der Dialog geschlossen wird, nimmt der Worker seine Arbeit wieder auf. Der Dialog selber unterteilt sich in 2 Bereiche. In dem ersten Bereich sieht man, welche Aufgaben noch im Worker aktiv sind, während im zweiten Bereich angezeigt wird, welche Aufgaben bereits abgeschlossen wurden.

Statusdialog des Workers

Weiterhin neu ist auch der Info-Dialog, in dem abgelesen werden kann, welche Version gerade verwendet wird. Außerdem steht dort ein Verweis auf diese Seite. Neben den Neuerungen habe ich, wie es der Name dieses Artikel bereits vermuten lässt, einige Bugs beseitigt. Wie immer kann die genaue Liste der abgearbeiteten Punkte im Bugtracker analysiert werden.

Als kleine Vorschau auf die nächste Version gibt es zu sagen, das ein klitzekleines Datenbankupdate erfolgen wird. Damit werde ich dann in der Lage sein, die Fotoalben weiter zu erweitern. Außerdem möchte ich, sofern ich es zeitlich noch schaffe, die Funktionen in den Popup-Menüs leicht anders anordnen, da sie nach der Einführung der 3 Ansichtsmodi nicht mehr so klar getrennt sind wie zuvor.

Meinen letzten Artikel, den ich einem Delphi-Problem gewidmet habe, liegt schon einige Monate zurück. Da ich beim Testen auf ein größeres Problem gestoßen bin und auch recht lange gebraucht habe um das Problem zu lösen, bietet es sich an, die Lösung des Problemes hier vorzustellen.

In Delphi 2005 gibt es 2 Sets an Komponenten, die es ermöglichen, einen Dateiauswahl-Dialog recht schnell zusammenzubauen. TDriveCombobox, TDirectoryListBox und TFileListbox sind noch aus den guten alten Windows 3.1 Zeiten vorhanden. Von der Optik her würde ich heute diese Komponenten nicht mehr einsetzen. Als zweites Set haben TShellTreeView, TShellComboBox und TShellListView in der Komponentenliste Platz gefunden. Allerdings werden sie etwas stiefmütterlich behandelt und befinden sich in meiner Delphi 2005 Version nur unter der Komponentenkategorie „Beispiele“.

Im BVASystem habe ich den TShelltreeview und die TShellComboBox genutzt, um den Dialog zur Auswahl des Dateinamens zur Speicherung eines Fotoindexes zu realisieren. Beim Testen ist mir dann aufgefallen, das die Komponenten unter Windows XP für Verzeichnisse, die auf einer CD liegen, teilweise falsche Pfadangaben zurückgeben.  Es werden nur dann richtige Pfadangaben geliefert, wenn das Verzeichnis kein Unterverzeichnis ist. „D:\Bilder\“ klappt also, während für „D:\Bilder\2011-04-29\“  nur „D:\Bilder\“ zurückgegeben wird.

Ok, für die Auswahl eines Speicherortes kann man wohl getrost auf das CD-Rom Laufwerk verzichten. Aber da ich vor habe, die Komponenten auch anderweitig zu verwenden, hat mich das Problem nicht mehr losgelassen.

Die Ursache des Problems konnte ich in der Klasse TShellFolder und dort genau in der Funktion „PathName“ finden. Zur Korrektur des Fehlers muss die Funktion, die sich in der „ShellCtrls.pas“ befindet, folgendermaßen geändert werden:

function TShellFolder.PathName: string;
begin
 result := GetDisplayName(ParentShellFolder, FPIDL, SHGDN_FORPARSING);
 //Result := GetDisplayName(DesktopShellFolder, FFullPIDL,  SHGDN_FORPARSING );
end

Wenn man dann die „ShellCtrls.pas“ schon offen hat, bietet es sich auch an, gleich ein paar Speicherlecks, die die Komponenten haben, zu schließen. Wie die Speicherlecks beseitigt werden, könnt ihr in der QualityCentral von Embarcadero nachlesen. Dort hat Brad Prendergast seine Lösung detailiert in den Kommentaren beschrieben.

Im Jahresfazit des letzten Jahres hatte ich angekündigt, das ich dieses Jahr hauptsächlich damit verbringen werde, die Datenbankfunktionalitäten des BVASystems auszubauen. Daher ist die neue Programmversion, die ab heute zum Download bereit steht, etwas ganz besonderes. Neu hinzugekommen sind nämlich 2 neue Ansichtsmodi, die sowohl im Bildbetrachtermodul, als auch im Datenbankmodul nutzbar sind.

Sucht man in einer Bildliste, die rund 100 Bilder enthält, ein spezielles Bild, so war es bisher nur möglich, das Foto durch ein langsames Durchblättern der Bildliste aufzufinden. In der neuen Miniaturbilder-Ansicht wird der gesammte rechte Bereich der Anwendung dazu genutzt, kleine Miniaturbilder anzuzeigen. Dadurch passen natürlich mehr Fotos auf den Anzeigebereich und die Suche nach einem Bild in der Liste gestaltet sich einfacher. Kurz: Man gewinnt leichter einen Überblick über die Fotos.

Miniaturbilder-Ansicht der Bilddatenbank BVASystem

Konsequenterweise habe ich einen dritten Ansichtsmodus implementiert, in dem nur  das große Vorschaubild angezeigt wird. Wie in der altbekannten Oberfläche gibt es unter dem Vorschaubild eine Funktionsleiste, mit der auch ohne Bildliste navigiert werden kann.

Die Ansichtsmodi kann man wechseln, indem man die entsprechenden Buttons im oberen Teil der Ansichten anklickt. Außerdem kann mit den Funktionstasten F5, F6 und F7 zwischen den Ansichtsmodi gewechselt werden. Beim Wechsel von einem Modus zum nächsten, wird das aktuell aktive Foto übernommen. Es ist also möglich, sich ein Bild in der Matrix herrauszusuchen, um es anschließend in der Einzelbildansicht möglichst groß anzuzeigen.

Wie auch beim letzten Update sind die neuen Funktionen nur in einer Rohbaufassung fertig. In der nächsten Version wird also nichts wirklich neues weltbewegendes dazukommen. Ich werde mich stattdessen damit beschäftigen, vorhandene Fehler zu beseitigen. Es passt von daher auch ganz gut, das mein Cheftester gerade eine Menge neue Tickets eingestellt hat, die ich dann so gut es geht ebenfalls bearbeiten werden.

Gerade jetzt, wo die Implementation der Fotoalben schon relativ weit vorrangeschritten ist, ist ein guter Zeitpunkt sich Gedanken darüber zu machen, nach welchen Prinzipien Ordnung in die Bilderflut gebracht werden kann. Durch die Fotoalben hat das BVASystem ein flexibles System erhalten, mit der Anwender fast jedes Ordnungsystem manuell umsetzen können. Trotzdem ist es angebracht, zu schauen, welche weit verbreiteten Prinzipien  in das Programm zusätzlich implementiert werden können, damit sich diese mit wenig Aufwand nutzen lassen.

Welche Ordnungsprinzipien gibt es?

Weit verbreitet ist zum Beispiel ein relativ einfaches System, bei dem die Bilder zeitlich geordnet werden. Die Bilder, die an einem Tag aufgenommen wurden, werden einfach in einem Ordner gespeichert. Zur besseren Übersicht können die Ordner monats- bzw jahresweise zusammengefasst werden. Dieses einfache System hat den Vorteil, das sich niemals neue und alte Bilder miteinander vermischen. Es kommen immer nur weitere Ordner dazu, der Inhalt der bestehenden Ordner bleibt immer gleich. Das Auffinden eines speziellen Bildes gestaltet sich allerdings schwierig, wenn man nicht ungefähr weiß, wann das Bild aufgenommen wurde.

Ebenfalls weit verbreitet ist ein Ordnungssystem, welches auf dem Bildinhalt basiert.  Jedes einzelne Bild wird dabei durch eine Anzahl einzelner Schlagwörter verknüpft. Wenn man den Aufwand nicht scheut, wird man damit belohnt, das Bilder, die thematisch zusammengehören ohne größere Probleme lokalisiert werden können. Neben dem hohen Aufwand hat dieses System aber auch Nachteile. Nicht ganz einfach ist das Festlegen der Schlagworte, denn diese müssen aussagekräftig und auch bei späteren Verschlagwortungen von ähnlichen Bildern wieder gleich sein. Es nützt zum Beispiel relativ wenig, wenn die Hälfte der Bilder mit dem Schlagwort „Spatz“ und die andere Hälfte mit „Feldsperling“ versehen wurde. Logische Problemlösung dafür ist eigentlich, alle Bilder mit den Schlagworten „Spatz“ und „Feldsperling“ zu versehen. Damit steigt allerdings der Aufwand für die Verschlagwortung weiter an und trotzdem ist die Gefahr, kein Schlagwort vergessen zu haben, nicht ausgeschlossen.

Ein weiteres Prinzip ist nutzbar, wenn zu den Bildern GPS-Informationen vorhanden sind. Dann können Bilder, die am gleichen Ort aufgenommen wurden, in eine Kategorie geordnet werden. Vorteilhaft ist, das dabei Kartenansichten erzeugt werden können, in denen man relativ leicht navigieren kann. Für die Suche nach Bildinhalten bringt das System nur dann Vorteile, wenn sich der Bildinhalt eindeutig lokalsieren lässt. Das „Brandenburger Tor“ kann eben nur in Berlin aufgenommen werden, ein „Spatz“ findet man dagegen wohl in jeder deutschen Stadt.

Als viertes System könnten automatisch bestimmte Parameter genutzt werden. Es könnten Beispielsweise alle Bilder nach ihrer vorherschenden Farbe geordnet werden. Alle Bilder einer Banane würden so in die Kategorie „gelb“ eingeordnet werden. Vorteil eines solchen Systems ist, das es ohne großen Aufwand umgestetzt werden kann. Leider ist es aufgrund automatischer Parameter nicht möglich den Inhalt des Bildes zu erkennen.  Nicht alle „gelben“ Bilder zeigen Bananen und alle Bananen sind auch nicht „gelb“. Unreife Bananen sind „grün“ und würden leider in einer anderen Kategorie landen.

Weiterhin könnten Bilder noch nach Parametern geordnet werden, die während der Bildaufnahme mit gespeichert werden. Solche Parameter wären zum Beispiel: verwendete Kamera, Brennweite oder Belichtungszeit. Da ich denke, das solche Systeme kaum genutzt werden, werde ich darauf jetzt nicht weiter eingehen.

Was bedeutet das nun für eine Bilddatenbank und für das BVASystem im Speziellen?

Der große Vorteil einer Bilddatenbank liegt darin, das nicht nur ein Ordnungsprinzip genutzt werden kann. Durch eine Mischung von mehreren Systemen kann das Auffinden eines Bildes erleichtert werden, da die Nachteile der einzelnen Systeme nicht so sehr zum tragen kommen. Vielleicht erinnert man sich an das ungefähre Aufnahmedatum des Bildes, welches man gerade sucht. Oder man hat genau den Ort vor Augen, wo das Bild aufgenommen wurde. Im Idealfall führt jede der Suchanfragen zu dem gesuchten Bild.

Ziel des BVASystems sollte es sein, möglichst alle Ordnungsprinzipien zu ermöglichen. Dabei soll der Anwender aber nicht in ein starres Konzept gepresst werden, welches wahrscheinlich nicht seiner Wunschvorgehensweise entspricht. Es gilt also einen Mittelweg zu finden zwischen einer kompletten Freiheit und einer selbsterklärenden Struktur.

Die Fotoalben sind ein erster Schritt um dieses Ziel zu erreichen. Durch die Fotoalben habe ich dem Anwender ein System geschaffen, mit dem er selbst eine Mischung aus den oben genannten Prinzipien umsetzen kann. Mein Beispielbild aus der Ankündigung der Fotoalben vermischt die Prinzipien der inhaltlichen („Urlaub“) und zeitlichen („Alpen 2002“) Ordnung.

Fotoalben im Rubrikenbaum

Weiterhin ist bereits eine fest vorgegebene zeitliche Ordnung nach dem „Aufnahmedatum“ in dem Programm integriert, welches beim Aufbau keinerlei Benutzerinteraktiv benötigt. Das System wird einfach beim Import der Bilder mit erstellt.  In der Zukunft werde ich das BVASystem sicherlich um das eine oder andere fest vorgegebene Ordnungssystem erweitern. Welche das im genauen sein wird, kann ich noch nicht sagen. Ein System zur Verschlagwortung der Bilder wird aber auf jeden Fall mit dabei sein.

Vergleicht man die Softwareentwicklung mit einem Hausbau, so kann ich sagen, dass mit der neuen Programmversion das Zimmer für Fotoalben im Rohbau fertig ist. Generell sind alle Funktionen, die ich geplant hatte, umgesetzt. Es fehlt aber hier und da noch die Tapete, damit das Zimmer wohnlich wird. Um zeigen zu können, was fertig ist und was nicht, möchte ich kurz das Fotoalbum-Konzept vorstellen.

Beim Import eines Bildes in die Datenbank, wird es automatisch an der jeweiligen Stelle im Aufnahmedatumbaum abgelegt. Dadurch kann man recht schön auf Bilder zugreifen, von denen man noch ungefähr in Erinnerung hat, wann sie entstanden sind. Aber wenn man auf der Suche nach einer Bilderserie ist, die man zeitlich nicht mehr so recht zuordnen kann, dann sucht man die berühmte Nadel im Heuhaufen.

Mit den Fotoalben soll die Möglichkeit für eine zweite Ansicht auf den Datenbestand geschaffen werden. Bilder, die während eines Urlaubs gemacht wurden, können zum Beispiel im Fotoalbum „Nordseeurlaub 2011“ abgelegt werden. Damit die Fotoalben übersichtlicher werden, können sie hierarchisch aufgebaut werden. Für das Urlaubsbeispiel heißt dies: Es wird das Fotoalbum „Urlaub“ angelegt und als Unteralbum das Fotoalbum „Nordseeurlaub 2011“. Dort kann dann wiederum ein Unteralbum für jeden Ausflug angelegt werden. In der Art und Weise, wie der Anwender seine Fotoalben anordnet, macht das Programm keinerlei Vorgaben. Wer im Extremfall die  Fotoalben nicht benötigt, benutzt sie einfach nicht.

Um mit den Fotoalben arbeiten zu können, sind mehrere Funktionen notwendig: Es müssen Fotoalben angelegt, umgeändert und gegebenenfalls auch gelöscht werden können. Weiterhin ist es notwendig, das Fotos mit Fotoalben verknüpft werden können. Das Konzept sieht hier vor, das ein Foto auch zu mehreren Fotoalben gehören kann. Und zu guter letzt müssen die Fotos, die einem Album zugeorndet wurden, auch angezeigt werden.

Alle diese Funktionen sind in der neuen Programmversion 2.0.0.18 umgesetzt. Allerdings fehlen noch einige Feinheiten. So ist es zum Beispiel nicht möglich, das übergeordnete Album eines Albums zu verändern. Aktuell wird das übergeordnete Album noch nicht einmal angezeigt. An der einen oder anderen Stelle wird es sicherlich noch Änderungen an der Oberfläche geben, da die jetzige noch nicht perfekt ist.

Eine weitere Idee von mir ist, das alle Bilder, die keinem Fotoalbum zugeordnet wurden, in eine Art „virtuellen Schuhkarton“ geworfen werden, damit man als Anwender leichter sehen kann, welche Bilder noch nicht sortiert worden sind. Eine ganz große Idee, die das Sortieren erleichtern wird, wartet ebenfalls noch auf ihre Umsetzung. Dazu aber erst mehr, wenn ich sie umsetzen werden.

Screenshot der Bilddatenbank BVASystem 2.0.0.18

Für die nächsten Wochen habe ich mir vorgenommen, die Feinheiten der Fotoalben links liegen zu lassen, um stattdessen den Rohbau für ein weiteres Zimmer erstellen zu können. Beim Benutzen des Programmes ist mir aufgefallen, das die waagerechte Anordnung der Thumbnails nur bedingt geeignet ist, wenn man auf der Suche nach einem bestimmten Bild in der Liste ist. Daher möchte ich eine zweite Ansicht schaffen, in der es kein großes Vorschaubild gibt und der Platz stattdessen für eine Matrix auf Thumbnails genutzt werden kann.