PDT2 anatomical modality: Recommendations and potential use of _echo

[nicholst]

For PD+T2 images created from a single series (two echos), our conversion tool (heudiconv) is encouraging us to use _PDT2 for modality type, creating two NIFTI+json pairs, one for PD and one for T2, but we're struggling to figure out how to give them distinct names.

I don't recall a discussion around the PDT2 anatomy modality label: What was intended? That a 4D (dim4=2) image would be created?

If two 3D images are created, how should they be distinguished? According to the spec, the only feasible options are _acq-<label> and _run-<index>. run doesn't really make sense as it suggests that two PDT2 acquisitions were collected. So might _acq-PD and _acq_T2w be recommended?

What would be unambiguous and perhaps clearer is if _echo-<index> was available as an option. Is there any interest/appetite for adding an optional echo keyword for anatomical scans?

Anyway, the PD+T2 is a very common clinical acquisition and if nothing else it would be good to offer some concrete suggestions in the spec.

[maryammokhberi]

I just want to say we have the same problem in dealing with PDT2 scans, which are converted into two separate files apparently due to having 2 echos. Currently, we are using _acq-PD and _acq-T2 labels for them, but I think _echo-PD and _echo-T2 would have made more sense if was bids-compatible. We have this ambiguity also with T2star scans as they are multi-echo as well.

[Gilles86]

Hi guys,

We are currently working on a BIDS extension that allows for BIDSifying data like this.

See the latest version in this repo: https://github.com/bids-standard/bep001/blob/master/src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md#suffix

I think it suggests to do the following:

 > sub-01_echo-1_MESET2.nii.gz
 > sub-01_echo-1_MESET2.json
 > sub-01_echo-2_MESET2.nii.gz
 > sub-01_echo-2_MESET2.json

sub-01_echo-1_MESET2.json

{
    'EchoTime':0.01,
    ...
}

sub-01_echo-2_MESET2.json

{
    'EchoTime':0.03,
    ...
}

[nicholst]

