Add support for multi-echo T1w scans

[JohannesWiesner]

BIDS currently does not seem to support multi-echo anatomical T1w scans such as:

sub-A00000909_ses-20110101_acq-mprage_run-01_echo-01_T1w.json
sub-A00000909_ses-20110101_acq-mprage_run-01_echo-01_T1w.nii.gz

It would be nice if this could be added in the future. See this post on neurostars.org, where this issue has already been discussed more detailed.

[effigies]

Is this part of BEP001?

[tsalo]

No, BEP001 doesn't include multi-echo T1w scans, so I recommended opening an independent issue in the specification repo.

[effigies]

Are we generally comfortable adding echo- for any structural scan? Does it make sense for a subset?

[tsalo]

I don't want to definitively say "yes", but I do think it would make sense for most, if not all, structural scans. Maybe we should pull in someone from BEP001 on it?

[tsalo]

@agahkarakuzu @Gilles86 do either of you see a problem with supporting echo in the current anat modalities? Specifically, this means T1w, T2w, T1rho, T1map, T2map, T2star, FLAIR, FLASH, PD, PDmap, PDT2, inplaneT1, inplaneT2, and angio.

After thinking about it a bit more, I think it may not make sense to support echo for the quantitative maps we already support (i.e., T1map, T2map, and PDmap), since those are derivatives that would generally combine across echoes. My intuition is that the others (especially T1w and T2w) should be fine. Perhaps I'm not understanding correctly though.

[agahkarakuzu]

@tsalo I see a problem in using echo with modalities specifically named to convey weighting information (T1w or T2starw), as what they denote ceases to hold true before/after some echoes. If a suffix is to imply a certain weighting, what it conveys should not be subjected to change by an entity allowed for it.

As for quantitative maps, as you noted, I don't think echo is needed. It acts as a building block rather than an output flavor.

[effigies]

I don't see MEMPRAGE directly addressed in BEP001. Is there a currently expected way that it would be represented? Since it's such a common sequence, I think it would make sense to address it as an example, even if it's an example of a broader class of acquisitions.

[agahkarakuzu]

@effigies there is ‘MEGRE’ for multi-echo gradient-echo acquisitions, which applies to MEMPRAGE. The only nuance is that MEMPRAGE has an inversion preparation block, which can be easily inferred from metadata.

I can add it as an example under MEGRE. What do you think? Or if there is a need for a clearer distinction, we can add MPMEGRE as a suffix to account for such acquisitions without sticking with a vendor-specific sequence name.

[effigies]

This is not my forte, so I don't want to weigh in on whether MPMEGRE is needed, but I think an example under MEGRE would be great, and @JohannesWiesner can see whether it handles his case.

[JohannesWiesner]

This is not my forte, so I don't want to weigh in on whether MPMEGRE is needed, but I think an example under MEGRE would be great, and @JohannesWiesner can see whether it handles his case.

just in case this tag was a request for me to respond: I am lacking technical knowledge here so I am afraid that I cannot make a meaningful contribution to the discussion.

[agahkarakuzu]

In that case, I would suggest going with MEGRE as it already worked on an MP can be inferred from (0018, 0021) Sequence Variant field. We can make notes about the importance of this field for type MEGRE.

[poldrack]

Just bumping this, as I have some T2w and PDT2 data with multiple echoes. To address @agahkarakuzu's point, you are certainly right that there will be some echoes where the weighting will not longer make sense, but won't it also be the case that there is a range of TEs that can give rise to any particular weighting? seems like we need to be able to capture those...

[agahkarakuzu]

@poldrack it is plausible to label chunks of a multi echo data using weighting tags along with the echo entity, assuming that there's no other multi-echo acquisition in the same dataset to complicate things. However, weighting suffixes for sub-parts of a larger logical group makes it difficult to pick up those files for parameter estimation, or for applications that need the whole set.

To ease inference on weighting, we suggested that the TEs are sorted in increasing order. So an app needing relatively more PDw can work with earlier echoes from a MESE dataset. We made sure that the file collection suffixes are informative that way (MEGRE/MESE/VFA etc.) But tagging (suffix) first echoes as PDw and later ones as T2w for the same dataset would make it less convenient for T2 fitting. That's why we avoided that convention for file collections.

[pwighton]

