"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) ?
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:
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.
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.
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.