Thanks @Gilles86! This would work, indeed. However, if there is no aspiration to create parametric maps, I wonder if the PDT2 label is more informative? (Or PDT2w or PDwT2w; see my new issue https://github.com/bids-standard/bep001/issues/52 on PD vs PDw).

While I'm fond of acq-PD and _acq_T2w to disambiguate the two scans, I agree the echo-1 and echo-2 is probably best and most consistent with the aspirations of bep001.

(@maryammokhberi's suggestion is also clear, _echo-PD and _echo-T2 won't fly as echo requires an index and not a label.)

[Gilles86]

Hi @nicholst,

First of all, we decided in our last meeting that the suffix _MESET2 is a bit of a mouthful and not consistent with the suffix _MEGRE for multi-echo gradient-echo images. We thus decided to rename it to _MESE.

Then:

However, if there is no aspiration to create parametric maps, I wonder if the PDT2 label is more informative? (Or PDT2w or PDwT2w; see my new issue bids-standard/bep001#52 on PD vs PDw).

In the BEP-001 we talked quite a bit about this issue. What we largely agreed on is that we have two types of images.

The first and most common type, is the one where the parameters are clearly chosen to create a specific contrast. Examples are the classic T1-weighted gradient-echo and T2-weighted spin-echo acquisitions. Although these images are never "truly" exclusively T1 or T2-weighted, it makes a lot of sense to call them like that and use suffixes like _T1w, _T2w or T2starw. Users of a data set then immmediately know what kind of contrast they can expect and what to use these images for.

However, a second type of images is becoming more common. In such images, we sweep over a set of acquistion parameters, like echo times (MEGRE, MESE) or inversion times (MP2RAGE) or a combination of those (MPM), to be able to quantify underlying physical parameters (T2-values in MEGRE) or increase image quality (e.g., MP2RAGE uses two images to reduce B1 inhomogeneities in a T1-weighted image). In this case, it is important to know for the end users which images are grouped together and what kind of approach has been chosen. Moreover, it is often not unambiguous how the individual volumes of such acquisitions are weighted (e.g., the middle images of a MEGRE have both PD and T2-weighting). Therefore, we chose to include suffixes like _MEGRE, _MESE, MPM and _MP2RAGE to quickly group such acquisitions in a meaningful way.

So for your use case, I would use the _MESET-suffix with two different echo-<echo> key-value pairs in the file name. However, if you think the end users of your dataset have no need to know that these two volumes are part of the same MESET acquisition, or you use pipelines expect a T2w and a PDw-image and do not know about the _MESET-suffix (yet), I think using the weighted-suffixes is fine as well. I do think we should refrain from using _T2 or _PD suffixes for volumes that are merely T2- or PD-weighted. See also the reply in https://github.com/bids-standard/bep001/issues/52.

[nicholst]

Thanks for the detailed comment @Gilles86!

While not so common in the neuro research world, PD+T2 pairs are super common in clinical data. But I agree with you that clearest thing is to represent them with separate PDw and T2w modality labels.

My problem now is that the converter I'm using, heudiconv, is presently built so that any set of images with a common series UID must share a modality label, forcing the use of a common label for both contrasts. I'll take it up with the heudiconv crew.

[yarikoptic]

Dear @Gilles86 , could you please digest following two sentences a bit more for me? To me they read like the 2nd one contradicts the first one (which states that it is Ok to have two separate _PD and _T2w images). Or I am misunderstaning the meaning of -weighted and how it is different from a "separate" _T2w image (?):

However, if you think the end users of your dataset have no need to know that these two volumes are part of the same MESET acquisition, or you use pipelines expect a T2w and a PDw-image and do not know about the _MESET-suffix (yet), I think using the weighted-suffixes is fine as well. I do think we should refrain from using _T2 or _PD suffixes for volumes that are merely T2- or PD-weighted.

[nicholst]

@yarikoptic : Maybe I can clarify. In that last sentence you quote I think @Gilles86 was commenting that _PD will be depicated for _PDw. The new BEP001 uses "map" to denote quantification and "w" the usual weighting; in fact I don't see _T2 in the current spec but _PD is there and lacks consistency with T1w T2w, etc.

[CPernet]

old issue, but still the case, we just converted PDT2 and the validator complained that echo-1_PDT2map.nii, echo-2_PDT2map.nii are not valid @rwblair @sappelhoff

[effigies]

If they're 3D images and not a combined image, why would they not just be PDmap and T2map?

[CPernet]

they are a PDT2map (a weird combo) so a single image, but 2 echos

[effigies]

So it's a single 4D image? I don't understand the use of echo- then, if both echos are in one file.

[CPernet]

We have two 3d anatomical images called PDT2map.nii as per spec (not T2w.nii not PD.nii). Each PDT2map.nii is from a different echo. So we logically apply the echo key, e.g. echo-1_PDT2map.nii

[effigies]

Neither parametric nor non-parametric anatomical images have permitted the echo entity. This is not my area of expertise, but I was under the impression that this was left this way by BEP001 for good reasons.

My understanding is that, in the case of parametric images, these are estimated from a spread of acquisition parameters, so generally there will not be a single echo (or inversion time, or flip angle) applicable to the image as a whole. For non-parametric images, the weightings are equivalent to the selection of acquisition parameters. Adding variable acquisition parameters just wouldn't make sense as the weighting would change.

Still, PDT2 seems to be an odd duck:

Name	suffix	Description
PD and T2 weighted image	PDT2	In arbitrary units (arbitrary). PDw and T2w images acquired using a dual echo FSE sequence through view sharing process (Johnson et al. 1994).
Combined PD/T2 image	PDT2map	In arbitrary units (arbitrary). Combined PD/T2 maps are REQUIRED to use this suffix regardless of the method used to generate them.

My reading is that these are 4D images, not pairs of associated 3D images. If you have 3D images, we already have _PDw, _T2w, _PDmap and _T2map that will describe them.

And if this was a multi-echo sequence intended for the purpose of deriving PDmap and T2map images, then it seems that MESE, which requires the echo entity, would be the appropriate naming convention:

Name	suffix	Description
Multi-echo Spin Echo	MESE	The MESE method involves multiple spin echo images acquired at different echo times and is primarily used for T2 mapping. Please note that this suffix is not intended for the logical grouping of images acquired using an Echo Planar Imaging (EPI) readout.

Again, though, this isn't my area of expertise. If the consensus is that it would be better to carve-out PDT2 so that echo-1_PDT2 and echo-2_PDT2 are a pair of simultaneously acquired PDw and T2w images, we could do that. My impression from reading the above was that this was not the consensus.

[nicholst]

These PDT2 are odd beasts but there are large volumes of historical data out there in this form.

As I see it, the problem is that they come from the same scan (same excitation even) but are used and interpreted separately and not quantitatively, not necessarily as a pair/sequence.

Is this really even a BIDS standard issue and instead a converter issue? What is to stop a converter to produce 2 3D images named

anat/sub-<label>[...]_PDw.nii.gz
anat/sub-<label>[...]_T2w.nii.gz

Wouldn't that be valid BIDS?

[Now edited as per @effigies comment; forgot we don't do _PD and _T2]

[effigies]

Is this really even a BIDS standard issue and instead a converter issue? What is to stop a converter to produce 2 3D images named

anat/sub-<label>[...]_PD.nii.gz
anat/sub-<label>[...]_T2.nii.gz

Wouldn't that be valid BIDS?

PDw and T2w, but yes.

[effigies]

Should we go ahead and just update the text of PDT2 and PDT2map so that these files are expected to be 4D and pairs of 3D volumes should just use the regular suffixes? Something like:

Name	suffix	Description
PD and T2 weighted image	PDT2	In arbitrary units (arbitrary). A two-volume 4D image, where the volumes are, respectively, PDw and T2w images acquired using a dual-echo FSE sequence through view sharing process (Johnson et al. 1994). If separated into 3D volumes, the PDw and T2w suffixes SHOULD be used instead.
Combined PD/T2 image	PDT2map	In arbitrary units (arbitrary). A two-volume 4D image, where the volumes are, respectively, PD and T2 maps. Combined PD/T2 are REQUIRED to use this suffix regardless of the method used to generate them. If separated into 3D volumes, the PDmap and T2map suffixes SHOULD be used instead.

[CPernet]

neither of them, P2T2 are single 3D images, you cannot separate the T2 from the PD, and they often come with 2 echos

[effigies]

Okay. I bow out, and will leave this discussion to those who work with these images.

[nicholst]

@CPernet I don't get your comment (& @effigies please don't totally bow out! Need your thoughts below).

neither of them, P2T2 are single 3D images, you cannot separate the T2 from the PD, and they often come with 2 echos.

specifically 'neither are single 3D images': First of all, from a physics perspective, they're old acquisitions and not 3D but 2D acquisitions, if that's what you're referring to. That's the 'physics' side.

From the data conversion side, it seems that the choice has already been made for 3D over 4D. That is, throughout BIDS it says that multiple echos are to be stored in separate NIFTI files as a file collection through the _echo-<index> entity component of the filename. This is explicitly noted for anatomical multi-echo acquistions MEGRE and MESE (see file collection) and for task fMRI multi-echo data (see Task (including resting state) imaging data: "Multi-echo data MUST be split into one file per echo using the echo- entity.")

So, taking your initial issue carefully @CPernet: It certainly seems that the current status quo is that PDT2 acquisitions will be converted and stored as

*echo-1_PDT2w.nii.gz
*echo-2_PDT2w.nii.gz

What I don't understand is how you got

*echo-1_PDT2map.nii.gz
*echo-2_PDT2map.nii.gz

.... is it possible to obtain quatitative PD and T2 from just two echos? I don't think so.

So! I want to raise two distinct issues:

1. Do we really need both PDT2 and PDT2map? In fact, the spec seems to acknowledge there's no difference: Under non-parametric & parametric you get...

Name	suffix	Description
PD and T2 weighted image	PDT2	In arbitrary units (arbitrary). PDw and T2w images acquired using a dual echo FSE sequence through view sharing process (Johnson et al. 1994).
Combined PD/T2 image	PDT2map	In arbitrary units (arbitrary). Combined PD/T2 maps are REQUIRED to use this suffix regardless of the method used to generate them.

... which shows the PDT2map aren't quantiative and thus I don't see how they're at all different from PDT2. Tagging @agahkarakuzu @sappelhoff @tiborauer @nstikov @Gilles86 or other qMRI BIDS people to hopefully explain this. If you can't make a quantitative map out of a PDT2 acqusition, why is there a PDT2map entity? When are you supposed to use one over the other?

2. What I belive is the original point of this issue, is that since a PDT2 acquisition is not quantiative, buth rather a hack to acquire two useful 'modalties' in a single acquistion, is it possible for the standard to accomodate this pair stored as

   *_PDw.nii.gz
   *_T2w.nii.gz

   The practical challenges to this are proabably in the data conversion, as is indistinguishable from a 2-echo multi-echo sequence, and is actually also technically a MESE anatomical acquisition.

[CPernet]

I'm not even contending what is relevant to what ... just that adding echo did not validate

[effigies]

@nicholst

It certainly seems that the current status quo is that PDT2 acquisitions will be converted and stored as

*echo-1_PDT2w.nii.gz
*echo-2_PDT2w.nii.gz

This is not the status quo. The echo entity is not permitted for parametric or non-parametric anatomical images (which excludes the qMRI inputs used to generate parametric images), and I outlined what I think the reasoning is in https://github.com/bids-standard/bids-specification/issues/223#issuecomment-1450532683. This is why it does not validate, which I believe is Cyril's complaint.

1. Do we really need both PDT2 and PDT2map? [...]

I don't think PDT2map makes sense, but I didn't write it. I would be equally happy for someone who knows what they're talking about to correct me or to propose removing PDT2map from the spec.

2. What I belive is the original point of this issue, is that since a PDT2 acquisition is not quantiative, buth rather a hack to acquire two useful 'modalties' in a single acquistion, is it possible for the standard to accomodate this pair stored as

*_PDw.nii.gz
*_T2w.nii.gz

I believe the standard does accommodate this. A PDw image can have the PDw suffix, however acquired.

The practical challenges to this are proabably in the data conversion, as is indistinguishable from a 2-echo multi-echo sequence, and is actually also technically a MESE anatomical acquisition.

Agreed, however you want to encode these data, some tool will probably need to special-case it.

---

To the extent that I had a point above, it's simply that there are multiple ways to encode these data. One already exists but may be technically difficult to achieve, while the other requires a loosening of the spec to permit non-parametric anatomical images to have a new entity. Either is doable, but a decision needs to be made.

Again, I am neither an expert nor user of these data, so I have no horse in this race. Here are the options, as I see them:

1) Change the spec to permit the echo entity for PDT2 images. This will require an update to the validator, but existing converters can probably handle it with little to no change.

2) Clarify the spec to state that the PDT2 suffix is specifically intended for 4D images where the first volume is PDw and the second volume is T2w, and that 3D images should simply be labeled with PDw or T2w, regardless of whether they were acquired simultaneously. No change is required to the validator, although it could be helpful to add an error if 3D PDT2 images are found. Converters may require more extensive changes to permit them to create two images with different suffixes from a single acquisition.