Has there been any more progress on coming to a consensus on how to BIDSify muti-echo T1w data? Specifically multi-echo MPRAGE data (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2408694/)?

I can see above in this thread that @agahkarakuzu suggests using MEGRE and then using (0018, 0021) Sequence Variant to infer that it's MPRAGE.

Some other suggestions:

• @mnoergaard suggests using MP2RAGE but only include one inversion.
• @bendhouseart put me in touch with @ericearl who suggests simply using T1w and including a .bidsignore file so validation tests don't fail.

A related question is how to best BIDSify the RMS average image. This usually comes off the scanner as a DICOM, which would imply its 'raw' data, however it can be recomputed from the echo images, so would it be better to put this under derivatives?

Does anyone know of any reference BIDS datasets with multi-echo MPRAGE data? I'd be happy to work on one if not.

[agahkarakuzu]

I can see above in this thread that @agahkarakuzu suggests using MEGRE and then using (0018, 0021) Sequence Variant to infer that it's MPRAGE.

Having InversionTime would also hint, but IIRC, the main concern here was to infer directly from file name that it is inversion prepared multi-echo gradient echo. Am I correct?

If that's the case, a new file collection, something like IPMEGRE with echo entity can be useful to accommodate a popular use case. Ofc, this requires a small PR to the extension.

I think I need to elaborate a bit on why not MEMPRAGE or MEMPR:

For these initial file collections, the suffix names were kept generic. This helped us avoid using vendor-exclusive naming conventions. For example, MEGRE makes it clear that the sequence is multi-echo gradient echo. Different sequence names from different vendors can fall under the same file collection.

On the other hand, MEGRE does not not specify what kind of readout was used. For example, references 1-2 in the article @pwighton shared shows possible different readouts for the MPRAGE sequence. If that difference would define a particular/popular application, then a new suffix would be needed.
This is also why EPI readouts are excluded from using MEGRE suffix. Their use cases are clearly described elsewhere in the specification.

Similarly, we did not add magnetization prepared variants of the MEGRE, unless there is a clear & widely used application, such as MPM. Using MPM as a suffix was not a problem as the method name is vendor-agnostic. Similar story with MP2RAGE.

As we need to find the sweet spot where the suffix name is generic enough to be vendor-inclusive and specific enough to identify the particular (or a popular) use case, I suggested IPMEGRE, not MEMPRAGE or MEMPR as these are not vendor-inclusive.

TLDR; we start from generic and create more specific file collection suffixes as the need arises.

P.S. If IPMEGRE is to become a new file collection, then the description of MEGRE must exclude the use of MEGRE for inversion-prepared acquisitions.

@mnoergaard suggests using MP2RAGE but only include one inversion.

The MP2RAGE file collection is reserved to group together images acquired by the MP2RAGE sequence. In addition, multiple readout blocks within the same TR (MP2RAGE) followed by one inversion pulse do not give the identical images with multiple runs of its sub-sequence (MPRAGE), even if the parameters were matched. For these reasons, I am against using another sequence name to create a logical grouping of images acquired using a different sequence.

A related question is how to best BIDSify the RMS average image.

There's this class of derivatives coming from a file collection, but they are not parametric images. Plus they can be generated offline, but vendor also outputs them. For example UNIT1 from MP2RAGE. The UNIT1 suffix is listed under the Currently supported non-parametric structural MR images table.

The UNIT1 from the scanner is allowed to be stored under raw/anat, but if calculated offline, it goes to derivatives/anat.

A similar approach can be adapted for the RMS image, probably with a more descriptive suffix name. Also, its description should mention the file collections from which an RMS image can be generated.

[pwighton]

Thanks @agahkarakuzu! That was super informative.

Having InversionTime would also hint, but IIRC, the main concern here was to infer directly from file name that it is inversion prepared multi-echo gradient echo. Am I correct?

Yes, this seems to be a common cause for concern.

P.S. If IPMEGRE is to become a new file collection, then the description of MEGRE must exclude the use of MEGRE for inversion-prepared acquisitions.

This is the biggest concern for me in creating IPMEGRE file collection -- we might be fragmenting or invalidating an established workflow. Personally, this concerns me more than the fact that we can't distinguish if the sequence is inversion prepared from the filenames. Maybe it's not a big issue. I'll try to find out.

Anyhoo, you've given me a lot to think about and digest. I'll discuss it with some colleagues and solicit their thoughts.

