The ReproIn heuristic (reproin) currently uses suffixes to distinguish complex-valued fMRI data (see below). However, the phase suffix is deprecated in favor of the part entity.
The difficult thing is that infotodictis run separately on each run loops over runs, and magnitude and phase data from the same run are typically (at least with the CMRR MB sequence) split into separate folders of DICOMs (magnitude first). I don't know how to flexibly identify magnitude BOLD runs that need part-mag (i.e., runs with phase data also reconstructed) vs. those that don't (magnitude-only reconstruction).
I'm thinking maybe that the filename_suffix_parts list could be built with part included by default, then it could be collected across runs, and then if there aren't any cases where everything else is the same except for part, the part entity could be removed.
Summary
The ReproIn heuristic (
reproin) currently uses suffixes to distinguish complex-valued fMRI data (see below). However, thephasesuffix is deprecated in favor of thepartentity.https://github.com/nipy/heudiconv/blob/4c2c2c06835f26474bc2c710a228242d2cdd45b3/heudiconv/heuristics/reproin.py#L501-L504
The difficult thing is that
infotodictis run separately on each runloops over runs, and magnitude and phase data from the same run are typically (at least with the CMRR MB sequence) split into separate folders of DICOMs (magnitude first). I don't know how to flexibly identify magnitude BOLD runs that needpart-mag(i.e., runs with phase data also reconstructed) vs. those that don't (magnitude-only reconstruction).I'm thinking maybe that the
filename_suffix_partslist could be built withpartincluded by default, then it could be collected across runs, and then if there aren't any cases where everything else is the same except forpart, the part entity could be removed.Platform details:
n/a