[agahkarakuzu]

Hi all,

Just to clarify what happened during BEP001 regarding PDT2, the initial plan was to deprecate it as it was ambiguous. But as noted by @nicholst, there appears to be a lot of data with this tag, which is also convenient for heudiconv. Therefore we refrained from deprecating it.

Also to clarify the physics aspect:

Two echoes at 40 and 80ms above are sampled at the center of k-space for PD and T2 contrast, respectively. If these "raw" images (that does not contain edge features) are in question here, then echo-1_PDT2 and echo-2_PDT would constitute a file collection. If these images exist, there may be images from other (3) echoes as well.

If you can't make a quantitative map out of a PDT2 acquisition, why is there a PDT2map entity? When are you supposed to use one over the other?

The view sharing method reconstructs images with high-frequency contributions from other echoes (the ones annotated by both in the above image). In this case there's again two images, but with better edge features, would be represented by echo-1_PDT2map and echo-2_PDT2map.

We knew the suffix "map" here is a misnomer (the name is still Combined PD/T2 image in the table), but left there to imply that these images have contributions from multiple images/samples. Again a compromise made to accommodate the existing PDT2 suffix while distinguishing what is raw vs what is combined moving forward.

Normally when we derive a map, entities such as echo drop from the derivative. But in this case the entity is still needed to differentiate the outputs.

