How is multishell data split in multiple files handled?

[pierre-nedelec]

Hello !

I have a similar question as #320. I have multi-shell data which was acquired with slightly different parameters (see screenshot below), and are split by b-values: one file for b=1000, one for b=2000.

Here's what it looks like after putting in BIDS format:

.
├── dataset_description.json
├── sub-1
│   ├── anat
│   │   ├── sub-1_run-1_T1w.json
│   │   ├── sub-1_run-1_T1w.nii.gz
│   │   ├── sub-1_run-1_T2w.json
│   │   └── sub-1_run-1_T2w.nii.gz
│   └── dwi
│       ├── sub-1_acq-d30b1000_run-1_dwi.bval
│       ├── sub-1_acq-d30b1000_run-1_dwi.bvec
│       ├── sub-1_acq-d30b1000_run-1_dwi.json
│       ├── sub-1_acq-d30b1000_run-1_dwi.nii.gz
│       ├── sub-1_acq-d55b2000_run-1_dwi.bval
│       ├── sub-1_acq-d55b2000_run-1_dwi.bvec
│       ├── sub-1_acq-d55b2000_run-1_dwi.json
│       └── sub-1_acq-d55b2000_run-1_dwi.nii.gz
...

I'm not quite sure how qsiprep will handle that: should I concatenate the files myself before running it, is there a special argument to use? I saw on BIDS docs there is a multipart-split-dwi-schemes, but not sure if this the right way to go about that either.

Any help would be appreciated, thank you!

[arokem]

Given the difference in TE between the acquisitions, I would expect the measurements to differ between the two scans in ways that are not predictable only by the b-values. For example, I'd expect the b=0 measurements to systematically differ. One approach to correcting for this would be to pre-process each of the scans separately and then add a post-processing step where each volume (including b=0 volumes) is normalized to its average b=0 measurement before proceeding with any of the reconstruction steps (e.g., modeling). I'd be curious to hear other folks' thoughts on this, and whether qsiprep already supports this kind of use-case.

[mattcieslak]

Is it not common to collect multiple b>0 values in GE DWI scans? @arokem I had typed something almost identical, and agree that processing these separately is likely the safest way to go. You can do this with the --separate-all-dwis flag, which will process each independently. Without this flag, qsiprep will concatenate these scans and your downstream analyses may not work as intended.

I wonder if this is similar to what used to happen for some siemens sequences where big delta and little delta would get secretly adjusted under the hood depending on the maximum b-value in the sequence. Based on the different TE, this might be happening in these scans. If that is the case you'll need to be extra careful when using something like MAPMRI (you won't be able to use the qsiprep mapmri recon workflow, unfortunately). I'm not sure how it will impact the multi shell - multi tissue methods.

Slightly off topic: you will need to make sure you have "PhaseEncodingDirection" and "TotalReadoutTime" defined in these sidecars.

[pierre-nedelec]

Thank you for your feedback! Another source pointed out by a colleague: https://community.mrtrix.org/t/dwi-images-with-different-echo-times/5892

@mattcieslak thanks for the note, these two values are defined in the sidecars.

[pierre-nedelec]

So it seems that the steps would be to:

1. preprocess the dwis separately (with --separate-all-dwis)
2. do some kind of normalization: @jdtournier proposes to do a "matching and concatenation based on histogram matching of the b=0 images" (link), @arokem "normalized to its average b=0", any thoughts?

For further processing, which might be beyond the scope of this thread, such as pyAFQ and especially FOD computing, it seems most wouldn't be appropriate (ref in link above), but MSMT-CSD should work? I'd be curious to understand that last part better.

Thank you all for your help & insights!

[cookpa]

Do you have a plan for correcting geometric distortion? Does your TotalReadoutTime vary between the series?

[pierre-nedelec]

The only differences are highlighted in the screenshot above, TotalReadoutTime is the same for both series.

[cookpa]

Ah OK. I was thinking you can theoretically use topup if the echo spacing varies, even if the phase encode dir is the same.