# ITK Take Too Long To read Double type image
**URL:** https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917
**Category:** Beginner Questions
**Tags:** dicom, python
**Created:** [May 10, 2018, 3:22am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917 "2018-05-10T03:22:21Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@wyBrian](https://discourse.itk.org/u/wyBrian)
#### Post date: [May 10, 2018, 3:22am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/1 "2018-05-10T03:22:22Z")
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 a lot
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [May 10, 2018, 3:39am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/2 "2018-05-10T03:39:37Z")
Hi Brian,
Welcome to ITK!
Did you build ITK? If so, was the `CMAKE_BUILD_TYPE` set to `Release`? Often it gets set to `Debug`, which is much slower,
Hope this helps,
Matt
---
### Author:  [@wyBrian](https://discourse.itk.org/u/wyBrian)
#### Post date: [May 10, 2018, 3:54am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/3 "2018-05-10T03:54:08Z")
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?
---
### Author:  [@wyBrian](https://discourse.itk.org/u/wyBrian)
#### Post date: [May 10, 2018, 3:56am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/4 "2018-05-10T03:56:44Z")
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…”
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [May 10, 2018, 4:51am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/5 "2018-05-10T04:51:23Z")
Could you try reading the files with [3D Slicer](https://www.slicer.org/)? 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.
---
### Author:  [@wyBrian](https://discourse.itk.org/u/wyBrian)
#### Post date: [May 10, 2018, 5:50am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/6 "2018-05-10T05:50:23Z")
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
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [May 10, 2018, 8:21pm UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/7 "2018-05-10T20:21:46Z")
How does reading with the DCMTK or GDCM backend compare? As [instructed here](https://www.slicer.org/wiki/Documentation/Nightly/FAQ/DICOM):
> 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.
---
### Author:  [@pocolya](https://discourse.itk.org/u/pocolya)
#### Post date: [April 5, 2019, 1:34pm UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/8 "2019-04-05T13:34:38Z")
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
---
### Author:  [@zivy](https://discourse.itk.org/u/zivy)
#### Post date: [April 5, 2019, 1:57pm UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/9 "2019-04-05T13:57:22Z")
Hello @pocolya
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](http://dicom.nema.org/MEDICAL/dicom/current/output/chtml/part03/sect_C.8.15.3.10.html) 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.
---
### Author:  [@pocolya](https://discourse.itk.org/u/pocolya)
#### Post date: [April 5, 2019, 2:46pm UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/10 "2019-04-05T14:46:09Z")
Thank you for the quick reply. This would make sense.
I saw a similar formula on the wiki of DICOM/ITK, but not exactly what you give :
RWV=RescaleSlope\*SamplesPerPixel+RescaleIntercept
So,normally when getting a numpy array from the DICOM data I would need to convert it acording to the formula?
---
### Author:  [@zivy](https://discourse.itk.org/u/zivy)
#### Post date: [April 5, 2019, 4:00pm UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/11 "2019-04-05T16:00:28Z")
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.
---
### Author:  [@pocolya](https://discourse.itk.org/u/pocolya)
#### Post date: [April 8, 2019, 9:37am UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/12 "2019-04-08T09:37:20Z")
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?
---
### Author:  [@zivy](https://discourse.itk.org/u/zivy)
#### Post date: [April 8, 2019, 1:12pm UTC](https://discourse.itk.org/t/itk-take-too-long-to-read-double-type-image/917/13 "2019-04-08T13:12:37Z")
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 🙂 .