[DWI] How to encode ADC/TRACE volumes?

[effigies]

Your idea

Scanners are increasingly generating ADC/TRACE volumes, and BIDS now considers scanner-generated derivatives to be raw enough to not contort ourselves into moving portions of the output into a derivatives/ subdirectory.

These volumes right now are best considered DWI volumes, with no applicable bval/bvecs, but at least the validator expects DWI to be 4D and have bval/bvec sidecars.

I would like to push the issue and just have a vote. Here are our options (use the emoji responses to indicate your vote):

• :tada: Carve out acq-ADC_dwi.nii[.gz] and acq-TRACE_dwi.nii[.gz] as special DWI images that can be 3D and not require bval/bvec. (Vote for this if you would prefer an entity, even if not acq.)
• :rocket: Create TRACE and ADC suffixes that go in the dwi/ datatype directory to refer to single-volume images with no bval/bvec requirements.
• :+1: Either is fine, but please just fix this.
• :-1: Leave things as is.

Rules of engagement

In the interest of keeping this discussion short, I would ask commenters to not address one another, but to limit themselves to a single post that argues for or against one or more of these options. If all you want to do is show support for one option, do it by voting.

References

• https://github.com/bids-standard/bids-validator/issues/1858
• https://neurostars.org/t/multiple-lesion-masks-for-bids/27184

[CPernet]

since those scanner derivatives are exported in some other cases than DWI, it makes sense +1

[tiborauer]

Arguing against the first option, acq typically refers to particular sets of acquisition parameters with the resulting image conceptually compatible (with the original without any acq field). Personally, I would leave things as is because I find it more transparent to estimate them based on the raw 4D DWI data, but I can also appreciate cases when they can be useful. At least, we can test more and more whether the two approaches (scanner vs. derivated) are indeed equivalent.

[smeisler]

For the first option, wouldn't the rec-<> label be more appropriate?

[mattcieslak]

I voted for new suffixes, but I also think BEP016 is relevant and would be happy with mdp and dwimap here

[arokem]

I voted for new suffixes, but I also think BEP016 is relevant and would be happy with mdp and dwimap here

Slightly off the main topic, but I wonder whether dwimap and similar should be reserved for derivatives of pipelines, and generally disallowed in raw data. I think this is a great case for this actually, where the purpose of the new suffixes is to indicate that this was generated by the scanner, and not attributable to a pipeline.

[effigies]

@CPernet Thanks for raising that point, Cyril. Do you have an example of such a case? Would it still make sense to put them under dwi/ or would you propose allowing it under multiple datatypes?

@smeisler Re acq vs rec, I agree that acq doesn't fit well, but I don't think rec quite fits, either, as the reconstruction algorithm is different from post-processing. One could consider taking proc- from MEG for this purposes. I have updated the first option to let it stand in for any entity, even if not acq. If that ends up winning, we can figure out the best entity, but I don't think we should spend much thought on it unless it does.

@mattcieslak /@arokem I suppose BEP016 is on-topic and I kind of wish I'd put a "Whatever BEP016 says" option there. With it as tilted as the result already is, I think we cannot legitimately put it in this vote. I would suggest a new topic where we hash out BEP016 interactions and see if it justifies another vote between the winner of this poll and the outcome of that discussion.

[CPernet]

I think we discussed this and should go for rec- as per https://github.com/bids-standard/bids-specification/pull/105. Obvious cases of scanner computed map are the phase map difference, distortion correction anat, cbf map (from ASL), qMRI stuff, and we store all those as raw

[effigies]

I see. I misunderstood, I thought you were saying TRACE/ADC were used in non-DWI contexts. Thank you for clarifying.

[effigies]

I've opened https://github.com/bids-standard/bids-specification/pull/1725. The text is synthesized from reading https://mriquestions.com/trace-vs-adc-map.html, but I have no practical experience. Expert review would be appreciated.

[Lestropie]

Popular option " :rocket: Create TRACE and ADC suffixes" risks an unwanted expansion in suffices once the principle extends beyond this one use case; explanation below the line.

I would personally make a proposal further changing the comments mentioning BEP016:

• Such images are saved in a derivatives directory within the raw dataset;
• The pipeline name is determined based on either:
  • The name of the scanner sequence that generated it;
  • A simpler approach where some reserved name indicates generation by the acquisition hardware;
• The storage conventions within there obey whatever the plans for BEP016 are (or other BEPs for other derivatives for which a subset is possible to generate on the scanner).

---

On Siemens MRs, the derivative images that can be auto-generated by the DWI sequences are I believe:

• Trace
• ADC
• FA
• Coloured FA
• Tensor
• "Tensor_B0" (presumably S0, ie. b=0 intensity predicted by tensor model)

Given any of these can be from the same sequence through a set of checkboxes, I don't think that it would be appropriate to allocate suffices for some but not all.

