Why not dwibiascorrect -fsl option for FBA?

preprocessing

#1

Hi, I would like to know the reason behind the advice of not using the -fsl option (i.e. using FAST) for dwibiascorrect when doing Fixel-Based Analysis. Thanks!


#2

Main reason, as far as I know, is simply that -ants works better (search for ‘fast’ on this forum to find other threads that go into this).

Also, bear in mind that if you use MSMT-CSD (in the dwi2fod call), you’ll be encouraged to also use mtnormalise to remove any remaining bias field and for intensity normalisation.


#3

Ok, I see. Interestingly FAST is working better for my dataset than N4, hence I asked. Although I can probably get better results if I play around with the N4 options.
Thanks for the advice about MSMT-CSD.


#4

Well, ehm, not exactly…

That’s perfectly possible. Bias field correction entirely depends on all parameters you set in the method(s) to correct for it. So when you’re seeing this, it’s just because of the defaults of either method, relative to what’s best for your data.

Without a doubt.

If you’re following the multi-tissue pipeline, you can rest assured that mtnormalise will fix whatever was not fixed yet.

But coming back to…

So that’s actually not the reason (nor per se the fact). The problem with the fast-driven method is that is only corrects the bias field within the supplied brain mask. However, about (almost) the only reason (especially in the multi-tissue pipeline) we still have dwibiascorrect at that stage (even though mtnormalise fixes stuff anyway), is that it can help with brain mask estimation (i.e. dwi2mask in a later step). But when dwibiascorrect with the fast-based approach works within a temporary suboptimal mask, it’ll introduce a sharp entirely artificial boundary between corrected and uncorrected data in your images. This will either undermine the subsequent, intended-to-be-better, mask estimation; or even worse, that sharp artificial boundary will be within your new mask, and subsequent analysis. mtnormalise can’t magically fix such random jumps in intensity down the track either.

So essentially, the fast-based approach is simply fundamentally incompatible with that pipeline as it stands. (and that’s why it’s so explicitly stated in the documentation). For many other similar pipelines, the same would be true; which is why I argued in the past to get rid of that bias field correction method altogether in the code: I’ve seen several users get very wrong analysis results because they’re not entirely clear on this property of that method. And, as you say, @Julio_Villalon, you can almost certainly get a similar accuracy of bias field estimation from the ANTs-based method by setting the parameters appropriately for your data.