[BUG] How motion parameters estimated by the MRI scanner should be encoded?

[oesteban]

Describe your problem in detail.

Currently, the physiology section reads:

https://github.com/bids-standard/bids-specification/blob/05f64ed77c5e6401ca39b479f02597acff4dba92/src/modality-specific-files/physiological-and-other-continuous-recordings.md?plain=1#L174-L175

while a new "Motion" section was integrated as a BEP in #443.

The question is whether these motion parameters should also be encoded with the _motion suffix or the _physio suffix.

Describe what you expected.

No response

BIDS specification section

https://bids-specification.readthedocs.io/en/stable/modality-specific-files/physiological-and-other-continuous-recordings.html#recommendations-for-specific-use-cases

and

https://bids-specification.readthedocs.io/en/stable/modality-specific-files/motion.html

[Remi-Gau]

Or get some inspiration from the way motion related time series are described in the functional derivatives BEP?

https://bids-specification--519.org.readthedocs.build/en/519/derivatives/functional-derivatives.html#motion-related-time-series

[oesteban]

The way I see it is that the current "raw" specification is unclear (at best) or conflicting (at worst) between the two physio and motion specs. The problem is relatively contained by the specificity of the physio specs, which (weirdly, IMHO) point at "motion parameters estimated by the MRI scanner" (i.e., other motion tracking options seem to be dismissed).

Once motion has permeated the "raw" spec as its own suffix, this looks to me like the "MRI scanner" should be considered a motion tracking device and therefore should be encoded as _motion and remove the note from physio.

A different topic (which IMHO deserves its own issue) is harmonizing motion between raw and derivatives. I can't quite understand how motion in "raw" was not dealt with within physio as it seems to be the intent in the phrasing of physio for a long while ago. If that issue were opened, I honestly feel motion in "raw" should be deprecated and encoded with physio. I would not propose deprecation of the motion "derivatives" though.

[Remi-Gau]

I can't quite understand how motion in "raw" was not dealt with within physio as it seems to be the intent in the phrasing of physio

One of the difference though is that motion data as introduced in the motion BEP is a datatype in its own right recorded with nothing along, where as physio files correspond to data recorded along with another datatype.

the "MRI scanner" should be considered a motion tracking device and therefore should be encoded as _motion

Unless I am wrong, if done according to the motion, that would imply moving the motion file to a motion folder and users of the datasets would then have to rely on the scans.tsv to know how to match the motion file with its MRI file counterpart. Isn't that more complex than treat this as a physio file?

[oesteban]

Okay, that makes a lot of sense. I missed that motion/ folder in the structure. IMHO it would make more sense to have used beh/ and _physio, but I can see the difference now.

Okay, I guess this should be more clear in the physio specs (and since I have only skimmed through motion, I cannot say about that side).

Thanks for the clarification @Remi-Gau, very much appreciated!

[oesteban]

I guess I can close this issue since these motion parameters should be encoded as a physio file under the modality that corresponds.