Legacy table for anatomical MRI data #58
Conversation
| * **`_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. |
There was a problem hiding this comment.
| `_T2starw`, `_PDw`, or `_GREME` depending on the use case. | |
| `_T2starw`, `_PDw`, or `_MEGRE` depending on the use case. |
There was a problem hiding this comment.
It would be really good to get some highly-clinically oriented people to comment on this. For white matter lesions (whether vanilla white matter hyperintensities or multiple sclerosis lesions) particular, FLAIR is so ubiquitous that it’s important to spell out exactly what is recommended (and that there is buy-in from the community that uses these scans).
In particular, I have never heard of a PD-weighted FLAIR image. A concrete replacement for _FLAIR as typically encountered should be offered. I think this is something like:
For a typical FLAIR with T2-weighting but suppression of the CSF,
we recommend `acq-FLAIR_T2w`.
Conversely, I’ve never heard of FLASH being used for T2 weighting, no less T2star... AFAIK, in its usual instantiation, it’s used for T1-weighted imaging. However, here, unlike FLAIR, FLASH just speeds things up and doesn’t change the contrast, so maybe it’s not so important to convey this. (Not 100% confident on this).
Can I perhaps make a radical suggestion: As I understand it, the proposal to remove FLAIR and FLASH are not specific to the remit of BEP001, right? They are rather part of a general revision/cleaning of the BIDS standard. UNLESS these changes are key to the multi-echo use case, can I propose that you create a separate PR, distinct from BEP001, that can get a fuller airing in the BIDS community, on the future of sequenced-named modality labels? BIDS was not crafted 20 years ago, but just a few years ago, and a wide community of people thought that, despite the slight inconsistency, there was merit in using these particular labels.
@KirstieJane, @Gilles86, @Remi-Gau, @franklin-feingold... what do you think?
There was a problem hiding this comment.
I am concerned (not opposed) to dropping support of FLAIR and FLASH support in modalities supported. I find these sequences are prevalent (as you mentioned especially in the clinical world). I feel raising a larger community discussion may be best to hear more opinions on this. I do not believe this could uptaken until BIDS 2.0 (due to backward compatibility) anyways, but I think great to hear from more of the community on this.
There was a problem hiding this comment.
@Gilles86, @agahkarakuzu and I are just chatting about this now - sorry to have dropped the thread for so long.
@nicholst - you've made a strong case for keeping FLAIR in the list of common scan acquisitions. We might tag you in the future for help adding a description to make it clear that we recommend using FLAIR only when the scan is T2-weighted with suppression of the CSF.
We'd like to still move FLASH to the legacy table because there are so many different flavours of this acquisition that it is impossible to confidently combine them across datasets. ie if data set 1 has a FLASH scan, there's little chance that it will look the same - have the same contrast - as the FLASH scan in data set 2.
So proposal: keep FLAIR in a prominant position, move FLASH, correct the labels that should have had ws after them going forwards (and put the non-w-d labels in the legacy table with the same meaning).
| `_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. |
There was a problem hiding this comment.
@nicholst - we're not super clear on what the PDT2 scan is and so we're not super sure about how to classify it! Can you help us? (References fine too!)
There was a problem hiding this comment.
PD T2 “dual echo” is just something that I’ve always seen with clinical scans. I found this reference: Fast Spin Echo Dual Echo, writing
For the first 20 years of clinical MRI, double-echo sequences were part of standard protocols for nearly all body parts. Short and long echo times (TE) were used to generate proton-density and T2-weighted images in a single acquisition using a long repetition time (TR). Over the last decade T2-FLAIR has largely replaced proton-density sequences for neuroimaging, but they are still used in musculoskeletal and other body applications.
While it may seem like an anachronism this dual echo pair is very common in existing clinical datasets, especially for clinical trials where the protocol was specified long ago.
There was a problem hiding this comment.
Hi @nicholst!! Thank you so much for commenting here - I'm so sorry that we've dropped this thread for so long.
@agahkarakuzu, @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?
Thank you!
There was a problem hiding this comment.
@agahkarakuzu, @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?
| to use the suffix `_PDw` for this. | ||
| * **`_PDT2`**: We recommend to use `PDT2map` for this. | ||
| * **`_inplaneT1`**: this is not a proper MRI contrast or grouping variable. The fact that the data is acquired with the | ||
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, |
There was a problem hiding this comment.
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, | |
| same prescription as the functional data is already decsribed in the orientation matrix. |
| * **`_PDT2`**: We recommend to use `PDT2map` for this. | ||
| * **`_inplaneT1`**: this is not a proper MRI contrast or grouping variable. The fact that the data is acquired with the | ||
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, | ||
| it could be communicated via the `acq-`-tag. |
There was a problem hiding this comment.
| it could be communicated via the `acq-`-tag. | |
| We recommend that this information is communicated via the `acq-`-tag. |
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, | ||
| it could be communicated via the `acq-`-tag. | ||
| * **`_inplaneT2`**: this is not a proper MRI contrast or grouping variable. The fact that the data is acquired with the | ||
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, |
There was a problem hiding this comment.
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, | |
| same prescription as the functional data is already decsribed in the orientation matrix. |
| it could be communicated via the `acq-`-tag. | ||
| * **`_inplaneT2`**: this is not a proper MRI contrast or grouping variable. The fact that the data is acquired with the | ||
| same prescription as the functional data is already decsribed in the orientation matrix. Furthermore, | ||
| it could be communicated via the `acq-`-tag. |
There was a problem hiding this comment.
| it could be communicated via the `acq-`-tag. | |
| We recommend that this information is communicated via the `acq-`-tag. |
|
|
||
| ##### LEGACY suffixes (to be deprecated) | ||
| Some suffixes were defined in the original BIDS 1.0.0 - 1.2.0 specification, but it is | ||
| recommended not to use them any more, because they are inconsistent and/or ambiguous. |
There was a problem hiding this comment.
| recommended not to use them any more, because they are inconsistent and/or ambiguous. | |
| RECOMMENDED not to use them any more, because they are inconsistent and/or ambiguous. |
| They will most likely be deprecated in later main versions of BIDS. | ||
|
|
||
| However, they are still part of the BIDS 1.x specification for legacy reasons. | ||
| Thus, the following suffixes are VALID, but NOT RECOMENDED: |
There was a problem hiding this comment.
| Thus, the following suffixes are VALID, but NOT RECOMENDED: | |
| Thus, the following suffixes are valid, but SHOULD NOT be used for future BIDS datasets: |
| | Combined PD/T2 map | PDT2map | (M) --> In arbitrary units (a.u.). Combined PD/T2 maps are REQUIRED to use this suffix irrespective of the method they are related to. | | | ||
| | T1 Rho map | T1rho | Quantitative T1rho brain imaging<br>[http://www.ncbi.nlm.nih.gov/pubmed/24474423](http://www.ncbi.nlm.nih.gov/pubmed/24474423) <br> [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4346383/](http://www.ncbi.nlm.nih.gov/pubmed/24474423) | | ||
|
|
||
| ##### LEGACY suffixes (to be deprecated) |
There was a problem hiding this comment.
| ##### LEGACY suffixes (to be deprecated) | |
| ##### Legacy suffixes (to be deprecated) |
|
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 ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In ProposedChangesToSpecification.md
<#58 (comment)>:
> +## 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
<#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/>
|
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 |
|
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 ***@***.***> 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
<#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/>
|
|
Ruling out 4D structural data sounds fine to me! FWIW, I haven't seen |
|
Cool. Thanks for the feedback!
…On Fri, 16 Aug 2019, 22:42 Thomas Nichols, ***@***.***> 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
<#58?email_source=notifications&email_token=AAIPRTTZYAWHFY47K2J2QNLQE4GL7A5CNFSM4HQM6RIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PU2EY#issuecomment-522145043>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIPRTQOTCRM2NLMAEAAM3DQE4GL7ANCNFSM4HQM6RIA>
.
|
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.