In this chapter, a CBIR design based on previous work of the author (Pein, 2008) is presented. The available system already allows for a retrieval by a query string (Pein, Lu, & Renz, 2008a). In the context of this investigation, the system has been extended to support alternative user interfaces as well as a testing module used in the case studies below. Being a pure research prototype, the retrieval engine is optimized for generating accurate results in order to have a reliable data foundation. Further, the query language syntax and the constraints for a practical application of the learning algorithm are presented.
TopRetrieval Framework Design
Most retrieval systems follow a basic work flow cycle (see section Methods-Browsing). A successful retrieval is performed as follows: users submit a query to the engine to trigger a search and receive a set of results. Those results may be satisfying and the user finds the required information. If not, the user may navigate through the results and eventually refines the previous query to trigger a new search.
Figure 1 illustrates the internal search steps performed by the retrieval engine. Three different abstraction levels are employed (Pein, Lu, & Renz, 2008a).
Figure 1. Layers in the retrieval process (Pein, Lu, & Renz, 2008a)
At a very high abstraction level, a simple retrieval system receives a query from the user, parses it somehow to understand the meaning, gathers the most relevant documents and finally returns them. This work flow is very common and can be offered by a generic framework, which simply offers all the basic functionality required. These framework components do not have to be specialized. They only need to understand standardized input and generate standardized output. All the details and optimizing are meant to be implemented in exchangeable plug-ins on the use-case dependent implementation level.
MAIN COMPONENTS
The main components of the system and their dependencies are presented in Figure 2. This diagram is a simplification of the true dependencies to ensure readability. Every single component makes use of “util.” Several system components developed for the preceding master thesis have been extended within this part: “core,” “admin,” “client,” “util,” “plugins,” “web” and “server.” These have mainly been extended by an optional indexing structure for the plugins, XML support and additional interfaces. Completely new are the components “parser,” “tester” and “composer.”
The “core” component contains all CBIR data structures. It also defines the generic interfaces for the “Framework Components” in Figure 1. The “util” is a loose collection of several useful methods that are required in several other components. The “plugins” are a collection of optional fv implementations. They are essential to make the CBIR work, but the choice of these plug-ins is up to the user.
The other components provide the actual realizations for work flow and user interfaces. “server” and “parser” are purely to provide the work flow. The “server” encapsulates the linear retrieval work flow of Figure 1. It accepts queries, forwards it to the “parser,” performs the retrieval and returns the results.
The “admin” component encapsulates the functionality to manage the image repository. The main tasks are adding new images and extracting the fv. This information is written into the repository for later use by the retrieval software.
The retrieval components usually require read-only access to the repository (without relevance feedback). Two retrieval clients have been developed by the author of this part. A fat client solution is contained in the “client” package, containing a full graphical user interface to access the “server.” A thin client is provided by the “web” package, allowing to use the “server” without the need of installing special software on the client machine. The UI of this package is supposed to be minimalistic, containing a user interface for directly submitting query strings and displaying results. On top of this service, a graphical query building software — the “composer” — is provided.
A special component is the “tester.” It contains a collection of time-consuming algorithms for analyzing the repository and also for learning the query descriptors.