Horus architecture
This document gives an overview of the architecture and functionality of the current Horus implementation. The overview focusses on the implementation as is. It provides only a flavour of the design rationale. The aim is to provide a starting point for usage and extension of the functionality.
For more detailed information please refer to the reference documentation. And, of course, the answer is in the source code :-)
The core of Horus is a C++ library for image processing. The library contains classes for images, image sequences, histograms, BSplines, etc. The functionality of the core Horus library can be employed in several ways.
Horus architecture
The most direct way is calling the C++ functions from a console application. Within the C++ console application a user has complete access to the functionality but lacks flexibility in that changing the application requires recompilation. Also, there are no means for visualization of results.
Several graphical user interfaces are available that provide access to the C++ functionality in a more interactive way. The GUI's are implemented in Java to be portable and, in the end, suited for demonstrations via WWW. To facilitate development of these GUI's and new ones a set of common Java components is collected in a separate library. In the end, the components are to become Java beans to be used in a standard application development environment.
The Java Mdi application is specifically targeted towards researchers in the image processing community. It has a menu and dialogue interface to provide interactive access to most commonly used image processing operations and viewers to inspect images up to the pixel level.
The Video application is more targeted towards video processing. It has a simple interface that would also suit an end-user.
The Java GUI's communicate with the C++ library via CORBA (the Common Object Request Broker Architecture). To that end, the C++ image processing functionality is defined in CORBA's Interface Definition Language (IDL) and an HxServer has been build to translate the IDL requests to the corresponding C++ functionality. Client applications, e.g. the Java GUI's, have access to the server in all language bindings supported by CORBA.
The Horus functionality may also be used from within third-party software. CorbaScript provides direct access to all CORBA-based functionality (without additional effort on the Horus side). Since Matlab 6 (release 12) has a Java interpreter, the C++ functionality of Horus is accessible directly via CORBA.
Examples of how to use the various Horus applications are given in the next chapter.
This is really conceptual, not all is implemented yet :-)
From an (end-)users' point of view it is essential to have a clear definition of concepts used in the Horus system in order to master the functionality provided by the system. The concepts provide the user with a set of handles for interaction with the Horus system. An overview of the concepts is given in the figure.
Conceptual overview
Functionality within the Horus system is divided into two categories: HorusObjects and Detectors. Each data-entity used within Horus is called a HorusObject. Horus objects include the sensory data itself and the spatial entities present within the sensory data. Transformations on (a set of) HorusObjects are preformed by detectors.
A key issue in the design of Horus is the separation between semantics, representation, and implementation of HorusObjects. Semantics, represenation, and implementation are defined and implement by different classes. Typically, the class defining the semantics contains (a reference to) the class defining the representation which contains (a reference to) the class defining the implementation. Each class has its own set of admissable operations.
As an example, consider a HorusObject defining the age (in years) of a person as a number. For the represenation we take a natural number, i.e. x is an element of N. The choice for N also defines the set of admissable operations on x. The class defining the semantics of x, i.e. it is an age, typically modifies the set of allowable operations. Some operations may no longer be allowed, e.g. decrement, while others may be introduced, e.g. isAnAdult. For the implementation we might take an 8-bit integer if space is critical or a 16-bit integer to be on the safe side. Naturally, the situation is a bit more complicated when dealing with images instead of ages.
The next chapters provides a handle to get install Horus and to get started with the various components of Horus. The remaining chapters describe each component in more detail.
1.2.12 written by Dimitri van Heesch,
© 1997-2001