Account for non-uniform spacing

Hello,

When loading a DICOM series in Slicer I noticed a warning related to the spacing of the images, so I manually checked if the spacing was the same between each slices, it’s not.

Converting the DICOM series with SimpleITK and c3d then leads to a visualization error :

What’s the convention to account for such problems in ITK ?

Thanks

ITK does not have a remedy for such cases. It assumes equal spacing between all slices. It gives a warning if that assumption is not satisfied.

And the rendering you show looks like it is a 3D image created by mixture of slices from two 3D images. That would also trigger non-uniform spacing warning.

2 Likes

Yes you are right it looks like a mix, the dataset is messed up, I can not even trust SeriesInstanceUID…

Thanks for your feedback

If you import through Slicer’s dicom module, you can enable the acquisition transform correction option (in the preferences) which automatically creates a nonlinear transform to put every slice in the location specified by the headers. You can then resample the volume through this transform if you need to have a regularly sampled volume like a 3D itk image.

https://www.slicer.org/wiki/Documentation/Nightly/Modules/DICOM

Of course there’s not much that can be done if the data is corrupted, but the dicom patcher addresses some common cases.

https://slicer.readthedocs.io/en/latest/user_guide/module_dicompatcher.html

1 Like

That’s good to know, thanks !

It doesn’t seem uncommon (in a clinical practice) to have a volume acquired at different z spacing, am I wrong ? I see lots of images with at least 2 or 3 unique spacing values in my dataset.
The only way I see to handle it would be from the DICOM tags directly, does any library could provide this kind of feature (in a non-graphical way like Slicer does) ?

Thanks

You are right, it’s fairly common in some clinical scans like abdominal CT where the table speed is varied to get more or less resolution in certain parts of the body. It can also happen when slices are missing. Also gantry tilt is a common issue addressed by this acquisition modeling approach.

dcm2niix will also detect and fix at least some of these cases during the conversion process.

I don’t know of any software other than Slicer that creates a non-linear transform so that you can control the resampling. The same technique could certainly be ported to other languages. Or it’s possible to use from Slicer in a command line mode / python script.

There’s more info on the Slicer method in the commit message, along with the code:

https://github.com/Slicer/Slicer/commit/b7650af3c27f34fc894bfdd587f2a4c02ba62a8b

Thanks for the detailed answer :slight_smile:

I am not familiar with the non-graphical part of Slicer. Am I wrong to think I could use Slicer’s python interface to correct these errors, like the tests you pointed out ?

As you can tell it’s something of an obsession for me :wink:

Regarding Slicer, yes, the Python interface is extremely powerful and flexible. For some of us it has become our main tool for taking on the complexities of real-world medical imaging research because so many tricky issues are already addressed. You have SimpleITK, VTK, numpy, Qt, and so many other useful things right at your fingertips on all major computing platforms.

Of course before anyone else points it out, Slicer is a big beast with a learning curve so it’s not the only way to go.

Here are some links to help you out, and you are always welcome over at discourse.slicer.org.

https://www.slicer.org/wiki/Documentation/Nightly/Developers/Python_scripting

https://www.slicer.org/wiki/Documentation/Nightly/ScriptRepository

1 Like

Thank you Steve, I can’t wait to learn more from the Slicer community !