I should also note that during development, it was not clear to us whether existing PDT2 images were combined or the low-res pairs.

This method is older than me, and as @nicholst they are usually acquired in 2D stacks. Therefore, solving the issue based on dimensionality may not be the ideal route.

The decision to refer to these images as PDw and T2w depends on the extent to which we want to acknowledge that they were acquired through the SHARE protocol. From a clinician's perspective, this is important information. For a data processing script, probably not that much.

[nicholst]

Thanks @agahkarakuzu for filling in the physics behind this. I didn't appreciate the complexity of the acquisition, but I can simply attest that the result is a pair of images with high in-plane resolution (as would be expected for their clinical use). In my time I've never seen examples where anything other than 2 images (1 PDw, 1 T2w) are conveyed from the scanner, but they could be out there.

So @agahkarakuzu has made the case for keeping T2PDmap, but we need an old timer physics person to weigh in on whether this means the T2PD should be depricated.

The proximal problem, right now, is that converters and the spec are out of sync. On @effigies's two options, paraphrased

1. Change the spec to permit the echo entity for PDT2 images.
2. Clarify the spec to state that the PDT2 suffix is specifically intended for 4D images where the first volume is PDw and the second volume is T2w, and if split the two 3D images be named PDw and T2w irrespective of their dual-echo provenance.

