ENH: Allow tools to specify a default PhaseEncodingDirection for SyN-SDC

[effigies]

To recover SyN-SDC behavior in fMRIPrep, it's necessary to provide a default phase-encoding direction. Currently it would need to be added to the metadata, but it seems cleaner to make it an explicit argument.

[effigies]

Should be considered alongside nipreps/fmriprep#2530.

[codecov-commenter]

Codecov Report

Merging #232 (a96c4a4) into master (1620310) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #232   +/-   ##
=======================================
  Coverage   93.66%   93.66%           
=======================================
  Files          24       24           
  Lines        1673     1673           
  Branches      191      191           
=======================================
  Hits         1567     1567           
  Misses         81       81           
  Partials       25       25           

Flag	Coverage Δ
travis	88.94% <100.00%> (ø)
unittests	93.52% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
sdcflows/utils/wrangler.py	100.00% <100.00%> (ø)

---

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 1620310...a96c4a4. Read the comment docs.

[oesteban]

Sorry, I am really behind on these developments. As I commented on the other thread, this doesn't feel all right.

If the user does know the PhaseEncodingDirection, it should be found in the metadata.
If they know the PE axis, but they do not know the polarity, we should send a PR to the BIDS specs so that this can be written with the metadata, and/or perhaps allow nonstandard metadata for this particular in fMRIPrep/SDCFlows, but adding a shortcut like this seems the wrong move, as it has very very low friction for the user on something potentially dangerous, and it is very likely this is lost in reporting (i.e., likely to become not-transparent).

As opposed to the case of readout time (for which I propose that internally SDCFlows may use 1.0 if unknown, provided that the user is aware that the units of the fieldmap are unknown and it should be used will caution), in this case if you don't know the PE direction, then you'd rather not run fieldmapless at all.

Alternatively, we could run fieldmapless in BOTH possible axes and then pick the one that gave a better fit - although this goes into the rabbit hole of how you decide between two registration processes. But at least you can show both results with the visual report, and very clearly state that this was a decision made by fMRIPrep. Follow-up questions would include what happens if fMRIPrep determines different PE directions for two runs that were certainly acquired with the same direction (which is not unlikely to happen, I'd say).

[effigies]

Fair enough.