gms | German Medical Science

In clinical research and routine, the analysis of medical images using computer based image processing tools leads potentially to an easier to apprehend visualization and to more precise quantitative results. Often, basic or at least well known image processing algorithms are sufficient to satisfy the needs of the scientists. However, prevalently, commercial solutions do not include all desired algorithms and are not sufficiently flexible to be combined with other commercial products as no access is provided to the required interfaces. On the other hand, image processing research groups develop usually software for highly specialized algorithmic problems even though access to all data would be available. The Insight Segmentation and Registration Toolkit (ITK, [Ref. 1]) and the Fast Light Toolkit (FLTK, [Ref. 2]) aim to fill this gap. They provide a template based C++ class framework containing, principally, known image processing algorithms near to the state of the art and classes to build a graphical user interface (GUI) with an interface to Open GL and VTK for 2D and 3D visualization.

Currently, not all domains of image processing are covered by ITK. Furthermore, as the ITK-FLTK example applications illustrate [Ref. 1], there is no commonly accepted concept how to build a modular image processing platform serving for scientific research and prototyping with contributions from different and varying persons from students to senior scientist. Other problems coming with ITK and FLTK are an insufficient documentation and a difficult installation procedure. The development using FLTK requires the use of a code generator (called FLUID, [Ref. 3]) because of the complexity of possible options and functionalities. The aim of this paper is to propose such a concept for building a platform for multimodal registration. It may serve as one guideline for the development of other medical image analysis platforms based on ITK and FLTK.

Our concept for the design of a modular image processing platform using FLTK and ITK comprises two principal points. One point concerns the separation of algorithms processing images from code containing FLTK classes, in particular from FLUID generated code. Secondly, we developed a concept to split the GUI into different groups instantiated inside a general frame GUI. In most ITK-FLTK applications which are provided on the official ITK Homepage [Ref. 1] the separation of FLUID classes is realized by defining a class as a child class of the FLUID generated class and by implementing the procedures called from the GUI (e.g., by clicking on a button with the mouse) in this class. This presents an unnecessary derivation and a misuse of the concept of derivation as the FLUID class is no abstraction of the child class. As, for instance, the "AnisotropicDiffusionFltkGui3D" project presented in [Ref. 1] shows this unnecessary derivation misleads developers to define even a base class from which in turn the GUI class is derived and to put the image processing filters into it. The drawbacks are (a) that changes in the base class require generally changes in the derived classes, (b) that the modification of the base class' parameters in methods of the derived classes may have side effects on the algorithms, and (c) that parameters in the base class changed during a first run of an algorithm my have side effects during a second run.

Instead, we defined two classes (for each GUI group, see above) which are independent concerning the class hierarchy but each of them is declared as friend and as element of each other. One is the FLUID class and the second one (the Interface class) manages the call of procedures invoked by the GUI and the communication (exchange of data) with the FLUID class. These procedures instantiate FLTK free classes implementing the algorithms and delete the created instance when the algorithm terminates. The management of the spatial data (images, point set, etc.) to be kept in memory is done by a FLTK free class (called SpatialDataContainer) connected with the Interface class using the concept of design patterns [Ref. 4]. To split the GUI we defined an autonomous GUI (with a FLUID and Interface class, called SpatialDataDisplay classes) implementing the display of spatial data which we instantiate twice inside a general GUI frame. To manage the communication of the display GUI with the general GUI frame we implemented a base class of the Interface class of the GUI frame which is an abstraction of each potential GUI frame inside of which the display GUI could be instantiated. Therefore, the display GUI can be used in many other programs as well.

Implementing the concept presented roughly in the methods section, we obtained a modular software platform suitable to be extended by different users independently and in parallel. Classes implementing algorithms for the manipulation of spatial data can be extracted and inserted into other, FLTK independent, environments without modification and with elementary data structures as an input. Classes as the SpatialDataContainer and the spatial data display classes are sufficiently autonomous and general to be used in other ITK and FLTK based medical image analysis applications. In several cases ITK algorithms could be directly called from our Interface classes. When implementing (according [Ref. 5]) the paired point matching (not yet implemented in ITK) we used all foreseen ITK data structures and methods related to them (a point set registration class recently added to ITK but not yet in ITK 1.4 did not fit in our case). Here, it turned out that it is worth to think about implementing the essential parts of the algorithms in ITK free manner such that they can be used on computers where ITK is not installed (see previous sections).

An application for routine use in clinical research was derived from this general platform [Ref. 6], [Ref. 7], using two instances of the SpatialDataDisplay classes with image and point set file input and output, several basic image manipulation features as well as the possibility to set landmarks interactively [Fig. 1]. The SpatialDataContainer allows managing the 3 original and the obtained processed images together with the respective landmark positions in memory whereas only two are displayed. Routines to register the landmarks and to transform the images according to them, for overlaying and for subtracting images are called from a general menu frame. In the future we aim to share our source code with the ITK community and to integrate our new ITK classes for paired point matching into a future release of ITK.

ITK and FLTK are useful toolkits to develop a modular image processing framework. Establishing a general, modular registration platform and deriving an application, which is usable within the clinical routine, was substantially simplified in comparison to a development from the scratch. Our concepts, predefined C++ classes, and new ITK classes shall help to further simplify the work of future developers and to make it possible to develop applications for specific clinical questions in reasonable time.

This work was supported in part by the FFF (Forschungsförderungsfonds für die Gewerbliche Wirtschaft), Austria.