ENH: An initial implementation of SD estimation.

[oesteban]

Adds a new subworkflow based on FSL TOPUP to integrate SD estimation
for the ds001771 dataset.

• Pin niworkflows to current master (while I release 1.2.0rc5
  containing FIX: Merge/SplitSeries write to path of input image, instead of cwd niworkflows#503, FIX: Add DWI default patterns for dMRIPrep's reportlets niworkflows#504, which
  are used here).
• Create a new sdc estimation workflow, with the expectation of
  upstreaming it to SDCFlows.
• Implement the barebones of how RFC: New heuristics table sdcflows#101 could look
  like. Also to be upstreamed to SDCFlows when mature.
• Stick TOPUP from FSL 6.0.3 in the Docker image, since topup from
  FSL 5.0.x is really unstable (for instance, it fails with a
  segmentation fault on the workflow of ds001771)

Resolves: #92

[pull-assistant]

Best reviewed: commit by commit

---

Optimal code review plan

     feat(TOPUP): an initial implementation of SD estimation.

     fix: add a --sloppy mode for topup to fit in Circle

     enh: use sdcflows.interfaces.fmap.get_trt instead of custom functi...

Powered by Pull Assistant. Last update a05e701 ... cb11a51. Read the comment docs.

[codecov]

Codecov Report

Merging #97 into master will decrease coverage by 1.25%.
The diff coverage is 19.60%.

@@            Coverage Diff             @@
##           master      #97      +/-   ##
==========================================
- Coverage   51.37%   50.11%   -1.26%     
==========================================
  Files          20       21       +1     
  Lines        1238     1289      +51     
  Branches      162      169       +7     
==========================================
+ Hits          636      646      +10     
- Misses        590      631      +41     
  Partials       12       12              

Impacted Files	Coverage Δ
dmriprep/workflows/fmap/base.py	18.75% <18.75%> (ø)
dmriprep/workflows/base.py	22.72% <33.33%> (+0.37%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6792e96...cb11a51. Read the comment docs.

[pep8speaks]

Hello @oesteban, Thank you for updating!

Cheers! There are no style issues detected in this Pull Request. 🍻 To test for issues locally, pip install flake8 and then run flake8 dmriprep.

Comment last updated at 2020-06-02 23:43:34 UTC

[dPys]

FYI-- if you want to bump up the fsl version (I've recently encountered a number of issues with the neurodebian fsl-5.0 libraries), I've worked out the following:

RUN apt-get update -qq \
    && apt-get install -y --no-install-recommends curl libquadmath0 \
    && curl -sSL https://fsl.fmrib.ox.ac.uk/fsldownloads/fsl-6.0.2-centos7_64.tar.gz | tar xz -C /usr/local \
       --exclude='fsl/doc' \
       --exclude='fsl/data/first' \
       --exclude='fsl/data/atlases' \
       --exclude='fsl/data/possum' \
       --exclude='fsl/src' \
       --exclude='fsl/extras/src' \
       --exclude='fsl/bin/fslview*' \
       --exclude='fsl/bin/FSLeyes' \
       --exclude='fsl/bin/*_gpu*' \
       --exclude='fsl/bin/*_cuda*' \
    && chmod 775 -R /usr/local/fsl/bin \
    && chown -R neuro /usr/local/fsl

It does add some GB to the build though...

[oesteban]

bumping fsl will definitely break nipype at points... so probably not the rabbit hole I'd like to explore right this minute... I agree in some time we will be updating to 6.0 (and then your code will be very useful).

[dPys]

Yeah, probably best to wait then. I wish there was an organized bookmarking system on github so that we could more easily remember to revisit/ priority-mark these kinds of things!

[oesteban]

Alright, the report with TOPUP-estimated field is here - https://460-233429127-gh.circle-artifacts.com/0/tmp/ds001771/derivatives/dmriprep/sub-36.html

[oesteban]

@dPys @mattcieslak @josephmje how does this look?

https://460-233429127-gh.circle-artifacts.com/0/tmp/ds001771/derivatives/dmriprep/sub-36.html

[dPys]

@dPys @mattcieslak @josephmje how does this look?

https://460-233429127-gh.circle-artifacts.com/0/tmp/ds001771/derivatives/dmriprep/sub-36.html

Hi @oesteban -- this looks REALLY nice to me. Question-- do the reports need to visualize the inhomogeneity outside of the brain or do you think we should just mask it so that users don't get alarmed by the amount of out-of-brain field inhomogeneity?

[oesteban]

Question-- do the reports need to visualize the inhomogeneity outside of the brain or do you think we should just mask it so that users don't get alarmed by the amount of out-of-brain field inhomogeneity?

This question is THE QUESTION. On the one hand, I do agree it is alarming (especially to the non-familiar eye). On the other hand, I think it is nice to compare how different methods regularize outside the brain differently. For instance, the traditional FUGUE correction (the infamous epiunwarp.fsl script) extrapolates (constant) the values at brain edges along the PE axis. That produces this kind of "rays":

Would you mind filing an issue about this at SDCflows?