... first is easier for authors of converter software as that seems to be happening now. However, for the second option, in practice the 4D PDT2 will most certainly need to be immediately split as pipelines using T2 images will expect 3D images, and thus ideally converters would support the splitting option; thus we might want to RECOMMEND that the files are split as part of conversion (making use of the PDT2 suffix rare). However, if I were a converter author it would seem like a bold step to, by default, convert any 2-echo sequence into a PDw and T2w pair... an "--assumePDT2" flag (or something) might be warranted. Or @agahkarakuzu, would you say 2-echo images are rare beasts and likley to be PD-T2 pairs?

I have no skin in the converter game, but I would definatley vote for option 2 with a strong preference for splitting. Would value @neurolabusc & @satra thoughts on this.

[neurolabusc]

@agahkarakuzu can I suggest you provide a respository of DICOM images in this sequence as sourcedata. See examples at osf or github. Concrete examples make this clear.

To be BIDS compliant, dcm2niix is expected to separate each echo from a DICOM series as a separate NIfTI file, so a ME-MPRAGE will have one 3D NIfTI per echo, and a multi-echo fMRI series for tedana will have one 4D NIfTI per echo. Therefore, I think that dcm2niix should parse your sequence into multiple files.

However, dcm2niix does not attempt to set the filename based on your intention. Therefore, you would want to use a dcm2niix wrapper like headiconv, ezBIDS or Dcm2Bids to rectify the PDw or T2w naming. Those tools are developed by large groups, but @yarikoptic, @dlevitas, @arnaudbore seem to be good representatives for their preferences.

Maybe I am missing something, but it is unclear what PDT2map adds relative to the existing generalized T2map. I think of T2 relaxometry as measuring T2 effects by manipulating echo time. Isn't the PDT2map simply a T2map where the short TE is selected to attempt to balance the contribution of T1 and T2 effects?

[agahkarakuzu]

@neurolabusc I don't have an example DICOM dataset for this. During BEP001 we had to go through many issues like this to overhaul ambiguous or incomplete descriptions. Maybe @nicholst can provide an example DICOM dataset.

Isn't the PDT2map simply a T2map where the short TE is selected to attempt to balance the contribution of T1 and T2 effects?

PDT2map (or PDT2img for that matter) is a weighted image, not quantitative unlike a T2map (in seconds) that is obtained by fitting voxel values from multiple echoes to the signal decay equation.

As for @nicholst's question, I agree that PDT2 and PDT2map duality caused by not breaking retrocompatibility is causing issues. Deprecating PDT2, then having something like:

*echo-01_PDT2img.nii.gz
*echo-02_PDT2img.nii.gz

would make both suffix name and the use case clearer.

[tiborauer]

It is interesting to see the similar "data vs use-case" discussions again and again. 😊 BEP01 came up with the idea of collection suffixes collecting heterogeneous acquisitions into single use-case to find a compromise. Following on that, my initial question is whether there is actually a use-case/workflow which would uses PDw and T2w images together, or is it simply a clever acquisition generating both images at once. If there is such a use-case, then we may want to consider coming up with a collection suffix describing the use-case rather than the data. If there is no such use-case, then I would second @nicholst's option 2.

