Legacy table for anatomical MRI data

[Gilles86]

Fixes issue #55 and issue #54.

Note that this PR is being incorporated into #59 and so will close when that PR is merged and the justifications are included in the Proposed Changes in Specification document.

[Gilles86]

So this would be what we call a "grouping"-suffix: so it could be sub-01_echo-1_PDT2.nii.gz for the PD-weighted one and sub-01_echo-2_PDT2.nii.gz for the T2-weighted one. What do you think?

On Fri, Aug 16, 2019 at 4:21 PM Thomas Nichols notifications@github.com wrote:

@nicholst commented on this pull request.

In ProposedChangesToSpecification.md https://github.com/bids-standard/bep001/pull/58#discussion_r314741416:

+## Legacy suffixes for anatomical data +### Proposed Change +Moves some suffixes for anatomical data to a new table called "LEGACY suffixes". These suffixes are still valid BIDS format, +but we reccomend not to use them anymore. They are ambiguous and/or inconsistent. + +### Justification +The following suffixes are moved to the legacy table:

• • _T2star: what is meant is T2*-weighted data. To be consistent with the suffixes T1w, T2w and PDw, we want +to use the suffix _T2starw for this.
• • _FLAIR: This is a sequence name rather than a contrast or a way of grouping quantitative maps. We prefer to use +_T2w, _PDw, or _MESE depending on the use case.
• • _FLASH: This is a sequence name rather than a contrast or a way of grouping quantitative maps. We prefer to use +_T2starw, _PDw, or _GREME depending on the use case.
• • _PD: what is meant is PD*-weighted data. To be consistent with the suffixes T1w, T2w and T2starw, we want +to use the suffix _PDw for this.
• • _PDT2: We recommend to use PDT2map for this.

@agahkarakuzu https://github.com/agahkarakuzu, @Gilles86 https://github.com/Gilles86 and I are just reviewing this pull request and wondering about whether this scan is one file (maybe with two volumes in it - in the 4th dimension) or two files? Or are the two echos combined in someway to one 3D file?

IMHO, the PDT2 suffix only makes sense for a 2-volume image... if the images are separated out, then one would be _PD and the other _T2. However, heudiconv presently uses it with 3D images too: dcm2nii creates 2 3D images, but heudiconv uses a logic that requires images sharing a DICOM Series UID to share a BIDS base and image type; so since both the PD and T2 arise from the same series, they get the same base and then must be distinguished with (e.g.) echo-1 and echo-2.

Does this help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bids-standard/bep001/pull/58?email_source=notifications&email_token=AAIPRTWKYGSTOY3MG4BN6KTQE2ZWTA5CNFSM4HQM6RIKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCBZRN2A#discussion_r314741416, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIPRTW7UIGQZ7OUG5FUM33QE2ZWTANCNFSM4HQM6RIA .

-- Gilles de Hollander Postdoctoral Researcher University of Zurich Department of Economics website http://www.gillesdehollander.nl/ | github https://github.com/Gilles86/

[nicholst]

So this would be what we call a "grouping"-suffix: so it could be sub-01_echo-1_PDT2.nii.gz for the PD-weighted one and sub-01_echo-2_PDT2.nii.gz for the T2-weighted one. What do you think?

Yup! This is what I was thinking.

Of course, if it is a 4D file of length 2 that it is assumed PD is the first volume and and T2 is the second, both in sub-01_PDT2.nii.gz.

[Gilles86]

Of course, if it is a 4D file of length 2 that it is assumed PD is the first volume and and T2 is the second, both in sub-01_PDT2.nii.gz.

To remain consistent, keep things overseeable for developers and users, and don't have json key-value pairs that can either be lists or scalars, we for opted to never have 4D-images in anatomical data... It can be a bit more work when preparing data sets, but it keeps things a lot less messy along the line. What do you think, Thomas?

On Fri, Aug 16, 2019 at 4:57 PM Thomas Nichols notifications@github.com wrote:

So this would be what we call a "grouping"-suffix: so it could be sub-01_echo-1_PDT2.nii.gz for the PD-weighted one and sub-01_echo-2_PDT2.nii.gz for the T2-weighted one. What do you think?

Yup! This is what I was thinking.

Of course, if it is a 4D file of length 2 that it is assumed PD is the first volume and and T2 is the second, both in sub-01_PDT2.nii.gz.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bids-standard/bep001/pull/58?email_source=notifications&email_token=AAIPRTWMFX6RHCCENCPOLE3QE2535A5CNFSM4HQM6RIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4O26LA#issuecomment-522039084, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIPRTQBGS33HU7PXCTNXBDQE2535ANCNFSM4HQM6RIA .

-- Gilles de Hollander Postdoctoral Researcher University of Zurich Department of Economics website http://www.gillesdehollander.nl/ | github https://github.com/Gilles86/

[nicholst]

Ruling out 4D structural data sounds fine to me! FWIW, I haven't seen dcm2niix/heudiconv ever create 4D PDT2 files.

[Gilles86]

Cool. Thanks for the feedback!

On Fri, 16 Aug 2019, 22:42 Thomas Nichols, notifications@github.com wrote:

Ruling out 4D structural data sounds fine to me! FWIW, I haven't seen dcm2niix/heudiconv ever create 4D PDT2 files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bids-standard/bep001/pull/58?email_source=notifications&email_token=AAIPRTTZYAWHFY47K2J2QNLQE4GL7A5CNFSM4HQM6RIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PU2EY#issuecomment-522145043, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIPRTQOTCRM2NLMAEAAM3DQE4GL7ANCNFSM4HQM6RIA .