Main concepts

In the following there is a description of the main concepts of f.r.e.e..

Overview of the main concepts of f.r.e.e.

Controller

F.r.e.e. has a controller concept which wraps all components and serves as a generic interface. This interface defines a unified set of possible procedure calls that allows the framework to interact with the controller and make use of its controlled component. The controller creates its assigned component and manages the data retrieval and data actualization. So in the terms of design patterns a controller is an adaptor and builder for the instances of the controlled component.
The controller concept also handles the integration of new components and registration strategies. Therefore, a controller can be integrated dynamically into the framework at runtime. The framework will look for any controller provided for import of such new elements and, if it finds one, add an instance of this controller to the controller pool. Hence it adds the ability to create and handle a new idea by using the associated controller. Thus applications using the framework do not need to be recompiled to extend their method inventory.
The basis class of all controllers is ComponentControllerBase. All other controllers are derived from this basis class.

Profile

Each controller has a specific profile. Among other things, this profile defines the structure of the generic setup part that corresponds to the controller. The profile of a controller (an XML (eXtensible Markup Language) [1] template shown in Fig. 1) is structured into three thematic sections. Section 1 contains the general information (unique ID of the controller, derivation information, etc.) about the component. Section 2 defines the correlated generic setup part (e.g. parameters and their default values, possible sub-components; for generic setup see below). This information will be used to generate the corresponding generic setup part (Fig. 2). The information in section 3 defines all requirements of a component in relation to other parts of the setup. Hence this section is responsible for establishing an ontology, which describes the semantic coherence between components. For the definition of requirements or constraints, any information from the first two sections can be used as criteria (e.g. the ID of a component, existence or value of a parameter, etc.). An example for such a scenario which uses the ontology realized by the profiles is the tool freeSetup (e.g. the editor only offers optimizers that are able to handle quaternion-based rotations, if the user has chosen a quaternion-based transformation).
While section one of a profile is always constant for a controller, section 2 and 3 may depend on the current generic setup, thus a value of the controlled component itself (e.g. sub-component “Sub2” is only needed if Parameter “UseSub2” is true) or any other part of the setup. These context sensitive profiles are realized be the controller concept as well.

Generic setup

In order to describe a complete registration method, a structured data format was defined and named “generic setup”. A generic setup can be stored in a well defined XML file including an associated schema definition file to ensure validity. Generic setups define the components to be composed, their combination and the setting of their parameters to represent a registration method which can be executed by f.r.e.e. (see Fig. 2). The ontology of the generic setup (combination of components, number and type of parameters) is not predetermined. Its complexity depends on the components used and is handled by the corresponding controller and their profiles.
Every part of a generic setup can be addressed and accessed by f.r.e.e. in an XPath styled manner. This feature is important for example for the controller ontology definition and is utilized by the adaptation facility (see adaptation element / adaptation list).
To achieve even more complex (registration) approaches, any single registration method (e.g. multiresolution rigid registration) can be combined with others to define a series of consecutive image processing and registration steps. In this case f.r.e.e. is able to update registration information and media (e.g. reference point sets, regions of interest (ROIs), segmentations, image files) to assure validity in consecutive steps. These media are also components and therefore bound to controllers, which process the update.

Adaptation item/Adaptation list

A careful separation of case-specific data (e.g. images used, ROIs, segmentation information or coordinates of reference points) and registration information (basic concept described by a generic setup) is important in order to ensure exchangeability and comparability. Mixing the two would become a problem in terms of exchanging either the test data or the registration concepts individually. This is a problem stressed in several scientific papers, but nonetheless rarely handled properly, as also reported by these groups (cf. [2, 3, 4]).
F.r.e.e. supports this separation by its generic setup on one hand and adaptation items or lists on the other. The generic setup as mentioned above only contains the sheer concept. All case-specific information is stored per case in an adaptation item. This adaptation information is used to customize the generic setup to the single case. It is possible for the level of adaptation to range from a simple definition of the images involved to component-sensitive changing of parameter values. Like the generic setup itself, an adaptation is also structured as an XML file and can be evaluated by a schema definition file. After the adaptation of a generic setup, the case-specific adapted setup can be utilized by f.r.e.e. to compute a registration of the corresponding cases.
It is possible to group adaptation items to an adaptation list that can be used on generic setups. Therefore a generic setup can be adapted and computed/evaluated with a whole case set in one run.

Adapted Setup

When a generic setup is customized to a case by the case specific adaptation item it is called an adapted setup. Hence an adapted setup is an image processing approach (specified by the generic setup) and enriched with case specific information (like input images, regions of interest, reference points...; all provided by the adaptation item).

Statistic

F.r.e.e. offers the possibility to collect statistical informations of the processing of a setup The logged information can be arbitrarily detailed because the framework allows every controller to specify the information that he will log. The produced statistic files are XML files that can be validated via schema. These files can be easily transformed in different formats or representations by utalizing XSLT [5]. By default f.r.e.e. offers the following transformations:

• Processing Overview: Produces an html document which shows the sequence of processing steps with duration and detailed information (if present).
• Registration: Produces an html document which shows the registration progress in detail of every registration done in the sequence of processing steps.
• Evaluation: Produces an html document of evaluation results generated by the tool freeEval.
• Setup Optimization: Produces an html document which shows the optimization progress of a setup optimization computed by the tool freeSO.

Other transformations can be easily established by writing an adequate XSLT file. Examples for these transformations can be found in the example section.

Figures

Fig. 1: Example of controller profile saved as an XML file. Three main sections can be distinguished. 1. General information section: identifies the controller (“Controller_1") and its relationship to others (“AncestorController_1"…). 2. Generic setup section: defines the corresponding part of the generic setup; needed or allowed subcomponents ("SubComponent_1") or component parameters ("Parameter_1"). 3. Requirement section: describes demands ("Controller_2") on other parts of the setup ("./SubComponent_1").

Fig. 2: Example of a generic setup in XML form established by using among others the profile of Fig. 4. The dark box marks the part of the setup determined by the profile of "Controller_1". The light box selects the part determined by a sub component controller ("Controller_2_Descendant"). The choice of this controller (dashed box) was limited by the requirement section of the "Controller_1" profile

Literature

1. T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler and F. Yergeau, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, W3C.org (http://www.w3.org/TR), 2004.
2. J. B. West, J. M. Fitzpatrick, M. Y. Wang, B. M. Dawant, C. R. J. Maurer, R. M. Kessler, R. J. Maciunas, C. Barillot, D. Lemoine, A. Collignon, F. Maes, P. Suetens, D. Vandermeulen, P. A. van den Elsen, S. Napel, T. S. Sumanaweera, B. Harkness, P. F. Hemler, D. L. G. Hill, D. J. Hawkes, C. Studholme, J. B. A. Maintz, M. A. Viergever, G. Malandain, R. P. Woods and et al., Comparison and evaluation of retrospective intermodality brain image registration techniques, Journal of Computer Assisted Tomography 21 (1997) 554-566.
3. R. Woods, Validation of Registration Accuracy, in Handbook of Medical Imaging, pp. 491-497 (Academic Press, 2000).
4. P. Jannin, E. Krupinski and S. Warfield, Guest Editorial Validation in Medical Image Processing, IEEE Transactions on Medical Imaging 25 (2006) 1405-1409.
5. J. Clark, XSL Transformations (XSLT) Version 1.0, W3C Recommendation, W3C.org (http://www.w3.org/TR), 1999.

---