MAINT: Select magnitude images in collect_data for BIDS 1.5.0

[tsalo]

Closes #591.

In BIDS 1.5.0, the part entity will be released. part can have a value of mag, phase, real, or imag, of which only mag is used for most preprocessing pipelines. When part is not provided, the data are assumed to be magnitude.

Changes proposed:

• Add part == mag or None to filters in collect_data() for T1w, T2w, FLAIR, and BOLD data.
• Add new entities (part, inv, flip, and mt) to config file.

[effigies]

@tsalo can you merge/rebase master? The CI failure may have already been fixed.

[tsalo]

Done!

[tsalo]

BTW would it be reasonable to select T1w and T1map instead of just T1w? Same for T2w.

[effigies]

Because we haven't tested fMRIPrep on T1map data, I would be inclined instead to encourage users to create a BIDS filter file to find the T1maps, until we gain some confidence that we can work with them automatically.

I'm currently imagining a new section to the docs with "Advanced and experimental use cases" where we explain how to do things that are possible but not (yet) supported. Open to other ideas.

[effigies]

RE the current failure, I think we need to update https://github.com/nipreps/niworkflows/blob/master/niworkflows/data/nipreps.json to include part.

[tsalo]

Because we haven't tested fMRIPrep on T1map data, I would be inclined instead to encourage users to create a BIDS filter file to find the T1maps, until we gain some confidence that we can work with them automatically.

That makes sense. Thanks for the clarification.

I'm currently imagining a new section to the docs with "Advanced and experimental use cases" where we explain how to do things that are possible but not (yet) supported. Open to other ideas.

That sounds awesome!

RE the current failure, I think we need to update https://github.com/nipreps/niworkflows/blob/master/niworkflows/data/nipreps.json to include part.

Done. I also added the rest of the new entities. LMK if that's a problem.

[tsalo]

I think this may require a new pybids release. I could pin to a commit in the setup.cfg though?

[effigies]

Ah, you're right. We're using a vanilla BIDSLayout, not passing our own. I think it's fine to leave the new entities in our JSON.

@tyarkoni Any objections to a PyBIDS release with entities that precede the BIDS spec release that makes them official? They're already merged into master, just pending a release.

[tyarkoni]

None objection!

[oesteban]

We will need to also update the default_path_patterns in nipreps.json if we want to generate derivatives of these data types.

[tsalo]

@oesteban that's a good point. I know where part comes in, but I'm less sure about how to handle the other entities. They all apply specifically to anatomical data, but incorporating them might require basically supporting qMRI (i.e., considering which suffixes accept each entity rather than bundling all anatomical suffixes together).

[oesteban]

I know I'd use part-mag for preprocessed fieldmaps. Although the raw spec does not allow it for the moment, we can push at least that to the BIDS-Derivatives.

[tsalo]

I've updated the default path patterns to include part. I don't think the other ones are necessary just yet, and I'm reticent to try incorporating all of qMRI in this PR.

[effigies]

This will depend on bids-standard/pybids#826.