To accomplish requirement 1 the system should be able to flexibly combine concepts and algorithms in order to establish registration methods by using independent main pillars as stated by Maintz et al. [1]. Unlike the original ITK, the flexibility does not end with the compilation of the program. This flexibility should not be achieved by using simply a scripting language, in order to suit the individual needs of different user groups. A script-based approach may be well-suited to a scientific environment, but when it comes to integration into daily routine, it would be clearly out of scale and not appropriate for the common clinician. A kind of semantics, helping to find reasonable combinations, is also desirable. The second requirement is an open system with embedding facilities, in order to allow the easy integration of new components and ideas, so as to ensure applications that can more easily evolve with scientific progress. To establish an evaluation basis (requirement 3), protocols and tools are needed that allow analysis, optimization and comparison of the efficiency of components or image processing methods. To avoid problems of lacking comparability, it should be possible to exchange and import methods as well as test data. This achieves exchangeability (requirement 4) of ideas and comparability of results.
The main focus of the developers is the engineering of new registration algorithms and components. They need an open system for the quick integration of new component ideas. They want to achieve short development cycles and they also need evaluation facilities for the basic evaluation of the component functionality.
Scientists are focused on solving new matching tasks. They assemble and optimize new registration methods, and finally there has to be the possibility to test, compare and optimize the different approaches.
Clinicians want an application for solving problems in daily routine. Therefore they require a program with good usability within their workflow. It should be a streamlined and simple application, which does not offer confusing options for adjustment but has an intuitive front end and, preferably, evolves with the user’s demands. This would mean only minor changes in workflow when new problems need to be solved.
Surely it is possible to design suitable, but non-coherent, tools for every single group. But interaction problems between the groups and their tools would mean a needless loss of synergy. A scheme illustrating the nature of interaction between the user groups is stated in Fig. 1. It shows how development of new approaches is driven by demands of the clinicians or rather the part of the option space really needed for their problems. Starting at the developers there is an ongoing process of specialization from the total multitude of possibilities (methods, their combination and parameterization) to the clinically needed option set, presented by a specialization corridor. Having a framework accompanying through all groups is one effective way to ensure that this condition is met.
Fig. 1: user group interaction scheme
1.5.3 written by Dimitri van Heesch,
© 1997-2000