How could ihMT/ihMTRAGE fits in BIDS naming?
Or should it be named with a non-BIDS suffix awaiting a future update?
On Siemens and GE, it results in 1 series with 1 file with 6 volumes.
Tried to read the papers to understand what they correspond to, but it is beyond my capacity to understand.
Just want to convey what our physicist is saying on ihMTRAGE:
if you look at the 4D dataset it’ll be MT0 (no MT), MTw-singlepos (MT-weighted with single positive frequency saturation), MTw-dual1 (MT-weighted dual frequency saturation), MTw-singleneg (MT-weighted with single negative frequency saturation), MTw-dual2 (MT-weighted dual frequency saturation, same as number 3)
It looks like there aren’t any entities that correspond to the saturation pulses or their directions, so I’m leaning toward using acq, even though it’s meant to distinguish separate acquisitions:
Thanks @tsalo for all these information!
Having to split the 4D nifti requires post-heudiconv edit, and generating sensible json sidecars with the appropriate metadata is not straightforward.
So you would lean towards a non-existent suffix while awaiting the spec to evolve?
Yeah, using a new suffix with reasonable entities is probably the best bet, since you can just include it in the .bidsignore and there’s less likelihood that it’ll conflict with existing suffix use-cases.
I’ll see if we can acquire some phantom data with ihMT and/or ihMTRAGE that we can use for a BIDS PR.