rprueckl
(Robert Prueckl)
March 2, 2020, 3:59pm
1
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):
Mango file header:
Another dataset takes less than one second to load (about 80MB):
Mango file header:
Any ideas where the long loading times could come from? I could provide a dataset for testing if required.
pieper
(Steve Pieper (Isomics, Inc.))
March 2, 2020, 4:17pm
2
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?
rprueckl
(Robert Prueckl)
March 3, 2020, 11:28am
3
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
pieper
(Steve Pieper (Isomics, Inc.))
March 3, 2020, 12:43pm
4
Interesting - thanks for testing and reporting.
4.10.2 uses an older version of ITK 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.
rprueckl
(Robert Prueckl)
March 4, 2020, 12:28pm
5
Thanks, I found the issue. Here some references:
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.
opened 01:56AM - 09 Jan 19 UTC
closed 10:12PM - 14 Jan 19 UTC
type:Performance
area:IO
### 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
committed 10:11PM - 14 Jan 19 UTC
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.
2 Likes
lassoan
(Andras Lasso)
March 4, 2020, 1:45pm
6
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.
rprueckl
(Robert Prueckl)
March 4, 2020, 2:02pm
7
Yes, thanks for the hint.