ArtifactDetect on FSFAST (AFNI) motion-corrected data

[Chris Johnson]

In preproc-sess, FSFAST uses the mc-afni script to perform motion correction, which in turn calls AFNI's 3dvolreg. The motion parameters are saved in an .mcdat file, which looks like this:

   0  -0.0000   0.0000   0.0000  -0.0000   0.0000   0.0000            0           0   0.000
   1  -0.0131   0.0151   0.0122   0.0601   0.0098   0.0239        64.62       64.63   0.065
   2   0.0224   0.0210  -0.0647  -0.0120  -0.0903   0.0410        30.56       30.14   0.100
   3  -0.0351   0.0699  -0.0273  -0.0241  -0.1217   0.0269        63.69       63.43   0.127
...

I have providing these .mcdat files, along with the associated motion-corrected NIfTIs, to rapidart's ArtifactDetect:

afni_artdetect = pe.Node(
    interface=ra.ArtifactDetect(parameter_source='AFNI',
                                mask_type='spm_global',
                                norm_threshold=1.0,
                                zintensity_threshold=3.0,
                                use_differences=[True, False]),
    name='afni_artdetect')

This produces somewhat odd results:

To compare, I ran motion correction on SPM and ran through a similar ArtifactDetect (with the parameter_source changed to 'SPM'):

I have plotted the parameters, and there are differences between SPM and FSFAST, but nothing that explains this difference in ArtifactDetect's results. It's possible that FSFAST performs a transformation on the AFNI results, and so ArtifactDetect is not using the correct columns from the .mcdat files. If this is the case, we might want to add an 'FSFAST' parameter_source.

Anyway, hope somebody more familiar with rapidart will see the problem immediately. Otherwise, I'll be digging through code to see how these parameter files are treated differently.

Thanks,
Chris

[Satrajit Ghosh]

hi chris,

can you run it through 3dvolreg and send that output to artifactdetect? i've never used it on fsfast output before, but 3dvolreg normally produces a 6 column file.

see: http://afni.nimh.nih.gov/pub/dist/doc/program_help/3dvolreg.html

here is an example:

https://github.com/INCF/BrainImagingPipelines/blob/master/bips/workflows/gablab/wips/scripts/modular_nodes.py#L47

cheers,

satra

--
 
---
You received this message because you are subscribed to the Google Groups "NiPy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nipy-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Chris Johnson]

Satra,

Sure, I can have a look at that. In the meantime, I tried telling ArtifactDetect to look 1 column to the right (https://github.com/nipy/nipype/pull/706) and this resulted in a much greater resemblance (across multiple subjects) to the SPM-based artifact detection.

If it turns out the 3dvolreg doesn't simply produce columns 1-7 of FSFAST, I'll report back.

Chris

[Chris Johnson]

The difference in motion parameter files is whether 3dvolreg is called with -1Dfile or -dfile. afni.preprocess.Volreg uses -1Dfile, while FSFAST uses -dfile.

From 3dvolreg help:

  -dfile dname    Save the motion parameters in file 'dname'.
                    The output is in 9 ASCII formatted columns:

                    n  roll  pitch  yaw  dS  dL  dP  rmsold rmsnew

  -1Dfile ename   Save the motion parameters ONLY in file 'ename'.
                    The output is in 6 ASCII formatted columns:

                    roll pitch yaw dS  dL  dP

           where:   n     = sub-brick index
                    roll  = rotation about the I-S axis }
                    pitch = rotation about the R-L axis } degrees CCW
                    yaw   = rotation about the A-P axis }
                      dS  = displacement in the Superior direction  }
                      dL  = displacement in the Left direction      } mm
                      dP  = displacement in the Posterior direction }
                   rmsold = RMS difference between input brick and base brick
                   rmsnew = RMS difference between output brick and base brick

Perhaps something along these lines would have been a better fix than my earlier patch?

diff --git a/nipype/algorithms/rapidart.py b/nipype/algorithms/rapidart.py
index 7d8709b..d12c5fb 100644
--- a/nipype/algorithms/rapidart.py
+++ b/nipype/algorithms/rapidart.py
@@ -47,7 +47,7 @@ def _get_affine_matrix(params, source):
     if source == 'FSL':
         params = params[[3, 4, 5, 0, 1, 2]]
     elif source == 'AFNI':
-        params = params[[4, 5, 3, 1, 2, 0]]
+        params = params[np.asarray([4, 5, 3, 1, 2, 0]) + (len(params) > 6)]
         params[3:] = params[3:] * np.pi / 180.
     if source == 'NIPY':
         # nipy does not store typical euler angles, use nipy to convert

It might still be good to keep an FSFAST option, just so that users coming from that environment immediately know what to use, but anybody with a pipeline that uses `3dvolreg -dfile` will presumably expect to be able to use the AFNI source, and so the parameter list should be checked for length.

Chris

[Satrajit Ghosh]

thanks chris,

this patch looks good. please send it as a PR. i already merged the other one.

cheers,

satra