# Understanding CT Image spacing and Acquisition geometry regularization
**URL:** https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001
**Category:** Support
**Created:** [July 31, 2021, 5:13pm UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001 "2021-07-31T17:13:34Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@manjula](https://discourse.slicer.org/u/manjula)
#### Post date: [July 31, 2021, 5:13pm UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001/1 "2021-07-31T17:13:34Z")
Dear all,
"Images are not equally spaced (a difference of 0.6 vs 0.3 was detected)’
Why does this error occur? What causes the acquisition of acquired irregular geometry? is it something to do with CT machine, protocol, technique or just a problem with exporting the data?
with Acquisition geometry regularization correction transform applied, I tried to harden the transformation and I expected the corrected version of the image to persist but it changed to the original? is this the expected behavior?
what does this mean and is there a difference that is too much to be corrected or too little to be ignored ? (a difference of 0.6 vs 0.3 was detected) ?
thank you
---
### Author:  [@pieper](https://discourse.slicer.org/u/pieper)
#### Post date: [July 31, 2021, 6:08pm UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001/2 "2021-07-31T18:08:17Z")
Hi @manjula -
There’s a description of the purpose and implementation technique in the git commit message linked below (small aside: it still makes me smile that Andras said he wished he’d thought of this : )
In your case it looks like the third cited motivation:
```auto
3) Variable table speed during CT acquisition, which is sometimes
used in abdominal or musculoskeletal imaging to provide high resolution
in selected body parts and lower resolution between (e.g. high res
at the ankle, knee and hip, but low res in the shin and thigh).
```
They often to this to speed up the exam, minimize radiation exposure, avoid a bunch of extra useless slices, and extend the life of the x-ray tube.
The volume shouldn’t move at all when you harden the transform, but maybe the RAS box is fit to the data differently. Please confirm this and we can investigate. The acquisition geometry regularization correction transform is not applied automatically so that you have an option to use a resampling tool to pick the desired resolution.
>
>
> Add a step to the DICOMScalarVolumePlugin to check that the loaded
> volume node's… slice geometry matches what is expected from
> the position and orientation information of the individual
> slices in the DICOM headers.
>
> If needed, a grid transform is created to reposition each slice
> to the appropriate position in patient space.
>
> Use an empirically defined epsilon threshold to decide if
> an acquisition transform is needed. The selected value of
> 1e-3 millimeters (one micrometer) is still very small by
> medical imaging standards but is large enough that rounding
> errors and other small variations do not result in extra
> correction transforms when they won't add real value.
> The error is defined as the max absolute difference
> in any coordinate of the corner of any slice so it
> is designed to handle gantry tilt, missing slices,
> and irregularly spaced slices.
>
> The DICOMReaders self test has been extended to test this in the
> case where slices are missing from the middle of the volume. The
> grid transform results in an interpolated band of pixels using
> information from adjacent slices to 'fill in' for the missing
> data. The test confirms that the last slice of the reconstructed
> volume is in the expected location in patient space. This correction
> means that calculations like ruler or segment statistics can be
> robust even with missing slices.
>
> Currently the only available testing data is for the case of missing
> slices. However this code should allow proper loading and display of
> several not-uncommon imaging scenarios:
>
> 1) Missing slices due to network failure or accidental file deletion.
>
> 2) Gantry tilted image acquisitons (see #4409) which is
> used, for example, to minimize radiation exposure to the retinas
> especially in pediatric imaging.
>
> 3) Variable table speed during CT acquisition, which is sometimes
> used in abdominal or musculoskeletal imaging to provide high resolution
> in selected body parts and lower resolution between (e.g. high res
> at the ankle, knee and hip, but low res in the shin and thigh).
>
> Consderations:
>
> By creating a transform we preserve the original data and leave it
> to the user to resample if desired. The option of resampling
> during load was rejected since it is unclear what sampling grid
> would be best in all cases.
>
> Although the transform should correct the geometry, a warning dialog is
> still generated during loading since the issue could be correctable
> (such as missing slices) or may be triggered by other data issues
> not forseen by this code.
>
> Most DICOM data has identical row and column spacing
> but when they do not it's critical to have the right
> spacing geomtry. This code uses the correct definitions
> from the standard. Where PixelSpacing is row/column
> but ImageOrientationPatient if column/row
>
> We check and avoid ValueError warning when dicom files do not have
> geometry information.
>
> svn-url: http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=26500
> git-svn-id: http://svn.slicer.org/Slicer4/trunk@26500 3bd1e089-480b-0410-8dfb-8563597acbee
---
### Author:  [@manjula](https://discourse.slicer.org/u/manjula)
#### Post date: [July 31, 2021, 6:44pm UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001/3 "2021-07-31T18:44:52Z")
Hi @pieper
Thank you for the reply and I will go through it.
This is what happens after loading this data and when I try to transform. Both in the stable and the preview release that I use (2021.06.24). I don’t know it is an error or not but I recorded a clip so you can see if it does what it intends to do or not.
[ ](https://www.youtube.com/watch?v=wshQXzH-5Ks)
---
### Author:  [@pieper](https://discourse.slicer.org/u/pieper)
#### Post date: [July 31, 2021, 8:01pm UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001/4 "2021-07-31T20:01:32Z")
This is probably correct because the volume rendering doesn’t take non-linear transforms like the acquisition correction into account. You can confirm this by making the slice views visible in the 3D view and they won’t match until you harden. It needs to be fixed at the VTK level, and we’ve discussed it but it hasn’t been done yet as far as I know. The volume rendering module should really generate a visible warning or error dialog when a volume with a nonlinear transform is selected.
In any case, it appears that things are working correctly elsewhere and things like rulers and other markups will work. You might do a few measurements as a sanity check.
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [August 2, 2021, 12:51am UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001/6 "2021-08-02T00:51:24Z")
> [@pieper](#):
>
> The volume rendering module should really generate a visible warning or error dialog when a volume with a nonlinear transform is selected
The related issue is here:
>
>
> \_This issue was created automatically from an original \[Mantis Issue\](https://ma…ntisarchive.slicer.org/view.php?id=4701). Further discussion may take place here.\_
---
### Author:  [@Davide\_Punzo](https://discourse.slicer.org/u/Davide_Punzo)
#### Post date: [November 13, 2023, 8:37am UTC](https://discourse.slicer.org/t/understanding-ct-image-spacing-and-acquisition-geometry-regularization/19001/7 "2023-11-13T08:37:23Z")
NOTE: Support for regularization transform hardening in DICOM Scalar plugin has been added. See [link](https://discourse.slicer.org/t/enh-support-regularization-transform-hardening-in-dicom-scalar-plugin/32772).