Introduction
This page explains how the NiftyView GUI fits together, covering the high level concepts. While it is simple to put together a single ITK or VTK pipeline, it is much more challenging to make a modular extensible application. For this reason, it is necessary to utilise various frameworks to provide structure and methodology so that future code can be easily plugged-in and the application continue to grow in a comprehensible fashion.
The Common Toolkit (CTK)
The Common Toolkit (CTK) provides various components that might be useful in any medical imaging application, such as the Qt widgets developed for Slicer 4, DICOM query/retrieve using DCMTK, DICOM application hosting (under development), a plugin framework based on the OSGi specification, an Event Bus based on the OSGi specification and so on. The CTK project is built in a modular fashion so that a third party project can select exactly which parts to build, as it is unlikely that an application will need them all. NiftyView uses
- The Plugin Framework for a clearly defined plugin model following OSGi specifications.
- The Event Bus for broadcasting events between plugins.
- Some of the Qt widgets.
The Medical Imaging Toollkit (MITK)
The Medical Imaging Toolkit (MITK) provides a more high level set of functionality than CTK, and MITK uses CTK quite extensively. For example, MITK provides an ortho-viewer editor, enabling a 2x2 image viewer, with a synchronised axial, coronal, sagittal and 3D view. However, it supplies this within a CTK plugin. Of the many things that MITK provides, NiftyView uses
- The main window and menu bar.
- Image viewers, providing easy slice views, 3D views, outline of binary masks, rendering of surfaces, points and meshes.
- A DataStorage to manage a tree like structure of data items.
- A PreferenceManager singleton that uses Qt to store user preferences.
- A GlobalInteraction singleton that manages a State Machine based interactor pattern for easy manipulation of data.
- A FocusManager singleton to keep track of which window has focus.
- The Undo/Redo framework.
- Macros to make easy use of ITK filters.
So, for the large part, NiftyView is based on the MITK framework, and hence uses CTK as a consequence.
Conceptual Overview of NiftyView
At this point, a high level view of NiftyView may provide helpful. Figure 1 shows how NiftyView can be understood conceptually.
Imagine that all data currently visible in the NiftyView GUI has been loaded from disk into a DataStorage. The DataStorage therefore is the single repository for all the data. Data can be images, surfaces, pointsets and objects such as lines, polygons or contours. Each piece of Data is associated with a DataNode. The DataNode can have properties such as colour, opacity, line thickness and so on. The user can create any number of new properties and store them on each DataNode. Thus the DataStorage, with each piece of Data, stored on a DataNode with all the properties is the Data Model. It should be considered as the Model part in a Model-View-Controller (MVC) pattern.
MITK provides various windows called "Editors" that enable a certain view of the data. Each of these editors is provided as a class within a CTK plugin. The main editor is the QmitkStdMultiWidgetEditor which provides the default orthogonal image viewer component. NiftyView has added an additional editor the niftkMIDASMultiViewEditor which provides a viewer that acts more like the MIDAS application with drag and drop functionality, and multiple panes. So several Editors are providing different views of the data and can be considered the View part of the Model-View-Controller pattern. However, in addition to this, for those readers familiar with the Eclipse RCP project, and the OSGi specification concerning how the workbench is assembled, the term Editor is more appropriate. When a file is selected, the file type determines what editor can be used to view and edit it. For example in Eclipse, a .cxx file is known to be C++, and so a text editor with C++ formatting is opened. In the case of NiftyView, the data is typically images, surfaces, meshes or points, all of which need rendering. So, both the default editor and the MIDAS Drag and Drop editor all display these types of data. But the concept is also naturally extensible to things like a python console. So if a python text file was loaded it could be associated with the right editor due to the underlying OSGi framework. So, we keep the term Editor for the main windows displaying data as the term is a bit more generic.
The final part in the Model-View-Controller pattern is the controller. The controller takes user input, converts this to some set of updates to the Model, and then requests that the display components re-draw the Model. In the original original MITK paper, the controllers were called "Functionalities" and are nowadays called "Views" implemented as CTK plugins with a Qt front end. Within the NiftyView GUI, the list of available Functionalities or Views can be found under the Window menu. Each of these Functionalities is delivered as a separate plugin, and for new development, the developer will usually focus on which new Functionalities need developing to satisfy a particular purpose. In addition to Functionalities, it can be seen that mouse clicks and key-presses in the main editor windows also produce an effect. This is because there is a controller component called GlobalInteraction which listens to Qt events. These are forwarded onto the GlobalInteraction singleton which can then distribute events to any number of StateMachine observers. This interaction pattern is further described here along with the related concept, the Undo/Redo pattern.
To summarise: Figure 1 illustrates then that the GUI revolves around the MVC pattern. Within each View (Functionality) or Editor (data viewing) component, the user can additionally lookup various services such as the FocusManager, GlobalInteraction, PreferencesService. Examples can be found in the MITK base class QmitkAbstractView or QmitkAbstractRenderEditor. MITK uses Singleton's but are currently migrating towards Micro-Services, which can be considered like Singleton's but with a more managed lifecycle.
