I have my own .par file from MELODIC, but I was wondering how I can use it in the afni_proc.py command? FSL’s MELODIC outputs a .par file, which contains all the motion parameters. I want to regress out these motion parameters. So I’m not sure how to incorporate that into afni_proc.py . Do I need to change the file type to a 1D?
Here’s an example code of what I expect to run:
-regress_apply_mot_types motionparameters.par \
Can I include the .par file the way I just did?
Yes, you would want to convert the *.par file (which seems an odd format for MELODIC to output in?) into a 1D file, or a set of 1D files. Actually, I wasn’t aware that MELODIC output motion parameter files-- to be clear, these motion parameter files are 6 sets of numbers, for the 3 rotation and 3 translation parameters?
Assuming these time series to include in the regression are not voxelwise estimates, but each applies to the whole brain, you would use this option to include them (any extra time series, actually) in the afni_proc.py regression model:
-regress_extra_stim_files FILE1 ... : specify extra stim files
e.g. -regress_extra_stim_files resp.1D cardiac.1D
e.g. -regress_extra_stim_files regs_of_no_int_*.1D
Use this option to specify extra files to be applied with the
-stim_file option in 3dDeconvolve (as opposed to the more usual
These files will not be converted to stim_times format.
Corresponding labels can be given with -regress_extra_stim_labels.
See also -regress_extra_stim_labels, -regress_ROI, -regress_RONI.
But note that regressing motion parameters is only part of the use of motion estimates. One typically also censors based on them (the “enorm” parameter from the motion estimates, in AFNI), and also one performs geometric motion correction with the estimates: that is, one wants to include the rigid body parameters as affine alignment parameters, concatenating them with EPI → anatomical and anatomical → template alignment steps, say. You will have to make sure that whatever format MELODIC is outputting their motion estimates in, it matches with AFNI’s syntax (coordinates, dset orientation, etc.). That might be somewhat complicated, actually. Also, I am not
Is there any particular reason not to use the standard AFNI volreg motion estimate? It has been rated as quite good:
and will definitely integrate into the processing more easily.