I tried the DICOMPatcher and it didn’t solve the issue.
ve just shared theanonymized` data set with you to share it with the ITK/GDCM developers. Hope it helps.
I reproduced the problem using pure ITK (the version that is used by Slicer).
The repo to reproduce the problem is here: https://github.com/fedorov/itk-gdcm-dcmtk-readers
GDCM reader fails with the same error as in Slicer:
Exception thrown while reading the series itk::ExceptionObject (0x7ff2538696d8) Location: "virtual void itk::ImageBase<3>::ComputeIndexToPhysicalPointMatrices() [VImageDimension = 3]" File: /Users/fedorov/local/builds/Slicer4-Release/ITKv4/Modules/Core/Common/include/itkImageBase.hxx Line: 187 Description: itk::ERROR: Image(0x7ff253873c90): A spacing of 0 is not allowed: Spacing is [0.3125, 0.3125, 0]
DCMTK reader works just fine, and results in a volume with slice thickness 1.3, as expected.
I will follow up with the ITK folks, but this experience, once again, begs the question - why do we rely in ITK and Slicer on GDCM and not on DCMTK?
ITK issue reported: https://issues.itk.org/jira/browse/ITK-3546
Sample dataset shared by @kirezgik uploaded here: https://github.com/fedorov/itk-gdcm-dcmtk-readers/releases/download/gdcm_fails/GDCM_fails.zip
@kirezgik are you able to build Slicer from source, or you only use the downloaded binaries?
I have a modified version of code that works for your dataset, but other people have concerns about integrating that solution into the main application, so I need to work on another approach.
I only use the downloaded binaries. But if building from source helps, we might try to do that.
@kirezgik I feel sorry to ask you to build it, since it might be easier for me to implement this feature in the extension, than for you to build Slicer. I think it is too much trouble for you. I am not sure if I can get to it this week, but if not then next week for sure.
Thanks very much for your fast reply, No problem, I can build it again.
@zp12132016 this is the branch that contains the fix that should allow loading of the DCE dataset @kirezgik shared earlier: https://github.com/fedorov/slicer/tree/dcmtk-for-scalar-volume
Thanks for your active reply!
I am trying to built the slicer again, currently I am using slicer version 4.6.2 and Viusal studio 2013 desktop with update 5, Qt 4.8.7 and CMake 3.8.1
Do you think I need to try different version of slicer?
For the branch you mentioned below, how to put it in build slicer?
You will have to check out the branch I mentioned above from GitHub, and build Slicer from scratch. Looking at the instructions , your setup should work.
We tried the instructions for setup, but can not unzip Cmake and Qt folders in common prerequisites.
Do you have CMake running? Do you have any anti-virus software that may prevent extraction of executable files? Can you extract the files in your user directory or desktop?
We had CMake run and tried to extract the files in desktop but it gives these errors:
We are moving forward with the implementation discussed in this thread: Slicer DICOM Scalar volume plugin relies on (old) GDCM: why do we not use DCMTK?
We should hopefully have it in the application sometime soon. I will followup with @pieper later this week. I think fixing this problem of failing read of scalar volume in the Slicer application should be done no matter what.
You can monitor this pull request: https://github.com/Slicer/Slicer/pull/734. Once it is merged, loading of your dataset should work in the nightly.
@kirezgik the issue you identified should be fixed in today’s nightly of Slicer. At least I can say I am able to load the dataset you shared without problems.
That`s great! Yes, it is working now. I am able to load the dataset and visualize it in all 3 planes as a dynamic view without problems.
Thank you @fedorov for all your help, and @lassoan , @pieper! I appreciate your interest and hard work since the beginning of my support request. I will update you about the implementation as I move forward with the analysis.
Dear @kirezgik , I am one of the author of GDCM. I have been starring at your DICOM datasets and they seems to suffer from a rather large issue from a DICOM point of view. This is the first time I am seeing this from a DICOM DataSet in the wild. Could you please confirm that this data is coming from a real modality (not some kind of experimental project) ? If so I’d like to contact the vendor about their failure to follow the standard. Ideally I would need a copy of the original DataSet. Thanks.
Hi @malaterre, thanks for your interest about this topic. The data is coming from an experimental project, it is not a clinical data. What is the issue you realized? I can let the vendor know about it. Also I can share the original DataSet if you provide me your email. Thanks.