[ENH] Adds extraction of physio signals from DICOMs

[pvelasco]

It uses bidsphysio to extract physiological signals from CMRR EPI DICOMs.

It includes regression test

[codecov[bot]]

Codecov Report

Merging #446 (15e4a49) into master (d8e5c5f) will increase coverage by 0.95%. The diff coverage is 91.39%.

@@            Coverage Diff             @@
##           master     #446      +/-   ##
==========================================
+ Coverage   76.01%   76.96%   +0.95%     
==========================================
  Files          38       40       +2     
  Lines        3010     3100      +90     
==========================================
+ Hits         2288     2386      +98     
+ Misses        722      714       -8     

Impacted Files	Coverage Δ
heudiconv/info.py	100.00% <ø> (ø)
heudiconv/utils.py	89.91% <ø> (ø)
heudiconv/dicoms.py	85.77% <66.66%> (+4.62%)	:arrow_up:
heudiconv/convert.py	85.71% <70.58%> (+0.43%)	:arrow_up:
heudiconv/heuristics/bids_PhoenixReport.py	93.33% <93.33%> (ø)
heudiconv/heuristics/bids_physio.py	94.11% <94.11%> (ø)
heudiconv/tests/test_dicoms.py	100.00% <100.00%> (ø)
heudiconv/tests/test_heuristics.py	100.00% <100.00%> (ø)
heudiconv/tests/test_main.py	100.00% <100.00%> (ø)
heudiconv/tests/test_regression.py	93.75% <100.00%> (+1.75%)	:arrow_up:
... and 4 more

---

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 d8e5c5f...15e4a49. Read the comment docs.

[yarikoptic]

re blacking: I don't mind at all. But we have outstanding sizeable PRs so it would introduce conflicts... will need to check with @tsalo and @bpinsard

[pvelasco]

another consideration while looking at this - WDYT about fetching the data via datalad instead of hosting it in the repo?

Of course, that would be great. You can just download the data from my branch, or I can send you a zip file with them. Once they are in DataLad, I'll modify the regression tests accordingly.

[tsalo]

@yarikoptic, I like automated code formatting, but I think running black would introduce a ton of conflicts in #442. Could aggressive re-formatting be something that's done in its own PR after the pending larger PRs are handled?

[mgxd]

of course, it would make it nearly unreviewable! I meant showing some love to formatting prior to the next release, and then inserting a style check into our CI

[yarikoptic]

Just a note (I am ok either way): theoretically (didn't try yet) if there is no value in individual commits in a or (or if they are way to split from a full diff, eg different files), and both branches are auto blacked when pr branch having master branch merged right before blacking - should be easy to force refresh PRs with blacked version ;-) I can try if we decide to black it all

[yarikoptic]

Re data - I think it is time to remove the middle man me! Let's (ab)use lfs of GitHub with datalad: http://handbook.datalad.org/en/latest/basics/101-138-sharethirdparty.html?highlight=Lfs#use-github-for-sharing-content . I will initiate a repo with the content of this PR data files, and invite everyone possibly interested ;-)...

[yarikoptic]

Thinking about it - iirc dicoms compress nicely. I will try with enabling shared encryption - that should compress them while stored in lfs.