Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide BOLD to T1w affine transform in the output folder #1184

Open
gkaguirre opened this issue Jul 2, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@gkaguirre
Copy link

commented Jul 2, 2018

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 chrisgorgo changed the title Retain warp transforms by default Provide BOLD to T1w affine transform in the output folder Jul 2, 2018

@chrisgorgo chrisgorgo added the feature label Jul 2, 2018

@chrisgorgo

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2018

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

This comment has been minimized.

Copy link
Author

commented Jul 2, 2018

Good call. Let me take a look.

@bbfrederick

This comment has been minimized.

Copy link

commented Jul 2, 2018

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

This comment has been minimized.

Copy link
Author

commented Jul 2, 2018

@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

This comment has been minimized.

Copy link

commented Jul 2, 2018

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

This comment has been minimized.

Copy link
Author

commented Jul 2, 2018

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

This comment has been minimized.

Copy link

commented Jul 2, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2018

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.

@oesteban oesteban added this to the 1.4.3 milestone Jul 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.