Hi, all:
Lately, I am coding an python app using itk. For dcm files IO, i try itk.ImageFileReader and itk.ImageSeriesReader, both take too long to read dcm with double type image. Environment is homebrewed ITK on Mac. Loading one single dcm using imagefile reader takes about 5s. I search online and find maybe the homebrewd version omit some flag wrapping certain data type(I am useing Itk.F). I tried on my another ubuntu workstation compiling with itk_wrap_double and other data types. After that, loading still about 1 second per dcm even I change reader config to ITK.D. Does any one has idea about that issue?
Thank you for your kind reply.
CMAKE_BUILD_TYPE is Release.
In my case, only some of my dcms of double type are loaded slowly, not all. I also try to use ITK_SNAP to load this dcms, quite slowly as well. Take also few mins to load a folder with 140 dcms inside. Loading got no errors. I check some dicom tags, but it seems nothing abnormal. Do you know any possible causes for this?
By the way, I got a warning when using ITK_SNAP trying to load these files. “Loss of Precision: you are opening an image with 32-bit or more precision, but itk-snap provides 16-but precision…”
Could you try reading the files with 3D Slicer? Recent versions of 3D Slicer read DICOMs through ITK with two alternate backends – GDCM or DCMTK. Please try both to see if DCMTK is faster. We could expose DCMTK in the Python wrapping.
I tried 3D Slicer, also take quite a well to load. My own app, itksnap and 3d slicer all quite slow. It seems like that the support of itk for Double datetype dicom image is not strong enough.
Below are some dicom info of the dcm I got from ITKSANP
How does reading with the DCMTK or GDCM backend compare? As instructed here:
Try import using different DICOM readers: in Application settings / DICOM / DICOMScalarVolumePlugin / DICOM reader approach: switch from DCMTK to GDCM (or GDCM to DCMTK), restart Slicer, and attempt to load the data set again.
Hello,
I have a connected issue with my DICOM reading in ITKSnap. Thought I read them, and I had a warning of the precision loss, which I beleived, then I read the image with Python (pydicom and dcmstack) and I see that my images are 16 bit. Precisely I get this :
(0028, 0100) Bits Allocated US: 16
(0028, 0101) Bits Stored US: 16
(0028, 0102) High Bit US: 15
(0028, 0103) Pixel Representation US: 0
(0028, 0106) Smallest Image Pixel Value US: 0
(0028, 0107) Largest Image Pixel Value US: 9828
(0028, 1052) Rescale Intercept DS: “0”
(0028, 1053) Rescale Slope DS: “1.8997689886166”
So, I don’ understand why ItkSnap tells it’s double. Moreover the maximum pixel values are not equal.
Any idea what’s happening?I will check with Slicer and c3d as well.
Thank you in advance
The intensity values are indeed double. The stored values (SV) data is stored in 16bits (bits allocated) and uses all 16bits (bits used). The formula to get the actual intensity from a DICOM image based on the standard is: I = SV *rescale_slope + rescale_intercept
In your case the slope looks like a double, so the final intensities should be double. You can obviously force your intensities to be whatever you want them to be (double, int etc.), but the original intensities appear to be double.
When you get a numpy array from DICOM data you first used a file reader which most likely takes care of this implicitly, otherwise it isn’t a complete DICOM reader. In general, the expectation from any DICOM reader is that it take care of this computation so that after reading the image you have the correct values without requiring you to do anything. In ITK, SimpleITK the underlying DICOM readers from GDCM or DCMTK take care of this, This is why you see the warning in ITK-SNAP which is using ITK.
Thank you for the comprehensive responses. I am using Pydicom and Dcmstack, neither seem to encount for the slope and intercept. I wanted to avoird using Simpleitk on this stage, but it seems like I will have to, maybe you can recommend other libraries in Python that manage DICOM well?
Sorry, you seem to be more familiar with the Python options for reading DICOM than I am, so I don’t have any other options for you. I was only aware of pydicom and SimpleITK/ITK. Thanks to you, I am now aware of dcmstack.
I would recommend going with SimpleITK/ITK, but I am biased .
.