B0s with different SNR: consequences for CSD

Dear experts,

I have posted a message in the FSL mailing list concerning this topic before, but I have since then started using MRTrix as well and I wonder if the same issues apply (full existing thread begins here: JISCMail - FSL Archives).

Briefly, I am acquiring some diffusion measurements using a protocol similar to the one of the Human Connectome Project. This means that we have 4 multiband multishell diffusion acquisitions: 2 with 79 directions and 2 with 81 directions, each pair with phase encoding direction AP and PA respectively.
The issue is the following. We have discovered that our scanner facility adds at the start of every multiband scan 2 calibration b0s. There are other b0s in our acquisition, interspersed among the volumes, but these calibration volumes have particular properties. Here is the description I made in the FSL list:

Our physicist has gotten back to me with some more specifics on this calibration b0. First of all, it is worth mentioning that we are scanning with a multiband factor 4 and our TR is 3.2. The calibration b0 is reconstructed from four b0 volumes, of which each is acquired with the same TR of the other directions. Specifically, to reconstruct this volume, each multiband series of four slices is acquired 4 separate times. Therefore theoretically the SNR of this volume is sqrt(4) times higher than the b0s in the diffusion acquisition. All the other acquisition parameters, e.g. TR, TE, echo spacing etc, are the same as the other diffusion volumes, and it also has the same signal level and contrast as the other b0s.

At first, we thought of removing these calibration volumes, but this made our files incompatible with preprocessing using the HCP scripts. In the FSL mailing list, we were reassured to find out that keeping them actually does not affect preprocessing. However, Jesper from FSL suggested removing them before running bedpostx or dtifit. The thing I would like to know is, would these volumes similarly impact your implementation of multi-tissue constrained CSD and would you also recommend removing them? The preprocessing collapses all diffusion directions into one file, this is why identifying and removing these calibration b0s and modifying the bvals/bvecs accordingly could be laborious and we are wondering if it is necessary.
Thank you very much for your help.

Leonardo Tozzi

The presence of volumes with different SNR would invalidate the requirements of dwidenoise. But as far as model fitting goes, neither of the CSD variants in dwi2fod explicitly consider noise levels or the like: it is a straight (constrained) least squares fit to the image data provided (so technically assuming Gaussian noise). So, for instance, the separation of tissue contributions in MSMT CSD would be less influenced by the averaged b=0 image than it would be if each of these four b=0 volumes were included individually in the DWI series. This also means that e.g. doing a WM & CSF fit in a protocol with 1 b=0 volume and 60 b=3000 volumes will behave differently to the same fit to a protocol with 8 interspersed b=0 volumes and 60 b=3000 volumes.

We’ve not yet got a consensus or solution on how to deal with this. But given the above, and the fact that there aren’t any requirements or assumptions being broken, I would personally probably err on more data being better than less data.

Rob

Just a quick addition to @rsmith’s comments:

This is actually pretty easy within MRtrix3, you can use a command like:

mrconvert input_dwi.mif -coord 3 0,2:10,12:23,25:end output_dwi.mif

to do this. See number sequences for details. This deals with keeping the DW scheme in sync with the data as expected.

This assumes you’re using the MRtrix3 mif format, which keeps the DW encoding information in the header. If you’re using NIfTI, it’s a bit more involved, but the same principle applies: use the mrconvert call as above, but add the -fslgrad option to specify the input bvecs/bvals, and the -export_grad_fsl to specify the output ones.

Your responses are excellent and I think cover all possible solutions to the problem!
I think we will keep the b0s, but I am glad to see that there is a simple way to remove them if we want to do so.
Thank you very much,

Leonardo Tozzi