Problem
A weakness of the current DICOM loading implementation is the process that loads a collection of 2D DICOM slices into a single image volume. This process sorts files to some extent into belonging volumens (differentiating groups of different orientation, size or slice thickness). However, it does not check consistent slice distance. Instead it takes the first two slices of a group (spatially sorted), calculates the origin and slice distance for a whole image block and then fills in all remaining slices without checking that they actually fit in the assigned position.
Possible problem: with this logic, some slices might be displayed to the user in a 3D position where they do not actually belong. I.e. the DICOM information would report position A, while the corresponding mitk::Image slice would report a different position B.
This behavior is a possible source of error, when secondary data (e.g. ROI measurements) is generated for 3D positions that mismatch with DICOM positions. The error only becomes apparent when later the previously missing slice is added and some of the mitk::Image slices would be loaded from different DICOM slices.
Attached is some ASCII "art" depiciting a possible error.
Suggested Solution
We need to improve the class DicomSeriesReader, which implements the loading of a series of DICOM files into mitk::Images. The class should be able to handle the situation above correctly by
- either 'fill in' the gap with slices clearly marked as artificial
- or separate the two parts into separate mitk::Images
This should be done depending on how big the gap is. Clearly, filling in more slices than the actual two parts cover is not meaningful. A sensible algorithm should be implemented to decide between the two options.