Provide BOLD to T1w affine transform in the output folder

[gkaguirre]

This issue regards a question raised by @bbfrederick on neurostars.

bbregister is used to register a BOLD template image to the T1-weighted structural in the routine init_bbreg_wf (link). The request is to by default save the transforms that map BOLD to T1w space. This would allow users to subsequently transform volumes between subject native space, MNI space, and between T1w and EPI resolutions with greater ease.

Tagging @oesteban and @chrisfilo, who were also in the discussion.

[chrisgorgo]

If this transform works out of the box this issue seems to be relatively easy to fix. Mostly connecting the right nodes. Great way to get involved in the project - would you like to give it a try?

[gkaguirre]

Good call. Let me take a look.

[bbfrederick]

If subjworkroot is the individual subject's functional workflow directory (apologies for csh script strangeness - I'm converting this to a cleaner python scripts):

set subjworkroot=$workdir'/fmriprep_wf/single_subject_'$subj'wf/func_preproc'$thisrun'_wf'

Then it seems there are 2 (or 3) necessary files depending on whether you do field map correction:
set affinetarget=$subjworkroot'/bold_reg_wf/bbreg_wf/fsl2itk_fwd/affine.txt'
set lorest1=$subjworkroot'/bold_reg_wf/gen_ref/highres001_N4Corrected0_masked_reference.nii.gz'
warptarget=$subjworkroot'/sdc_wf/syn_sdc_wf/syn/ants_susceptibility0Warp.nii.gz'

If you don't do field map correction, you then apply:
antsApplyTransforms \
--default-value 0 \
--float 1 \
--input mapinboldspaceIwantinT1space.nii.gz \
--interpolation LanczosWindowedSinc \
--output transformedmap.nii.gz' \
--reference-image $lorest1 \
--transform $affinetarget

If you do the synthetic field map correction, you then apply:
antsApplyTransforms \
--default-value 0 \
--float 1 \
--input mapinboldspaceIwantinT1space.nii.gz \
--interpolation LanczosWindowedSinc \
--output transformedmap.nii.gz' \
--reference-image $lorest1 \
--transform $affinetarget \
--transform $warptarget

Tried this out and it worked on a couple example files - but this does not include any of the cases Chris mentioned where the initial warp is wacky

There is one caveat to be aware of. When we do bold to T1w coregistration we use a reference image constructed (via some heuristics) from the bold timeseries. The same image is used as a motion correction target. Since we apply bold2T1w after applying motion correction transformation this does not matter. However, you will be applying it without the motion correction. In a rare case that our reference image creation heuristic does something funky to the orientation (LAS -> RAS or something like this) you might experience some funky results.

[gkaguirre]

@bbfrederick: Please do take the lead on implementing a fix and issuing a PR, as you are much further along on defining the solution. I can offer to test your branch if that is helpful...

[bbfrederick]

First dumb question - what's a PR?

I'm certainly willing to take a look at the nipype nodes, but that will take some amount of time to get up to speed on that, not being familiar with the code base - I just had a cheesy script that digs out the files after the fact and applies the transforms, but yes, fixing the nodes is the right way to do it. I'll check in as soon as I get oriented.

[gkaguirre]

A PR is a “pull request”. Basically, you create your own fork of the fmriprep repo. In your fork, you edit the code to implement the fix. Once you’ve tested it, you issue a pull-request for your changes, which is an invitation for the fmriprep admins to look at your code changes and consider merging them into the main branch of the fmriprep code base.

GitHub has excellent intro tutorials on the process.

[bbfrederick]

Ah ok, cool. I should really know that, since I have a few things up on GitHub - but so far nobody has sent new code...

Off to work then.

[chrisgorgo]

Great to get your help! This FMRIPREP specific guide should help https://github.com/poldracklab/fmriprep/blob/master/CONTRIBUTING.md. Please also note that the fmriprep-docker wrapper is capable of injecting development (local) source code of FMRIPREP which is super handy for testing.