Fixel-Based Analysis on single shell data

Hi all,
I’m planing to do a fixel-based analysis on some single-shell data(b=2000, dirs = 96). I’m confused that there are two FBA pipelines for single shell data in MRtrix3 docs. One is "Fibre density and cross-section - Single shell DWI;’ the other is “Fibre density and cross-section - Multi-tissue CSD”. So which one should I use?

Thanks,
Zonglei

The multi-tissue CSD pipeline requires multi-shell data - at least for the time being. So you’ll probably want to use the single-shell pipeline.

Note that it is perfectly possible to use multi-tissue CSD on single-shell data, since the b=0 images constitute a second ‘shell’. However, this doesn’t allow you to do a full 3-tissue decomposition, you’d be limited to WM & CSF, with GM not being handled particularly well. This still provides CSF suppression though, which might come in useful. However, it’s probably simplest at this stage to stick to the single-shell pipeline…

HI J-Donald:
Thanks much for your detailed information. I’ll get started with the single-shell pipeline.
Zonglei

Hi @Zonglei,

I second @jdtournier’s advice to stick with the (single-shell) single-tissue pipeline for the time being. The confusion in the manual is with respect to an upcoming release of single-shell 3-tissue CSD (SS3T-CSD, see this reference, we used it for instance successfully in this, and this / this study). But to be clear: this is not yet publicly available in MRtrix3. Our internal results have been produced with an internal prototype of the method that I built specifically for this purpose. Ironically, this is what’s been taking up a lot of my time and has delayed work on a publication / public implementation of the method… let’s hope that changes soon. :wink:

Apart from that, @jdtournier suggestion to use MSMT-CSD with just WM and CSF as tissue types is a useful one too. This will buy you free-water elimination, which is not per se unimportant at b=2000, and in the presence of certain specific pathologies. Furthermore, using the MSMT-CSD implementation in this way, will also buy you a “hard-constrained” implementation of CSD inherently. Our experiences over here with the latter aspect have been nothing but positive compared to the default “soft-constrained” default CSD. I would personally highly recommend it. I can provide you with further details privately if you wish.

For further related information on these topics, see also this, this, this (recommended), and this post elsewhere on this forum.

However, an important word of caution: however strange it may sound at first (maybe), if pursuing this strategy (dwi2response dhollander followed by dwi2fod msmt_csd with only the WM and CSF responses), I personally recommend plugging this step into the current single-tissue pipeline, only using the WM outcome of this all after this very step. The reason for this is that the multi-tissue pipeline does the mtbin bias field and intensity normalisation step right after this (and no bias field and intensity normalisation step before the CSD step). This very step, however, definitely requires the full 3-tissue CSD results (WM-GM-CSF) to work correctly at higher b-values (b=2000 is high enough in this context). Ironically, at a low b-value (say below b=1000), this wouldn’t be so much of an issue.

Finally, if you’d want to pursue using SS3T-CSD itself, just contact me privately; we can always arrange something if and when it makes sense.

Cheers,
Thijs

Hi @Thijs,
Thanks for the valuable comments.

If I understand you correctly, you are suggesting a mixed pipeline in which we use the single shell pipeline as the framework, but insert dwi2response dhollander and dwi2fod msmt_csd from multi-shell pipeline into it. Am I right?

Cheers,
Zonglei

Yes, that’s correct. So you’d be following the pipeline over here, but instead replacing step 6 (response function estimation) by:

foreach * : dwi2response dhollander IN/dwi_denoised_preproc_bias_norm.mif IN/response_wm.txt IN/response_gm.txt IN/response_csf.txt
average_response */response_wm.txt ../group_average_response_wm.txt
average_response */response_csf.txt ../group_average_response_csf.txt

…and step 9 (FOD estimation) by:

foreach * : dwi2fod msmt_csd IN/dwi_denoised_preproc_bias_norm_upsampled.mif ../group_average_response_wm.txt IN/fod.mif ../group_average_response_csf.txt IN/csf.mif -mask IN/dwi_mask_upsampled.mif

…and then proceed as normal with the FOD output. This comes down to estimating 3 tissue responses (WM, GM, CSF), but ditching the GM response upon doing MSMT-CSD with only WM and CSF, and then after that ignoring the CSF output (but knowing that the WM FOD will have benefited from its inclusion in the model).

Does that make sense? :slight_smile:

@Thijs Very clear, thanks much! I’m running the analysis according to your suggestion.

1 Like

Just a small addition here: as I’ve mentioned in this post just now, you can actually also continue using the multi-tissue pipeline after you’ve obtained the WM and CSF outcomes from dwi2fod msmt_csd. So essentially still dwi2response dhollander, ditching the GM response, dwi2fod msmt_csd with only WM and CSF responses, but then not ditching the CSF outcome, but proceeding with the multi-tissue pipeline (rather than the single-shell one) while using 2 tissue types (rather than the exemplary 3 in the documentation). The mtnormalise step should work quite well with WM and CSF, as long as they come from an actual 2-tissue WM-CSF reconstruction (so not from a 3-tissue WM-GM-CSF reconstruction where you ditch the GM; that would be ditching actual signal, which isn’t good for mtnormalise).

The reason why this still works very decently, is because the b=0 signal from GM is still not massively different from WM, and the non-b=0 signal will in most scenarios be the other way around. The CSF compartment will also still fit a tiny bit of the actual GM. So putting this all together, the summed WM+CSF image from a WM+CSF 2-tissue reconstruction, plus rebalancing (which mtnormalise does internally for you), still results in a quite flat image; apart from T2 shine-through and bias fields. That’s exactly the assumption that mtnormalise hinges on, so it does perform well in practice.