I am working with functional data, and have a question about the sct_fmri_moco algorithm. The output transformation matrices are in the X and Y plane. I am hoping to understand this output a little better.
In other moco implementations of moco there are 6 matricies (X, Y, Z, Rx, Ry, Rz). In the antsSliceRegularizedRegistration documentation it says that the moco is slice-by-slice, then regularized in the z direction.
sct_dmri_moco, uses the slicereg algorithm, which performs a translation along X and Y on a slice-by-slice basis. If you look at the help of
sct_fmri_moco, it says:
The outputs of the motion correction process are:
- the motion-corrected fMRI volumes
- the time average of the corrected fMRI volumes
- a time-series with 1 voxel in the XY plane, for the X and Y motion direction (two separate files), as required for FSL analysis.
- a TSV file with the slice-wise average of the motion correction for XY (one file), that can be used for Quality Control.
So, there is a TSV file, which shows the average of Tx and Ty across all slices, per volume. That way you can spot aberrant motion for volumes. See example below (for the first 10 volumes):
If you want the individual Tx and Ty per slice and per volume, you can use the output moco_params_x.nii.gz and moco_params_y.nii.gz files.
Does this mean that there are no Z shifts in the moco?
Indeed, no z-translation.
Also, are rotations considered?
No. We have implemented it at some point but then discovered a bug (more details here). If that would be a desirable feature, we can reconsider it.
I’m working with cervical MT data, and when using sct_extract_metric I am getting incorrect values for the volumes of the tracts when using the MAP and ML methods. The BIN and WA methods output the proper Size(vox) of the tracts, but the MAP and ML methods both output the total size of the Cord and CSF contour. I’ve checked and the PAM50 registration looks good, and the all the labels are correct.
Yup! This is a known bug, recently reported here and fixed 2 days ago in this PR.. The fix is available in the
git-master version of SCT, and will be available in the next stable release.