WIP/including optional fieldmap unwarping in rsfmri example workflow

[juhuntenburg]

A first attempt to add fieldmap unwarping to the rsfmri_vol_surface_preprocessing_nipy example workflow, I'd be happy about comments and suggestions.

I have tested it with my data, but maybe testing with different data would be good.
Next I will try to include optional registration of mean EPI and fieldmap.

[oesteban]

Hi @juhuntenburg, why don't you use this workflow:

nipype/nipype/workflows/dmri/fsl/artifacts.py

Line 515 in fc0d9bb

def sdc_fmb(name='fmb_correction', interp='Linear',

We would not be re-inventing the wheel, and we can test it on your fMRI data :)

[coveralls]

Coverage decreased (-0.02%) to 70.46% when pulling 6a04f6b on juhuntenburg:WIP/FieldmapRsmriWorkflow into 5ca0086 on nipy:master.

[juhuntenburg]

Thanks @oesteban! I wasn't aware of this workflow (never really checked the dMRI ones).

However, the motivation here was to extend the existing rsfMRI workflow to make it suitable for data that comes with fieldmaps. In our group it often turns out to be very useful to have a complete preprocessing workflow like this, that has good defaults and is easy to use even when being a nipype beginner. A less flexible but maybe even more straightforward alternative to BIPs and CPAC if you will.

Or was your suggestion to use the workflow you mentioned within the rsfMRI one?

[oesteban]

@juhuntenburg yes, the workflow I've pointed out should work on rsfMRI data as well.

Details:

• Provide the reference volumes (baseline) in an array to inputnode.in_ref. If you only have one reference volume at the begining, then pass [0]

• Settings can be passed using inputnode.settings. These are the defaults:

  epi_defaults = {'delta_te': 2.46e-3, 'echospacing': 0.77e-3, 'acc_factor': 2, 'enc_dir': u'AP'}
  

If you don't like these settings, you can write a JSON file with your settings:

{
    delta_te = 2.46e-3,
    echospacing = 1.0,
    acc_factor = 2,
    enc_dir = 'AP'
}

I'm not sure these parameters are also ok for fMRI, please let me know and I will help with them.

[juhuntenburg]

@oesteban ok, just to be on the same page: you would suggest to import that workflow into rsfmri_vol_surface_preprocessing_nipy?

In that case, I would make the settings you mention all inputs specified by the user, as they differ from sequence to sequence (although delta_te will mostly be 2.46).

Also, I was wondering what's the reason to reproduce the steps in fsl_prepare_fieldmap instead of using this http://nipy.sourceforge.net/nipype/interfaces/generated/nipype.interfaces.fsl.epi.html#preparefieldmap ?

Thanks!

[juhuntenburg]

Or, actually I could probably try to derive this information automatically from the dicoms that are already an optional input to the workflow.

[oesteban]

@juhuntenburg:

Q1: why not fsl_prepare_fieldmap instead? -> I wrote that pipeline to use it isolated. I stopped using it because the equivalent inside scd_fmb is better (IMHO). Actually, in next releases I intend to replace prelude (FSL) for the phase unwrapping. In my experience, it is not very robust and better algorithms are there (particularly I will use the one in scipy). If you use sdc_fmb, you will keep everything updated.

Q2: read parameters from dicoms? -> Sure!, but you will need to pass a file to the workflow. Therefore, you'll need a JSONFileSink (http://www.mit.edu/~satra/nipype-nightly/interfaces/generated/nipype.interfaces.io.html#jsonfilesink) to write them to a file.

[juhuntenburg]

@oesteban ok great! I don't really have time to make the changes and test now but I will do so as soon as I get the chance.

[chrisgorgo]

We are planning to make a new release soon - any chance of finishing this soon(ish)?

[juhuntenburg]

Sorry, not this week..

[effigies]

This pull request is "orphaned," which means it has been deemed to be abandoned by its original author. Orphaned pull requests have not been rejected, and we hope that if a user sees one that will meet their needs with a little work, that they will fork it and open a new pull request (or, in the case of the original author, reopen the original PR).

We ask that all adopted PRs be updated to merge or rebase the current master. If you would like to adopt a PR and need help getting started, any of a number of contributors will be happy to help.