ENH: Fix dicom reading slices #4955
Conversation
The AlmostEquals function fails for slices that are only 1e-15 different for 1.5mm slices. The DefaultImageCoordinateTolerance has been determined to be 1e-6. Using the global default tolerance provides more meaningful default behaviors.
When reading individual 2D dicom slices, the slice thickness may not be known at each slice reading. If set to spacing of 0 (the default) an exception is thrown before the inter-slice distance can be computed. Catch this case and set a temporary inter-slice thickness.
hjmjohnson
added
type:Bug
github-actions
bot
added
type:Enhancement
|
Local mac testing: 100% tests passed, 0 tests failed out of 3011 |
There was a problem hiding this comment.
The Windows libtiff errors seem to be unrelated:
itktiff-6.0.lib(tif_luv.c.obj) : error LNK2005: __ucrt_int_to_float already defined in itktiff-6.0.lib(tif_aux.c.obj)
itktiff-6.0.lib(tif_color.c.obj) : error LNK2005: __ucrt_int_to_float already defined in itktiff-6.0.lib(tif_aux.c.obj)
bin\ITKAnisotropicSmoothingTestDriver.exe : fatal error LNK1169: one or more multiply defined symbols found
| // file. interslice distances can be computed after all slices are read. | ||
| // set to non-zero value here to avoid prematurely throwing an exception | ||
| // before the interslice thickness can be computed. | ||
| const auto abs_spacing_2 = std::abs(sp[2]); // Spacing may be negative at this point, will be fixed below |
There was a problem hiding this comment.
A 2D DICOM slice
file. Inter-slice distances (leave a single white space after the period)
Set to non-zero value
before the inter-slice
|
@jhlegarreta I appreciate your comments, but I don't have the bandwidth to make this perfect. I'm going to add it as is. |
hjmjohnson
merged commit 296bed6
into
InsightSoftwareConsortium:master
|
Is this at all related to #4794 ? |
|
I just tracked down 916a40c as the cause of one of our app's unit test failures. With the new less-strict tolerance check, We use the value of It's not clear to me from the commit message what bug this commit was fixing... Yes, Where does this magic 1e-6 ( |
Dicom files that do not have explicit "SliceThickness" listed can still be used. The actual "spacing between slices" is computed from the stack of slices when multiple dicoms are provided such that the initial setting of the "SliceThickness" placeholder is not used. (NOTE: SliceThickness is used when a single slice is read into a 3D image).
This fixes an issue when a stack of 124 dicom slices does not have "SliceThickness" fields, but does have "ImagePositionPatient" for each slice.
The previous implementation would throw an exception prior to getting to the code that explicitly computes the slice space from the "ImagePositionPatient" values.
The new code now allows ITK to make 3D nifti volumes that are compatible with those created by the dcm2niix package.
PR Checklist