[nicholst]

RE PDT2 vs PDT2map & @agahkarakuzu's reference to Johnson et al. (1994):

After some recollecting and reading I don't think that it is representive of these sequences we're discussing. In particular, I'm pretty sure I saw my first PD-T2 pair in 1992 and it was a work-a-day sequence then, so I doubt it is so complex.

I cannot find a canonical reference... this "dual-echo spin-echo" sequence seems to have been so ubiquetous no one thought to cite it. However this figure from Alharbi et al. (2022) captures my understanding:

and a careful re-reading of MRIquestions's Dual-Echo FSE indicates that Johnson et al. (1994) is an elaboration on the classic, a view sharing extension not the de facto.

So! This provides some clarity and a concrete proposal RE: PDT2 vs PDT2map

• PDT2 is a 2-volume 4D file arising from a dual-echo sequence (exactly 2 echos) producing PDw and T2w images; remove any reference to Johnson et al. (1994) in its description.
• PDT2map are 4D files arising from from 2 or more echos that are processed into images that have PD2 and T2w, giving Johnson et al. (1994) as an example.

PS: Let me appologise for not being able to share any example DICOMs... all my (many) examples are from a priopriatry database from which I can't export data.

[nicholst]

@agahkarakuzu regarding the proposal of

*echo-01_PDT2img.nii.gz
*echo-02_PDT2img.nii.gz

this is the first use I've seen of img as part of a suffix (can't find any reference in the current spec at least). What is PDT2img supposed to convey over PDT2?

Also, I concur with @neurolabusc that the converters can't be all-knowing and that wrappers will have to be used to adjust things according to knowledge that lives outside the DICOM headers.

The sticking point, then, seems to be the current rule that anatomical images are prohibited from having the echo keyword (& what caused @CPernet's validator error in the first place). It would seem that that rule needs to change or we have to convince @neurolabusc that these acqusitions should be converted into 4D NIfTI images.

My vote is for allowing

*echo-1_PDT2.nii.gz
*echo-2_PDT2.nii.gz

to be valid. In practice, though, upon conversion I would immediately rename them to *PDw.nii.gz and *T2w.nii.gz as part of wrapper.

Does anyone know the motivation for prohibiting the echo keyword from anatomical images?

[neurolabusc]

@nicholst the BIDS EchoTime field can be an array of numbers. Therefore, it seems reasonable to stack an anatomical sequence with multiple TEs as a single 4D volume. This would support a sequence with only two echo times (e.g. PD and T2 dominated) as well as a sequence with many echo times that can be used to calculate relaxometry.

However, my instinct is that this concatenation should be done by a wrapper that knows the user's intention. I worry there will be a lot of unintended consequences if we try to embed this logic into dcm2niix. For example, consider a multi-echo T2* fMRI run where a gradient echo series is acquired with reverse phase encoding that has only one volume per echo.

Perhaps dcm2niix could be extended to provide a comprehensive solution to BIDS conversion if users provide reproin intention hints in the protocol name. However, I think that there is logic between a consistent low-level conversion (dcm2niix) versus a high-level wrapper (headiconv, ezBIDS or Dcm2Bids) that makes intention specific modifications.

if there is a consensus on a robust low-level heuristic for making this concatenation decision, I am happy to implement it.

[agahkarakuzu]

this is the first use I've seen of img as part of a suffix (can't find any reference in the current spec at least). What is PDT2img supposed to convey over PDT2?

The intention was to convey that the image is not just a "map" and also not a conventional "weighted" image. Rather, it is an image created through the combination of contrasts, similar to the UNIT1 image in MP2RAGE.

So! This provides some clarity and a concrete proposal RE: PDT2 vs PDT2map

Thank you for clarifying this!

[nicholst]

Regarding my PDT2 vs PDT2map proposal

• PDT2 is a 2-volume 4D file arising from a dual-echo sequence (exactly 2 echos) producing PDw and T2w images; remove any reference to Johnson et al. (1994) in its description.
• PDT2map are 4D files arising from from 2 or more echos that are processed into images that have PD2 and T2w, giving Johnson et al. (1994) as an example.

