New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extermely slow loading of image files due to GDCMImageIO::CanReadFile #388

Closed
lassoan opened this Issue Jan 9, 2019 · 0 comments

Comments

Projects
None yet
2 participants
@lassoan
Copy link

lassoan commented Jan 9, 2019

Description

Some images take extremely long time to load because GDCMImageIO::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

hjmjohnson added a commit that referenced this issue Jan 9, 2019

PERF: GDCM CanRead function fail quickly for non-compliant DICOM files.
Some images take extremely long time to load because GDCMImageIO::CanReadFile
takes several minutes to fail.  This is due to GDCM's default behavior of trying
to read non-compliant dicom files that do not have the required DICM header.

This resolves #388.

hjmjohnson added a commit that referenced this issue Jan 9, 2019

PERF: GDCM CanRead function fail quickly for non-compliant DICOM files.
Some images take extremely long time to load because GDCMImageIO::CanReadFile
takes several minutes to fail.  This is due to GDCM's default behavior of trying
to read non-compliant dicom files that do not have the required DICM header.

This resolves #388.

hjmjohnson added a commit that referenced this issue Jan 10, 2019

PERF: GDCM CanRead function fail quickly for non-compliant DICOM files.
Some images take extremely long time to load because GDCMImageIO::CanReadFile
takes several minutes to fail.  This is due to 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.

@thewtex thewtex closed this Jan 13, 2019

@thewtex thewtex reopened this Jan 13, 2019

hjmjohnson added a commit that referenced this issue Jan 14, 2019

PERF: GDCM & DCMTK CanRead fails very slowly for non-DICOM files.
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.

hjmjohnson added a commit that referenced this issue Jan 14, 2019

PERF: GDCM & DCMTK CanRead fails very slowly for non-DICOM files.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment