# Nifti loading times

**URL:** <https://discourse.slicer.org/t/nifti-loading-times/10497>\
**Category:** Support\
**Created:** [March 2, 2020, 3:59pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497 "2020-03-02T15:59:46Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![rprueckl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rprueckl/32/4240_2.png) [@rprueckl](https://discourse.slicer.org/u/rprueckl)\
**Post date:** [March 2, 2020, 3:59pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/1 "2020-03-02T15:59:46Z")

</div>

Hi,

I encountered very long loading times for some nifti datasets. I don’t know what it is.

**The following dataset takes one minute and 15 seconds to load in slicer 4.10.2 (it has about 60MB):**  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/2/c/2cf6bed2d5e947f07072690aaaad535fb0080a0b.png)

Mango file header:  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/e/e/ee464d77d808b7ffc407dd4a21d86548ea7192e2.png)

**Another dataset takes less than one second to load (about 80MB):**  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/9/b/9bb19c944ebd056108295635f6fefd2508c91c4b.png)

Mango file header:  
 ![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/2/7/272efbb117680568b2ebd8f2f2d1033bbc37ab9f.png)

Any ideas where the long loading times could come from? I could provide a dataset for testing if required.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [March 2, 2020, 4:17pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/2 "2020-03-02T16:17:43Z")

</div>

Thanks for the report. Yes, it would be good if you could provide a way to replicate this on public data.

Also did you try the latest preview version?

---

<div class="post-metadata">

**Author:** ![rprueckl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rprueckl/32/4240_2.png) [@rprueckl](https://discourse.slicer.org/u/rprueckl)\
**Post date:** [March 3, 2020, 11:28am UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/3 "2020-03-03T11:28:54Z")

</div>

In the latest preview version, the problem cannot be reproduced.  
As I am working with the sources of 4.10.2 for my project, it would be very interesting what was changed for the problem to be gone as I will have to apply the solution as a patch in my version. I can go through the commits myself, I just would need a hint where to start my search. Thanks

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [March 3, 2020, 12:43pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/4 "2020-03-03T12:43:12Z")

</div>

Interesting - thanks for testing and reporting.

4.10.2 uses an [older version of ITK](https://github.com/Slicer/Slicer/blob/v4.10.2/SuperBuild/External_ITK.cmake#L56) for file IO, and probably a lot has changed. You could go back and see if the problem could be reproduced in pure ITK and then perhaps backport whatever changes are needed. But more sustainable long-term (and maybe easier) would be to port your project to the latest Slicer.

---

<div class="post-metadata">

**Author:** ![rprueckl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rprueckl/32/4240_2.png) [@rprueckl](https://discourse.slicer.org/u/rprueckl)\
**Post date:** [March 4, 2020, 12:28pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/5 "2020-03-04T12:28:42Z")

</div>

Thanks, I found the issue. Here some references:

> [@Gipl files freezes slicer](https://discourse.slicer.org/t/gipl-files-freezes-slicer/5312):
>
> I was given two volumes in gipl format (image and labelmap), that I can open with ITKsnap without any problem. When I drag and drop them into Slicer, first it suggests to load them as ‘Scalar Overlay’ as oppose to ‘Volume’. Regardless of what’s chosen, Slicer stalls. This happens with both stable 4.10 and r27623 on windows 10. Same volumes exported as NRRD from ITK-Snap loads fine.

> <https://github.com/InsightSoftwareConsortium/ITK/issues/388#issue-397178164>
>
> \### Description
> 
> Some images take extremely long time to load because GDCMImag…eIO::CanReadFile takes several minutes.
> 
> \### Steps to Reproduce
> 
> Download this image:
> https://1drv.ms/u/s!Arm\_AFxB9yqHtrg3be4uEYghv0JPSw
> 
> Using just ITK:
> 1. Load image file linked above using itk::ImageFileReader
> 
> Using 3D Slicer:
> 1. Drag and drop the image file linked above to the application window
> 2. Select "Volume" in Description column
> 3. Click OK
> 
> \### Expected behavior
> 
> The file is loaded within a few seconds.
> 
> \### Actual behavior
> 
> The file is loaded in about 5 minutes.
> 
> \### Reproducibility
> 
> 100% with the file linked above.
> 
> \### Versions
> 
> 4.13
> 
> \### Environment
> 
> Windows10, VS2015
> 
> \### Additional Information
> 
> Originally reported by a Slicer user here: https://discourse.slicer.org/t/gipl-files-freezes-slicer/5312/3

> <https://github.com/InsightSoftwareConsortium/ITK/commit/19fa58feb02bfd45154e811d0e13510787e2adfb#diff-824229b4fd5f76e67acd43acc54fdae2>
>
> NOTE: DCMTK and GDCM demonstrate the same behavior with certain
> non-DICOM …files that have byte patterns similar to DICOM
> 
> Some images take extremely long time to load because
> DCMTKImageIO::CanReadFile & GDCMImageIO::CanReadFile takes several
> minutes to fail. This is due to DCMTK's and GDCM's default behavior of
> trying to read non-compliant dicom files that do not have the required
> DICM header.
> 
> Add more extensive testing about the structure of the file to determine
> if it looks like a dicom file. Previous testing only looked to see if the
> files without preables had values of 2 or 8 as the first byles of the file,
> but that resulted in many false positives.
> 
> This implementation looks at all the SOP Instances that start with 2 or 8
> to ensure that the proper dicom structure is found.
> 
> This resolves #388.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [March 4, 2020, 1:45pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/6 "2020-03-04T13:45:05Z")

</div>

Note that we will soon (in maybe a couple of weeks) release Slicer-5 and deprecate Slicer-4.10. So, I would not recommend to spend time with backporting any fixes, etc. to Slicer-4.10 but rather spend that time with updating to latest Slicer-4.11 (that will become Slicer-5) and test/fix things.

---

<div class="post-metadata">

**Author:** ![rprueckl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rprueckl/32/4240_2.png) [@rprueckl](https://discourse.slicer.org/u/rprueckl)\
**Post date:** [March 4, 2020, 2:02pm UTC](https://discourse.slicer.org/t/nifti-loading-times/10497/7 "2020-03-04T14:02:50Z")

</div>

Yes, thanks for the hint.