Assuming that one wanted new suffices to cover all of these, the problem then is how to deal with all of the other mechanisms that themselves create all sorts of parametric maps. Some pipelines may fit the tensor model, and yield one or more of these same derivatives, albeit likely with some image pre-processing having happened beforehand; others will fit other models, and will yield different derivatives.

I figure there's two options here:

1. Any model derivative that has the special distinction of there existing a scanner sequence capable of generating that derivative gets its own suffix.

   1. An analysis pipeline that generates exactly the same derivative would be expected to conform to BEP016. So there would be a strange situation where the very same parametric map uses different filesystem conventions depending on whether the "pipeline" that generated it was sequence code or something downstream.
   2. This to me gives too much power to the scanner sequences. The set of derivatives they generate is not set in stone.
   3. This logic of allocating new suffices for scanner-generated derivatives would need to extend to non-DWI sequences.

2. We allocate a new suffix for every unique parametric map. This equates to an acceptance of https://github.com/bids-standard/bids-bep016/issues/50: Decision 2 "File names", option 2 "many suffices". It expands so rapidly so as to become prohibitive; indeed the BIDS Validator would likely need to ignore suffices in derivative datasets, lest generation of novel derivatives outside of the current version of the specification be deemed illegal. BEP016 opted to move away from these based on the desire to keep suffix expansion to a minimum. So creeping in that direction for the sake of fulfilling the need at hand may have greater detrimental consequences on derivatives as a whole than it may initially seem.

Personally I don't like either of these.

I think the fundamental source of the problem is trying to sneak scanner-generated derivatives into "raw". If you accept that scanner-generated derivatives are "derivatives", I believe the landscape becomes much more clear.

---

Edit: As per comment and link therein, separating scanner-generated derivatives from raw data may not be a fan favourite. So now I'll have to add an argument I decided to omit from my original post for simplicity.

Scanner-generated derivatives could follow the conventions established (or being created) for derivatives (eg. _dwimap for ADC / TRACE), but be stored directly alongside the other "raw" data (acknowledging the issues around defining what "raw" means in the presence of such). I suggest that this could work, but might require revision of the following:

Further, any files created as part of a derivative dataset must not match a permissible filename of a valid raw dataset. Stated equivalently, if any filename in a derivative dataset has a name permissible for a raw BIDS data, then that file must be an identical copy of that raw file.

If such scanner-generated derivatives can be stored in raw datasets, obeying the same naming conventions as would be used were those derivatives to have been generated using a downstream processing pipeline, then the demands around per-file distinction between raw and derived may need to be thought about more carefully, since a derivative file (being eg. a DWI map file encoding ADC) could now very clearly be "permissible" as a raw data file.

Now maybe the issue here is that the quoted sentences are in fact not equivalent, and the latter is the more crucial one, ie. a derivative dataset can't have a file that has exactly the same name as a raw file unless it's an exact duplicate, and I'm unfairly picking on the word "permissible". So if a pipeline were to generate an ADC image based on pre-processed DWI data, but its path were to collide with a (present, not hypothetical) scanner-generated one, disambiguation would need to be performed (and that disambiguation would have to be performed unilaterally on the pipeline derivative). What that disambiguation should be isn't immediately clear to me: "_desc-preproc" provides sensible disambiguation for raw vs. pre-processed DWI data, but for ADC data, "preprocessed" is moreso an observation of provenance rather than what the data are.

One advantage of scanner-generated derivatives being in their own directory separated from the raw data is that this wouldn't be an issue.

[arokem]

@Lestropie: What do you think of the other (entity-based) option for change?

🎉 Carve out acq-ADC_dwi.nii[.gz] and acq-TRACE_dwi.nii[.gz] as special DWI images that can be 3D and not require bval/bvec. (Vote for this if you would prefer an entity, even if not acq.)

What about using an entity for this, and adding the dwimap suffix (a la https://github.com/bids-standard/bids-extensions/pull/26) to indicate that this is not DWI? Could maybe still be considered "raw", rather than derivative? (i.e., the opposite of my previous comment). I think this is similar to what you are suggesting, but uses the dwimap suffix in place of a "derivatives" directory inside the "raw" directory. I think that the reason not to treat these as derivatives boils down to this, and I think the same line of reasoning would make a "derivatives" directory inside the "raw" directory confusing.

@CPernet : your recent comment suggests that you also favor an entity-based solution (rather than suffices). Does that change your original vote here?

[Lestropie]

@arokem: Response in comment update (trying to obey RoE).

[arokem]

Oops. Sorry for messing up and not following the RoE!

[CPernet]

issue 1: raw vs derivatives - derivatives are objects computed from BIDS raw
A Trace, FA or ADC coming out of the scanner should, therefore be in the root directory (and that what we should document)
A Trace, FA or ADC that one computes should, therefore go into derivatives (no need to document that IMO, since almost no one does that)

[CPernet]

issue 2: acq- Those maps are not acquired, as discussed above this could berec-, alternatively we can use the more generaldesc-. Using suffixes solves that discussion altogether -- I have no preference, except not using acq-