[yarikoptic]

isn't this a duplicate of #223 which got some discussion going on recently?

[neurolabusc]

@yarikoptic I agree that #223 is related, but that was for spin-echo sequences. In both the gradient-echo ME-MPRAGE and ME-SE the bids-validator refuses to allow the _echo suffix. For the spin-echo sequences, the expectation is that the short echo time gets a PDw suffix (though balanced proton density requires longer TR than practical) while the longer echo time gets the T2w.

Specifically, bids-validator rules do not allow echo for T1w, PDw, or T2w images. For concrete examples of ME-MPRAGE DICOMs one can download the HCP images from ADNI. The validator refuses the filenames:

sub-1_ses-1_acq-tflme3s3_echo-1_T1w.json
sub-1_ses-1_acq-tflme3s3_echo-2_T1w.json
sub-1_ses-1_acq-tflme3s3_echo-3_T1w.json
sub-1_ses-1_acq-tflme3s3_echo-4_T1w.json

[neurolabusc]

I recognize that ADNI data requires registration, which makes it harder for others to replicate and reproduce this issue. In 2018 I acquired a ME-MPRAGE sequence where I share the DICOMs for dcm2niix validation

[neurolabusc]

Related to heudiconv output described in 2019 that fails the modern bids-validator.

[yarikoptic]

Well, let's see if a simple #1570 would go through.

[effigies]

I've reread and am trying to integrate the state of the discussion after @agahkarakuzu and @pwighton's latest exchange. I believe the recommendation for @neurolabusc's example would be:

sub-1_ses-1_acq-tflme3s3_echo-1_MEGRE.json
sub-1_ses-1_acq-tflme3s3_echo-2_MEGRE.json
sub-1_ses-1_acq-tflme3s3_echo-3_MEGRE.json
sub-1_ses-1_acq-tflme3s3_echo-4_MEGRE.json

If the goal is to make it clear that it was MEMPRAGE, that could be specified in the acq- assuming that there aren't two different MEGRE sequences that need to be distinguished with acq-.

I have never worked with MEMPRAGE, so I don't really know what the scope of valid things to do with these data is. I can tell you that if we saw _echo-*_T1w.nii.gz in fMRIPrep, we would align and average the files. If additional preprocessing is needed before it is appropriate to pass there, I think that would be one argument for not using the T1w suffix.

[yarikoptic]

IMHO a standard should not introduce limits on how data must be scanned. If it is possible to scan T1w with various varying echo times (which is if I got it right -- possible), and use cases came up, I think BIDS should support it: it should not require users to abuse some other entity (e.g. _acq-echo1, _acq-echo2) or to add to .bidsignore to just overcome limitation of BIDS to become BIDS-valid. Concerns of "downstream processing tools" are indeed interesting, but IMHO again should not scope what the standard should allow for or not. FWIW I already see a dataset in openneuro with files like ./ds001619/sub-M80371898/anat/sub-M80371898_ce-echo4_T1w.json (abused _ce?), and ./ds003798/sub-CC0006/ses-core2p2/anat/sub-CC0006_ses-core2p2_acq-combecho_run-02_T1w.nii.gz (combined from multiple echos for fmriprep?).

[effigies]

That's a fair argument. I believe the alternative view expressed above could be summarized as "There should be one, and preferably only one, way to do things."

However, if we are agreed that echo-*_MEGRE is not always an appropriate way to categorize the set of things people might want to call echo-*_T1w (and so what we need is just better documentation and guidance), then I think echo-*_T1w is reasonable.

[neurolabusc]

I have just created dcm_qa_mprage that provides sample Siemens 3T Prisma VE11 images for MPRAGE, MP2RAGE and MEMPRAGE. I acquired two series of MEMPRAGE, one only saving the RMS and the other saving each image individually. All the echos of a MEMPRAGE are heavily T1w-weighted, for most applications the averaged root mean squared (RMS) is terrific, providing good signal to noise. In theory, the different echoes can help distinguish the meninges from the gray matter. When acquiring the sequence, you can choose to store only the single echoes, only the RMS or both. In my validation dataset I acquired one series where only the single echoes were saved and one where only the RMS was saved, providing a concrete example of how we often see the images in the real world.

This is outside my domain of expertise, but I also feel echo-*_T1w is reasonable.