Hello, our clinical DICOM images very often seem to end up having “irregular volume geometry” detected just above the threshold of 0.001 mm.
This is a typical message I got today: [Python] Irregular volume geometry detected (maximum error of 0.0010596 mm is above tolerance threshold of 0.001 mm). Adding acquisition transform to regularize geometry.
I am never making measurements at a much finer scale than a voxel, which is at least 250x larger than this threshold (0.25 mm at the smallest for images I work with). This results in creation of an unnecessary (for me) nonlinear “acquisition transform”. Is there a way I could increase the threshold to avoid this? I don’t want to turn the warning off entirely because I want to know if there is a large irregularity in something I try to load, but this threshold is a little too sensitive for the data I work with.
Clinical scanners do not usually have such problems. What kind of scanners do you use? Do you see this error on the data that comes directly from the scanner or is it introduced during reprocessing/anonymization of the images?
The tolerance values are specified in DICOMScalarVolumePlugin.py and you can modify this file on your computer as you see fit. If we find that clinical scanners violate these tolerances then we may consider making them adjustable in application settings, but it is simpler and safer to keep them as constant values.
The image volume which generated that error message came from a Siemens Avanto Fit, on DICOM images downloaded directly from our clinical PACS (no reprocessing before importing to Slicer).
Thanks for the reference to the threshold location, I will modify the threshold to bump it up a little to 0.005 mm.
It would be interesting to know that it is due to rounding (the manufacturer thinks it is OK to use 3 digits after the decimal); or there is some inconsitency at the first or last slice; or there is an issue somewhere in the middle.
Could you copy here the ImagePositionPatient tag values for the series? (right-click View DICOM metadata, type ImagePositionPatient in the filter, click Copy all files metadata, save to file, upload the file somewhere and post the link here)
@mikebind are these for a rotated MR volume? I think sometimes there are limits on what the gradients can achieve so the slicer prescription gets clamped to a nearest value or something. In that case I’m not sure if it’s good to ignore the spacing irregularity or apply the geometry correction (or maybe the difference is negligible).
In any case for batch processing I have found it useful to auto-apply the acquisition transform and maybe we should expose that as a user setting in addition to making the tolerance settable.
My apologies! I just realized I grabbed the wrong series metadata. I had loaded both an MR and a CT for this patient and misremembered which one had the irregularity error message. It was the CT which was warned as irregularly spaced. Here is the image position patient data for that image volume: IrregularImagePositionPatientExample_CT.txt - Google Drive
@pieper, to your question about whether it is a rotated volume, this is the volume information
@mikebind There seems to be a rounding of the position offset between neighbor frames to 3 digits (0.032 or 0.033). This corresponds to 0.001/0.032 = 3.1% error in slice spacing, which is quite small, but not necessarily negligible. Also, the rounding is a bit unexpected, because the position values have 6 digits after the decimal point. I would recommend to report this problem to the manufacturer.
@pieper It seems that currently we use absolute tolerance values. What do you think about setting the tolerance as percentage of the slice spacing? Maybe we could then be a bit more permissive and say we allow up to 5% variation in slice spacing?
Thanks for looking into it. A relative tolerance threshold sounds like a good idea to me. I will work on figuring out how to report the problem to Siemens.
It would be good to talk to someone who could give insight into why these small differences occur to decide if resampling is more accurate or leaving them as-is is more accurate (i.e. are the positions incorrectly recorded or do the correctly denote irregularly spaced slices).
But yes, a relative error sounds reasonable in any case.
I was thinking exactly the same thing: if the slices are equally spaced but the recorded slice locations are being rounded, then the right thing to do is to treat the slices as equally spaced despite the rounding errors. The alternative is that the slice locations reported are measured more accurately than the scanner’s ability to space slices equally. In that case, the theoretically right thing to do is to treat the slices as unequally spaced and have a transform applied to achieve that. Either of those options seems somewhat plausible to me, so I agree it would be good to talk to some who would know which is actually the case.
