It is important to understand the project directory structure, the overall technology stack, and the dependencies between third party libraries.

Project Structure

The top level directory structure contains

Applications - Command line applications not depending on MITK.
Config - Various files that are generated into the build, or to setup the environment at runtime.
CMake - Contains CMake code to build all external projects, find external packages and set up ctest and cpack.
Documentation - Contains the User Manual and Technical Manual, generated using Doxygen.
Libraries - Libraries needed by applications in NifTK.
MITK - Graphical and command line applications using the MITK framework.
Scripts - Various Python, Bash and MatLab scripts.
Utilities - Various utility scripts.

It has become customary within the field of medical imaging research to write small, self contained programs, typically as command line applications. These command line applications demonstrate loose-coupling, and hence can easily be combined into pipelines of programs using unix / perl / python scripts. This can be clearly seen in the above directory structure. Furthermore due to the prevalence of Unix type systems, most researchers use a Unix or Mac operating system, and so currently bash scripts are the recommended scripting language, and the next alternative would be python.

Command line apps also allow a minimal entry point for researchers to contribute C++ code. A single file can be used to write a small application, for example using ITK filters, that can be self contained and easy to understand.

Technology Stack

It is important to consider the various third party libraries, with their various dependencies, organised in layers, which herein will be called a technology stack (Figure 1).

Figure 1. The third party libraries are used for a specific reason, and have an implicit layering, creating a technology stack.

In Figure 1, we have a hierarchical ordering of each of the third party libraries. It can be seen that each library has been assigned to a layer, according to its purpose. Each library must not depend on the libraries above it. Libraries can depend on the libraries below them. For example, GDCM knows nothing about ITK, as it is a library for reading DICOM images. ITK however can use GDCM to read DICOM images into an ITK data-structure. Similarly, the VTK library can be connected to an ITK pipeline, to visualize the results. So, logically speaking, VTK depends on ITK, but ITK code should never be concerned with how the data is rendered.

There are a couple of exceptions worth mentioning. If you download ITK v3.20, you will find adaptors for VTK classes, which seems to contradict the hierarchy above. However, the ITK-VTK bridge in ITK v3.20 is templated meaning that the code is not compiled unless it is instantiated, and so it can be safely packaged within the ITK code-base. Secondly, CTK is designed to be a general purpose library, but it always depends on Qt, as Qt contains a lot of nice code (smart pointers, memory management etc), written in a cross-platform way. However, there are two types of application within NifTK. Command line applications refer to libraries to the left of the blue line, and the NiftyView GUI additionally includes libraries to the right. Here, MITK can be build without Qt or CTK, and hence can be used in command line programs, or with Qt and CTK for building a GUI. So, we can see that by the time CTK is required, Qt will always be present for the GUI, so this additional dependency, not indicated in the diagram is OK.