I sought advice from (old-timer :) MR physicist Peter Jezzard and I wanted to record his advice on how to distiguish between vanilla dual-echo and SHARE & related fast spin-echo methods:

If you have the scan time durations recorded in your data then you can probably work out what they are. If they are dual-echo spin-echo acquisitions then the scan time will be equal to TR times the number of phase encodes (plus or minus any partial Fourier). If they are dual-echo fast-spin-echo acquisitions then the scan time will be considerably shorter (by a factor of probably 4 or so).

He noted that the slow dual-echo method gave more reproducible T2 measures but clinicians didn't notice and were happy with PD and T2-ish images.

But, honestly, this all seems like a very fine distinction and often people won't know which they have in their hands, so not sure if we're over-baking things with having both PDT2 and PDT2map.

[tiborauer]

If we consider only the PDT2(w) and PDT2map, then we need both because the former is weighted only, while the latter is (quantitative) parameter map typically derived from PDT2(w).

[nicholst]

If we consider only the PDT2(w) and PDT2map, then we need both because the former is weighted only, while the latter is (quantitative) parameter map typically derived from PDT2(w).

But it isn't clear that there is such a thing as a quantitative pair of parameters maps for PD and T2w. (Even current standard acknowledges that PDT2map isn't quantiative).

[tiborauer]

PDT2map isn't quantiative

I think this is an inconsistency which should be rectified.

[CPernet]

@neurolabusc the student is scanning this week (I think) and I asked to do a phantom with our pd+t2 sequence, will upload the dicom for you

[CPernet]

This all seems like a very fine distinction and often people won't know which they have in their hands, so not sure if we're over-baking things with having both PDT2 and PDT2map. -- I think we do.

1. PDT2 is not quantitative so using *map is confusing so I vote for removing PDT2map.
2. Separating PD from T2 is an option and wrappers can do that, let dcm2niix spit out echo1- echo2-, simply rename *T2.nii.gz and *PD.nii.gz
3. I would still like to have the option to let users know what the data are so *echo-1_PDT2.nii.gz and *echo-2_PDT2.nii.gz. I prefer that 2nd option because I would typically also have another T2 image.

This leads to 2 alternative ways to encode those images, I personally don't see this as a problem - but others might point out that it is for n reasons I cannot see right now.

