AFNIproc.py after fMRIprep.

AFNI Message Board
1

Dear AFNI experts,

I have been convinced to use fMRIprep for the initial steps of the preprocessing.

First question: motion parameter file
fMRIprep returns a very large file with all the regressors that one might want to remove (e.g., the motion parameters, among others). However, I’m unsure how to correctly create the motion regressor file to possibly continue using AFNIproc.py.
1- I’ve opened a dfile_rall.1D from prior preprocessing with AFNI, and I see what I suppose are the six motion parameters (one per column). Is the order relevant? 2- Can I create this file with a simple text editor by copying and pasting?
3- If I call my file with the same name, will it be possible to use AFNIproc.py with the remaining blocs for motion correction, censoring, and first-level analyses?
4- Some suggest adding a few more noise regressors to the basic 6 motion parameters; should this be done at this level? Will it impact the motion censor step?

Another difference with fMRIprerp is the reference used in the slice timing correction. Apparently, for short TRs, the difference in slice timing correction is not relevant. I’m unsure what is a short TR. My study has a 1020ms TR. Is this TR short enough to make the difference irrelevant, or should I correct the Stimuli times by subtracting TR/2?

After fMRIprep, I hope to run the following blocks: blur, scale (I don’t think it’s being done in fMRIprep), and regress.
I believe that the equivalent of shift, align, tlrc, and volreg is performed with fMRIprep.

Thank you for your insight and guidance,
ilaria

2

Iliara,
I would not consider myself an AFNI expert, but I would not recommend "mixing and matching" these preprocessing pipelines, as neither of them are designed to interoperate. fMRIPrep is intended to replace all other programs' preprocessing, by doing the "mixing and matching" between major packages for you. If your plan is to do a GLM, etc. in AFNI then I would recommend just using afni_proc.py. There are many subtle sorts of errors (see below) that can be introduced if you're not very careful.

  1. Yes, the order is relevant. See the 3dvolreg help under "-dfile": AFNI program: 3dvolreg

n roll pitch yaw dS dL dP rmsold rmsnew

  1. Yes, any ASCII text matching AFNI's specifications for a regressor should work; see, for example, the help for 3dREMLfit: AFNI program: 3dREMLfit (unless you mean to censor motion, in which case it's probably easier to manually specify volumes that you would like censored in 3dDeconvolve; see -CENSORTR)
  2. Sorry, I'll have to wait for somebody else to answer that.
  3. Additional regressors will not impact motion censoring.

For slice timing, the note in 3dTshift points out how the timings affect operations like 3dDeconvolve: AFNI program: 3dTshift

The new slice/volume timing is intended to be the real timing from the
start of the run.

How might this affect stimulus timing in 3dDeconvolve?
3dDeconvolve creates regressors based on volume times of k*TR, matching
tzero=0. So an event at run time t=0 would start at the time of volume
#0. However using -tzero 1 (or the default, in the case of TR~=2s),
an event at run time t=0 would then be 1s before the first volume.
Note that this matches reality. An event at time t=0 happens before
all but the first acquired slice. In particular, a slice acquired at
TR offset 1s might be unaffected by 3dTshift. And an event at run time
t=0 seems to happen at time t=-1s from the perspective of that slice.

To align stimulus times with the applied tzero of 3dTshift, tzero
should be subtracted from each stimulus event time (3dDeconvolve
effectively subtracts tzero from the EPI timing, so that should be
applied to the event times as well).

It is not clear to me if fMRIPrep would make the same guarantees as 3dTshift (representing a possible interoperability issue).

However, 1s is pretty short, you may use slice time correction but it may not make much of a difference.

3

You might check out this article on slice timing and modeling if you are concerned: https://reproducibility.stanford.edu/slice-timing-correction-in-fmriprep-and-linear-modeling/

4

Hi Ilaria,

Just adding a few comments to the useful reply from jbteves.

Indeed, since fmriprep seems to do preprocessing through alignment, some external package will be needed to complete processing through linear regression, and afni_proc.py can do that. The most important thing is for you to have a good idea of what fmriprep has and has not done. Whether you use the MELODIC output might affect what you ask afni_proc.py to do.

  1. Indeed, the order of volreg parameters matters, though not too much from the perspective of afni_proc.py.

For censoring (via the enorm time series, generated as the Euclidean norm of the first diffs of the parameters) and regression, the order will not affect the results. The order will affect what is plotted in the HTML report, as it assumes the order from 3dvolreg. But that is just for labeling, not a big deal.

But you can always reorder the 6 columns as from 3dvolreg: roll, pitch, yaw, dS, dL, dP. It is the -1Dfile format that is applied.

Note that you would not be able to do outlier censoring (though that could be done separately, with a censor file passed to afni_proc.py via -regress_censor_extern).

External motion parameters should be passed via -regress_motion_file.

  1. As jbteves notes, yes, the regressors are just text files of numbers. You can pass one or multiple matrices of these, or individual columns as you see fit. Multi-column (matrix) inputs could be passed via -regress_extra_ortvec, labeled with the corresponding -regress_extra_ortvec_labels option. I would suggest one file per type, just to have an appropriate label attached, e.g. motion_deriv or comp_cor_6.

Note that you would not pass the motion parameters to afni_proc.py this way (use -regress_motion_file).

You should be able to regress the first differences too if you choose, maybe applying “-regress_apply_mot_types demean deriv”. Or you can pass the first differences as an ortvec (-regress_extra_ortvec) as you see fit.

  1. Yes, you can tell afni_proc.py which blocks to run via something like “-blocks mask blur scale regress”. If it has the motion parameter file, it can censor from that. You can also (additionally) provide an external censor file, which would be combined with any motion censoring (e.g. outliers).

  2. Yes, if you want to include other noise regressors, they should be applied in the same regression model at this level. Consider use of one or more -regress_extra_ortvec options.

It is important to keep all regressors in a single model, including censoring (and possibly but hopefully not bandpassing).

That is right, as jbteves also notes. If you verify that fmriprep is using 3dTshift to align to the middle of the TR, that offset should be subtracted from the stimulus times. This correction can be applied in afni_proc.py via -regress_stim_times_offset, or separately using timing_tool.py -add_offset, passing the negative offset in either case. Note that the offset is not exactly TR/2, but it is close (TR/2 * (nslices-1)/nslices).

Hopefully this seems reasonable.

  • rick
5

Thank you both for your extensive replies; I will be studying what you wrote!

Ilaria

6

Hi Rick,

Suppose I have multiple columns of extra regressors in a file variable.txt, and use them as


3dDeconvolve ... \
    -ortvec  variable.txt var_name \
...

Is there a way to specify var_name such that each column in variable.txt has a different name in the X.xmat.1D file? As of now it seems they take the format var_name[0]#0, var_name[1]#0, …

Thanks,
Erik

7

HI Erik,

No, but you can use 1dcat, 1d_tool.py or whatever software to extract sets of columns into separate files. Then pass one file at a time using multiple -ortvec options, each with its own label. I suggest partitioning such regressors into a few sets, not just a single column per ortvec. But anyway, then you can give each ortvec its own label. You can pass them all as one set (as you seem to be now), go down to one ortvec per column (with its own label), or anything in between.

  • rick