Hello,
I am running fMRIPrep on a multi-echo dataset using 20.1.1. I am doing SDC as part of the workflow of fMRIPrep. I was looking the composite transformation (mat2itk.txt, _warpfieldQwarp_PLUS_WARP_fixhdr.nii.gz, out_fwd.tfm, ants_t1_tomniComposite) to the MNI, and I realized the transformation is performed to split_opt_comb/vol*
Tracking down the image from split_opt_comb, I ended up with bold_bold_trans_wf/_bold_file_..data..sub-<>..func..sub-<>_task-<>_run-<>_echo-1_bold.nii.gz/merge/vol0000_xform-00000_merged.nii.gz which seems to be motion and distortion corrected. If that is the case, fmriprep might be applying motion correction and the fieldwarp two times (thanks @tsalo ).
I only read the command.txt files saved in the working directory, so I may be missing something. Could you help me find the origin of split_opt_comb/vol*, if different from the one I found?
Thanks!
Here are some relevant sections of the code:
1) bold_split is data without any transforms (no HMC, SDC, or coregistration to T1w)
2) bold_std_trans_wf takes in bold_split for non-multi-echo, but it takes in split_opt_comb (optimally combined after STC, HMC, and SDC) for multi-echo.
3) bold_std_trans_wf expects data that hasn't been motion corrected, but can be slice timing corrected.
4) The ME-EPI workflow here seems to go meepi_echos --> bold_stc_wf --> boldbuffer --> bold_bold_trans_wf --> skullstrip_bold_wf --> join_echos --> bold_t2s_wf --> split_opt_comb --> bold_std_trans_wf.
5) The SE-EPI workflow here goes bold_reference_wf --> bold_stc_wf --> boldbuffer --> bold_split --> bold_std_trans_wf.
I think there are three solutions (assuming there isn鈥檛 a secret workaround that we haven't noticed yet):
bold_std_trans_wf.ref_std_trans_wf).bold_std_trans_wf for ME data specifically.bold_std_trans_wf can handle empty xform inputs, which is reasonable, but I haven't checked it yet.For maintainability, I'd prefer to avoid (2).
I think (3) is possible, we'd just need to validate whether the xforms exist and update the merge_xform connections appropriately. I'd prefer (3) over (1) in that it'd be a more readable solution, which should also help with maintenance over time !
One question: Does (3) imply dropping split_opt_comb from ME-EPI workflow?
I don't think so. It should just involve disconnecting the following connections in an if statement for ME data:
Plus ensuring that bold_std_trans_wf can handle missing xforms in the manner @emdupre proposed.
I agree that (3) is the best of those three options. I see two implementation options:
1) Condition the construction of the transform lists on whether we have multiecho.
2) Pass in an identity transform for anything that doesn't need to be applied. (antsApplyTransforms will just take the string "identity", so we don't even need to create identity files.)
That latter might simplify a bit of the conditional logic for SDC as well, since we currently determine the length of the transform list based on whether SDC is to be applied
@JulioAPeraza please try poldracklab/fmriprep:unstable.
Most helpful comment
For maintainability, I'd prefer to avoid (2).
I think (3) is possible, we'd just need to validate whether the xforms exist and update the
merge_xformconnections appropriately. I'd prefer (3) over (1) in that it'd be a more readable solution, which should also help with maintenance over time !