Interaction is an important part for image based medical applications. This is true for intervention planning, assistance systems for medical interventions, for manual and semi-automatic segmentation as well as to adjust automatic processes for segmentation or registration tasks. MITK has a new, generic interaction concept to structure and by that standardize the manipulation of data and artificial objects in 2D and 3D views.
Interactions are reactions of the software on user input. Since their many types of input devices (e.g., graphics tablets, tracking systems, etc.), the first step to standardize is to create abstract events out of device dependent events. The next step is to interpret the meaning of the event, which often depends on the state of the software. Even the rather simple case of building a polygon and subsequently interacting with it has multiple states (building-in-progress, point-is-selected, point-is-being-moved, etc.). MITK's unique interaction concept is organized by hierarchically defined state machines and allows to describe and configure states and state-transitions in a consistent way in XML-files, which are loaded during run-time.
That way it is possible to load different interaction behavior used in familiar medical manufacturer software (e.g. Siemens Syngo, Philips Easy Vision, GE Advantage).
Furthermore it is possible to easily adapt the behavior to specific applications and workflows.
|
Fig 1 Overview of the interaction concept. Events from different event sources (e.g. graphics tablets, tracking systems etc.) are converted into abstract events by the singleton class EventMapper. This class transmitts the events to the singleton GlobalInteraction. According to its internal state this state machine delegates the events to the dedicated Interactor-objects. The manipulation of the data is achieved through the creation of Operation-objects, that are send to a specific Data-object. Here the operation is executed. Additionally, the Operation and its associated Inverse Operation (undo-operation) are send to the UndoController, which stores the operations according to the undo-model. In case of an undo, the inverse operation is send to the data and restores the previous status. |
