Multi-frame series work well in ITK as far as I am aware.
There were a few recent improvements for some exceptional image geometries:
If there is an image geometry / series type that exists and is known to not read correctly, then we should look into fixing it. However, performing geometry checks for the sake of geometry checks can have performance downsides that dramatically impact user experience. We do not want the experience of loading DICOM files to be painfully slow.
@thewtex Thanks for the information, this all sounds promising. Unfortunately, even clinical device manufacturers misuse the DICOM standard in every possible way, so consistency checks are necessary for safety-critical applications. Performance of course is important, too - maybe that can be addressed by making some checks optional.
@dzenanz can you tell us if the reader sorts the individual frames of a multiframe object geometrically, since you worked on that part recently?
I canāt think of a use case when it makes sense to not sort image slices geometrically while reconstructing the volume. What is the alternative - to keep the fingers crossed?
Iāll note that the issue of non-geometrically sorted frames in a multiframe document comes up for data created from converters that read and concatenate the frames read from disk that is, for example, sorted by filenames or directory (inode) order. I suspect the reason sorting isnāt usually needed is that modalities would typically output sorted frames.
The ādefensive programmingā thing to approach would be to have both (1) the converter sort the frames to work with systems that typically only see sorted frames and (2) the reader sort the frames to handle converters or modalities that donāt provide sorted frames.
Of course, sorting correctly can require heuristics or further user input so thereās no 100% solution for these issues.
I just donāt know how accurate that statement is. Following the same reasoning, one might not sort geometrically non-multiframe series and instead rely on InstanceNumber or some other assumption (or wait - is this what ITK has been doing already for reading non-multiframe series, and Slicer sorts them outside of ITK because of that?).
I agree that disabling sorting makes sense, once the user established that the specific equipment produces sorted frames, and no sorting is necessary. But I still donāt think that by default it should be disabled.
I also think it is time to split this topic - I am afraid we veered off the topic and might have lost the user and the actual problem they wanted to get resolved.
@fedorov I didnāt suggest not sorting frames, just explaining why the issue probably hasnāt come up much in practice. In my (admittedly very limited) experience Iāve only ever seen non-sorted frames come from converters.
I agree. In my (even more limited) experience, I have never encountered multi-frame series produced by the clinical applications I worked with. I think it is hard to get a grasp of how important it is with very limited adoption of multiframe by modalities.
Also, it is not clear if sorting is disabled, or it is just not implemented (as it has not been implemented for non-multiframe series).
I donāt think itās disabled on purpose, I think itās just a very different code path.
In ITK, the itk::ImageSeriesReader processes in a series of images. These images should already be sorted. They can be sorted with any desirable strategy beforehand.
For example, ITK provides itk::DCMTKSeriesFileNames, which is a nice default. This works by:
This class generates a sequence of files whose filenames points to a DICOM file. The ordering is based on the following strategy: Read all images in the directory (assuming there is only one study/serie)
- Extract Image Orientation & Image Position from DICOM images, and then calculate the ordering based on the 3D coordinate of the slice
- If for some reason this information is not found or failed, another strategy is used: the ordering is based on āImage Numberā
- If this strategy also failed, then the filenames are ordered by lexicographical order.
If multiple volumes are being grouped as a single series for your dicom objects, you may want to try calling ->SetUseSeriesDetails(true) prior to calling SetDirectory().
Slicer could also use a more complicated or different strategy, too.
If the images have already been sorted by the time they are ready to be passed to the itk::ImageFileReader, then I do not think they should be sorted again. This is an opportunity for conflicting behavior and it negatively impacts performance. While some of the best DICOM support around can be found in Slicer, a common criticism is that it is too slow for users ā we should try to improve this 
.
Slicer needs to handle more than just images. Some of the data objects cross-reference other objects (by DICOM UIDs), which can be loaded in any order or may be missing - to resolve all these we need to maintain a database. We also need to handle ambiguities in how to interpret a data set. Often there are many interpretations, some of them are most likely to be correct than others, but you cannot choose the most likely solution until you investigated all options. Database building, reading, testing hypotheses about best interpretation, etc. take time - probably magnitudes more time than consistency checks or sorting of frames. If we lock things down (e.g., disable DICOM plugins that you are sure you wonāt need; load files without DICOM database import) then we get better performance, but by default we prioritize flexibility over performance.
Still, Slicerās current DICOM import and loading speed currently is about at the level of industry standard. It was noticeable slower about half year or year ago, but we then successfully identified and fixed some performance bottlenecks.
Of course, things can be improved further. However, instead of shaving a few percent off from raw DICOM image reading times, we plan to focus on reducing ātime to first imageā by showing thumbnails, using DICOMDIR files, etc. in the DICOM browser.
@lassoan You were right, after changing the settings i see all of the loadables in a list, each having different content time in the advanced tab.
It loads the content, but not correclty, the slices are displayed as the image data matrix had a wrong datashape (canāt explain better) but see pic below:
Iāll make an anonimised data set and upload it soon.
@fedorov
I havenāt modified any of the files, i left them in the structure as it was exported from the software.
ā¦ not THIS user
Yes, exactly - this is a nice heuristic for sorting files, but what @fedorov mentioned is the case where you have a multiframe object in a single file, but the individual frames are not geometrically sorted. Itās a valid point that the standard allows many different frame orderings so the same kind of sorting heuristics could/should be applied to soft the frames as they are to files.
I know I will sound as a broken record ā¦ but is the result of conversion with dcm2niix and plastimatch convert any different?
I donāt know if this is a new development, or if it was not considered for use in Slicer in the past for any reason, but if it works as stated, it should be considered to replace the sorting implemented in the Slicer scalar volume DICOM plugin then.
I believe this is basically the same code that has been in itkGDCMSeriesFileNames from the very early days, which Slicer does use. As @thewtex says, this code requires that all the files be in one directory and that the directory contain only one series. This simply does not match the way many people have their data. Very often multiple series are in the same directory. And also very often (such as a DICOM exported CD or DVD) the files that make up a series are spread out across subdirectories.
The DICOMScalarVolumePlugin (and others) use the database and heuristics to create loadable chunks that correspond to the data that Slicer will be able to digest and then gives the user options about which are passed to ITK for loading.
It is worthwhile to try improving ITKās implementation to relax some of the constraints and handle more scenarios, but itās fairly big job and several previous efforts havenāt worked out too well, which is why there is still the legacy GDCM reader path in parallel with the newer but differently incomplete DCMTK path in ITK and exposed in Slicer.
If you look at the /vtkITKArchetype* classes in Slicer youāll see that a lot of the code involves instantiating the ITK readers across all the range of possible image types that might be discovered from parsing a dicom series, but even this (very large) set doesnāt handle all the other cases that one might want to load from a dicom study (like SEG, PM, or various types of timeseries images).
One more point: the whole code base could obviously benefit from a fresh start, but as has been noted many times in the past, we donāt have any way to really test a new implementation. The existing implementation was developed to read data that we donāt have access to (and we never will have because much of it private patient data or was otherwise not public).
How to load using ITK Series reader?
If you drag-and-drop a single file to the Slicer application window and you are not in DICOM module then the ITK series reader is used for reading the DICOM file. This method is not recommended and may result in incorrect loading of the DICOM data set.