thx @agahkarakuzu @nicholst for the physics behind those -- PS: our sequence uses a tse acquisition with e1=0.011 and e2=0.092 (and yes it's a stack of high-res, in-plane acquisition (not whole brain), the clinicians love to check brain stem stuff for instance)

[tiborauer]

I like options 1 and 2, as suggested before, but I vote against option 3. *echo-1_PDT2.nii.gz and *echo-2_PDT2.nii.gz can be ambiguous because an average user may not be able to figure out the correspondence (i.e., which TE belongs to which weighting) unless explicitly stated (as in option 2).

[neurolabusc]

@CPernet when the BIDS steering committee meets with the DICOM executive committee, perhaps you could propose promoting Echo Number from Optional (Type 3) to required on condition of sequence being multi-echo (Type 1C). Perhaps this could be specific for enhanced DICOM. Without this, any tool that wants to interpret, convert or display multi-echo images needs to add kludges. This issue is particularly complicated for enhanced DICOMs from Philips where the images are not stored in any particular order (perhaps reflecting completion from a parallel reconstruction pipeline), the fact that Instance Number (0020,0013) does not need to be sequential or even unique.

[CPernet]

if option 3 is discarded -- @tiborauer how do you suggest indicating this T2 is coming from a combined PD-T2 share scheme? given another T2w image already in the same directory? because this is how this goes 90% of the time

[tiborauer]

Do the two T2w images usually have the same geometry (resolution, alignment, slicing)? We can use the acq field to indicate either their different geometry or their different origins.

[CPernet]

@neurolabusc I have shared a folder with you with DICOM from a phantom -- also here https://drive.google.com/drive/folders/1_D9yR48RjF7oJrWWOx3dxcYbdfYf0WzG?usp=sharing

[CPernet]

@tiborauer @nicholst ok so we usually have a full brain T2, add the PDT2 which are more restricted in space but anyway a valid BIDS folder can look like

• sub-xxx_T2w.nii.gz (whatever acquisition doesn't matter, one can add it if wanted)
• sub-xxx_acq-sharePDT2_PDw.nii.gz
• sub-xxx_acq-sharePDT2_T2w.nii.gz

that way we drop *PDT2map.nii.gz and drop the *echo-*.nii.gz
last, do we need to keep *PDT2.nii.gz in the spec? for backward compatibility, i guess we should, but in this case, it must be the 4D image and the json must have the two echo times

[tiborauer]

I think it looks like a concise solution to me. I would probably use acq-partial (or whatever is the most important feature from the user's POV) and mention the sequence or protocol name in the JSON (if required).

[neurolabusc]

@CPernet your data is now available as dcm_qa_pdt2 providing a validation dataset for how dcm2niix will convert this. The current dcm2niix behavior is to save each echo as a separate file, so two NIfTI images are genrated ("EchoTime" of 0.092, 0.011). Either dcm2niix wrappers would concatenate these, or we have to develop a consensus for how dcm2niix determines when to concatenate echoes and when it does not (and implementing this change may require changes for all the wrappers that depend on dcm2niix).

The experts in this topic who follow this post may also want to examine the JSON files that dcm2niix generates to ensure that it has captured all the relevant sequence details stored in the source DICOM.

[effigies]

Updating my earlier proposal to match what I understand from @CPernet's most recent comment, we could remove PDT2map and update PDT2 to say (new text in bold):

Name	suffix	Description
PD and T2 weighted image	PDT2	In arbitrary units (arbitrary). A two-volume 4D image, where the volumes are, respectively, PDw and T2w images acquired using a dual-echo FSE sequence through view sharing process (Johnson et al. 1994). If separated into 3D volumes, the PDw and T2w suffixes SHOULD be used instead, and an acquisition entity MAY be used to indicate the origin of the images, for example, acq-PDT2_PDw.nii.gz and acq-PDT2_T2w.nii.gz.

I would interpret this SHOULD as indicating that a 3D PDT2 volume would raise a warning, not an error. Currently the validator will accept either 3D or 4D without complaint, so making 3D an error is potentially breaking.

I found no datasets on OpenNeuro with PDT2 images to test whether 3D or 4D images exist in the wild.

[CPernet]

looks good to me @effigies

[effigies]

Okay. With at least provisional agreement, I've made a concrete PR here: https://github.com/bids-standard/bids-specification/pull/1448.

[nicholst]

Hi @effigies, this update is good and consistent with the current example that Cyril just generated, but is unnecessarily incompatible with older data that may not use a view sharing / Turbo Spin Echo sequence. I would propose to simply make it:

Name	suffix	Description
PD and T2 weighted image	PDT2	In arbitrary units (arbitrary). A two-volume 4D image, where the volumes are, respectively, PDw and T2w images acquired. If separated into 3D volumes, the PDw and T2w suffixes SHOULD be used instead, and an acquisition entity MAY be used to indicate the origin of the images, for example, acq-PDT2_PDw.nii.gz and acq-PDT2_T2w.nii.gz.

[yarikoptic]

@CPernet when the BIDS steering committee meets with the DICOM executive committee, perhaps you could propose promoting Echo Number from Optional (Type 3) to required on condition of sequence being multi-echo (Type 1C). Perhaps this could be specific for enhanced DICOM. Without this, any tool that wants to interpret, convert or display multi-echo images needs to add kludges.

Thank you @neurolabusc ! Just to make clear, the "kludge" here is the necessity to "get the sorted list of all echo times present and get the index for a specific echo within that list of sorted values", or there is more ad-hoc to it (e.g. echo values aren't matching exact etc)? I am just trying to see first pros/cons on why DICOM folks might have tried to avoid having it mandatory (e.g. "data duplication").

[neurolabusc]

@yarikoptic echo number is an explicit integer string, while echo time is a floating point Decimal String (DS), and Effective Echo Time is a float double. With floats, one needs to have a tolerance to decide if variability is meaningful or not. Often, DICOM stores the acquired data, and these can show slight variance due to rounding error or hardware capabilities at different spatial locations.