2 questions - sct_fmri_moco and sct_extract_metric

SCT
1

Hello!

Question 1:
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. Does this mean that there are no Z shifts in the moco? Also, are rotations considered?

Question 2:
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.

Thank you for you time and help!
Mark

2

Hi Mark!

Question 1:
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_fmri_moco, like 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):

X Y
3.33002457135005e-06 -6.06590395217192e-06
-0.020430507354518000 -0.05460222822036920
0.04756090103723190 -0.10960818736168800
0.01905056370102960 -0.07620355659530390
0.044265178434871500 -0.021218659940223200
0.02033304025641000 -0.11795519527067900
0.050682700148200300 -0.028725411308628900
0.023094671931923800 -0.12841860053985100
0.08334008549293220 -0.12726617553537400
0.1399040250382250 -0.06437511406339410

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.

Question 2:
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.

Cheers,
Julien

3

Hi Julien!

Thank you so much for the info and links!

Are there plans for implementation of a Z-translation in the moco algorithm?

From what I saw in the PR link, it looks like the issue was with the isct_antsSliceRegularizedRegistration function - and this was fixed and included in the SCT 5.0 release. I think rotation transformations would be very helpful in the cord.

In regards to the sct_extract_metric - I’ve cloned the repository and will check it out today.

Cheers,
Mark

4

Are there plans for implementation of a Z-translation in the moco algorithm?

No, unless someone can demonstrate the need for such a feature. In most cases (>95% I would say), fMRI and DWI of the spinal cord is done with axial EPI time series, with thick slices (~5mm). If z-translation was on, the through-slice interpolation would result in excessive partial volume effect. I am afraid that a lot of users would not be aware of that issue and introduce interpolation errors with that feature.

From what I saw in the PR link, it looks like the issue was with the isct_antsSliceRegularizedRegistration function - and this was fixed and included in the SCT 5.0 release.

I’m sorry this was the wrong link. Here :point_left: is the correct link.

I think rotation transformations would be very helpful in the cord.

Noted. We have reopened the ticket and will consider this feature request in the future.

1 Like
5

FWIW, I spent a fair bit of time considering rotations in motion correction for spinal cord fMRI data, and looked carefully at images before and after rotational registration. Even with constraining the rotational parameters, the rotations would often bounce back and forth between the extremes. The spinal cord is approximately circular and thus challenging to accurately estimate rotations. Also, phase shifts in k-space (due to B0 inhomogeneities) result in translations in image space - not rotations. My suggestion is for the algorithms to focus on accurate and robust in-plane translations.

-Rob

2 Likes
6

Hi Julien and Rob,

Thank you for the info - that makes sense to me for the Z-translations. Also I take Rob’s great point in terms of rotations being difficult in the cord.

Thank you again!

7

yes, I second Rob about the rotations being tricky to properly correct for during motion correction. Most of the time we end up adding more spurious rotations than correcting the (non-) existing ones.

also, FWIW, sct_register_multimodal and sct_register_to_template include an algorithm to detection Z-rotation (-param algo=centermassrot) which works fairly well. It is using both the segmentation and the image. So in most cases, we would like to account for participants having their head slightly rotated in the scanner, when registering their spinal cord to the straight PAM50 template.

1 Like