Operating system: Windows 10, 64bit
Slicer version: 4.8.1
Expected behavior: load multiframe image data as (labeled) volume data (dose distribution and VOI)
Actual behavior: In the DICOM browser under advanced tab shows by examining that it is a Scalar Volume, and it warns that “Multi frame image. If slice orientation or spacing is non uniform, then the image may be displayed incorrectly. Use with caution. Reference image does not contain geometric information. Please use caution”
The above mentioned multiframe image data were exported from Simplicit90Y™ (Mirada). Below is the Metadata.
The Pixeldata should represent Dose Distribution and VOIs.
Normally segmentations are saved to DICOM as segmentation objects or RT structure sets (and can be loaded if you install Reporting and SlicerRT extensions). Is there an option to save into these standard formats?
4D volume import has been greatly improved after Slicer 4.8.1 was released, so if you don’t have any other export option then you can try that. You may also try loading by enabling “Advanced” option, clicking Examine, and choosing different loadables in the list at the bottom.
thank you for the answer,
sadly i have no more chance to export / save the datasets, but i’ll try with SlcerRT and Reporting and with the different loadables.
I’ll let you know how it goes!
I think the issue here could be imperfect support of multiframe DICOM objects in Slicer.
@Sandor_Konya what happens after you try to load the series, despite the warnings? Do you have a CT series corresponding to that labeled volume dataset? That way you could confirm that Slicer accurately interpreted image geometry.
You could also consider using plastimatch convert or dcm2niix to convert that DICOM series into NRRD or NIfTI format, and then load those into Slicer. I believe those tools are more robust than Slicer in interpreting DICOM multiframe objects (with the exception of DICOM segmentation object, but it is unlikely that is the object you have).
Of course, if you have a de-identified dataset that you could share, we could look into investigating the issue in more detail.
and only get 2 of them loaded in the data tree (theones that are displayed w/o warning in the background)
I’ll try to convert them with plastimatch converter and dcm2niix though.
I suppose that the files in the folder should contain information about the transformation of the datasets ( CT series and a SPECT matched with ridig body transformation) and the segmentation results to.
It is also possible that frames are missing or the acquisition has variable number of frames. If you use a recent night build, then the MultiVolume importer writes thr reasons why it rejects loading of the data set into the Slicer application log. It would be useful if you could copy the log messages here. You can find the logs in menu: Help / Report a bug.
Here is the log excerpt, I cropped a bit, hope that helps:
[INFO][Stream] 26.08.2018 14:35:19 (unknown:0) - Loading with imageIOName: GDCM
[…]
Description: itk::ERROR: ImageSeriesReader(000001DB887C4390)] (D:\D\P\Slicer-0\Libs\vtkITK\vtkITKArchetypeImageSeriesScalarReader.cxx:264) - Size mismatch! The size of [path]/WK_V2/IM1.DCM is [892, 892, 17] and does not match the required size [892, 892, 1] from file [path]/WK_V2/IM1.DCM
[ERROR][VTK] 26.08.2018 14:35:19 [vtkCompositeDataPipeline (000001DB88874530)] (D:\D\P\Slicer-0-build\VTKv9\Common\ExecutionModel\vtkExecutive.cxx:782) - Algorithm vtkITKArchetypeImageSeriesScalarReader(000001DB87F624A0) returned failure for request: vtkInformation (000001DB88256120)
Debug: Off
Modified Time: 371028
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA
FORWARD_DIRECTION: 0
ALGORITHM_AFTER_FORWARD: 1
FROM_OUTPUT_PORT: 0
[CRITICAL][Stream] 26.08.2018 14:35:19 (unknown:0) - Could not read scalar volume using GDCM approach. Error is: FileFormatError
and then again:
[ERROR][VTK] 26.08.2018 14:35:20 [vtkITKArchetypeImageSeriesScalarReader (000001DB87F62100): Exception from vtkITK MegaMacro:
[…]
Description: itk::ERROR: ImageSeriesReader(000001DB887C33D0)] (D:\D\P\Slicer-0\Libs\vtkITK\vtkITKArchetypeImageSeriesScalarReader.cxx:264) - Size mismatch! The size of [path]/WK_V2/IM1.DCM is [892, 892, 17] and does not match the required size [892, 892, 1] from file [path]/WK_V2/IM1.DCM
[ERROR][VTK] 26.08.2018 14:35:20 [vtkCompositeDataPipeline (000001DB88872230)] (D:\D\P\Slicer-0-build\VTKv9\Common\ExecutionModel\vtkExecutive.cxx:782) - Algorithm vtkITKArchetypeImageSeriesScalarReader(000001DB87F62100) returned failure for request: vtkInformation (000001DB88878800)
[…]
[CRITICAL][Stream] 26.08.2018 14:35:20 (unknown:0) - Could not read scalar volume using DCMTK approach. Error is: FileFormatError
Could you upload the complete log (only remove patient information from the log - patient name, ID, etc)? If it is too large then you can upload to pastebin.com, dropbox, onedrive, or gdrive and post the link.
Well, first, I do not see in this thread any reason why that specific dataset would be handled by the multivolume plugin. It is probably just a couple of scalar volumes saved as enhanced multiframe objects, and I did have problems with multiframe objects in the past using Slicer. But maybe I missed something. I also know that the MF parser in ITK (at least the one that is based on DCMTK) doesn’t have a function to sort individual frames of a MF instance geometrically, which tells something about MF support robustness.
Regarding integration of dcm2niix, it would make sense to first consider this not in the context of multivolume, but for parsing scalar volumes. Multivolume plugin does not parse or load scalar volumes by itself, it delegates that task to the scalar volume plugin. To make an educated decision of whether it makes sense to consider integrating dcm2niix into Slicer, I would want to see some meaningful comparison of different tools to demonstrate its superiority to alternatives. I do not have resources to work on such at the moment.
In this particular situation, I just thought it is most practical to take a converter that is specifically designed for the task, and try it on the dataset.
Thanks for the explanation, I have been following multiple discussions and it seems I missed the point that these are just simple 3D volumes in multi-frame format and you are right that for this it is not necessary to use MultiVolume infrastructure
If Slicer has problems reading this file then most probably ITK’s DICOM image reader should be improved to better support DICOM files that contains multiple frames.
@thewtex Can you comment on this? Has DICOM multi-frame image support been improved recently? Do you need sample data sets to investigate or you are already aware that there are some limitations?
I don’t have the data set but I’ve tried loading 3D.dcm sample just now.
I’ve found that passing the file directly to the ITK reader (by drag-and-dropping the file to Slicer window and loading using ITK series reader) worked. So, ITK can load the multi-frame volume.
Loading the volume through Slicer’s DICOM scalar volume plugin failed with the same error as in the log above (Size mismatch! The size of .../3D.dcm is [275, 176, 164] and does not match the required size [275, 176, 1] from file .../3D.dcm).
So, it seems that this loading error is due to how Slicer uses the ITK image series reader and it has to be fixed in Slicer. Until the fix is ready, multi-frame volumes can be loaded by using “Add data” function (without DICOM module).
@fedorov mentioned some other limitations of multi-frame image support in ITK - see above:
@thewtex Do you know if this is this still the case? Even with the GDCM-based reader? Do you know about any other limitations related to multi-frame files?
This is definitely something that can debugged - by default the DICOMScalarVolumePlugin should be using the same code path as the Add Dialog, with the ability to force the use of other readers, as described in the thread linked below.
@lassoan under what circumstances did you get that error? I just loaded the 3D.dcm file through the dicom module on a linux system with a nightly build from August 4th. I had no problems no matter what reader approach (GDCM or DCMTK or Archetype all match the Add Data result).
In that sample data folder there are 4 files. If you import all of them into the DICOM database then you’ll see the error.
It is an interesting twist in the story. DICOM reading fails because 3 of the 4 series has the same series instance uid, therefore the DICOM reader tries to read them as one series, but in fact they are completely independent volumes.
For me it seems to be a violation of he DICOM standard that multiple volumes have the same series instance UID, but it is interesting that both this data set and most likely the Mirada Simplicity generated data set suffers from the same issue.
@Sandor_Konya Could you please check if you enable “Allow loading subseries by time” option (in menu: Application settings / DICOM), then go to DICOM module, enable “Advanced” option (in lower-right corner), click “Examine”, then you see multiple series with different contentTime in the list at the bottom?
If you check each loadable (with different contentTime, unchecked by default) and click “Load” then are the volumes loaded correctly?
Can you share the data set? (preferably use phantom data set; if patient data set then make it is anonymized)
@Sandor_Konya did you do anything with those files prior to loading into Slicer? Did you apply any anonymization on Mirada or using any other tools, or you are confident those files are exactly as they were created by Mirada?
Assignment of non-unique UIDs seems like a very serious non-compliance issue for a clinical product.
Hmm… Any 4D sequence acquired on one modality would have multiple volumes in one series (and therefore be a multivolume). But if these files are not from the same equipment or modality then they shouldn’t be in the same Series. In this case I guess the labels and dose are from different equipment from the original images so yes, a violation.
This information model is a simplification of the real world concepts and activities of medical imaging; for acquisition modalities, a Study is approximately equivalent to an ordered procedure, and a Series is approximately equivalent to a performed data acquisition protocol element. In other domains, such as Radiotherapy, the Study and Series are less clearly related to real world entities or activities, but are still required for consistency.
The Series IE defines the Attributes that are used to group Composite Instances into distinct logical sets. Each Series is associated with exactly one Study.
The following criteria group Composite Instances into a specific Series:
All Composite Instances within a Series must be of the same modality
Each Series may be associated with exactly one Frame of Reference IE, and if so associated all Composite Instances within the Series shall be spatially or temporally related to each other
All Composite Instances within the Series shall be created by the same equipment; therefore, each Series is associated with exactly one Equipment IE
All Composite Instances within a Series shall have the same Series information
