Nothing wrong here, based on what you report; especially if…
That actually shows
mtnormalise did a splendid job!
As to why those scales where so off to begin with (and
mtnormalise then corrected that), that is realistically one of 2 things:
Your raw data showed such huge variations; this can sometimes happen due to how the scanner decides to save the data. I’ve seen cases where a min-max or something determines this, and even a single outlier voxel hence causes this. That’s in principle not a problem, since T2-weighted and other …-weighted images don’t come with a unit.
dwibiascorrect caused this. Again no worries in principle, same reason as above: the solution is determined up to a constant factor. In the end, the only “impact” of this is that certain subjects’ estimated response functions will have had a greater weight in computing the average response. I’ve thought about this long ago, and people have suggested to do some renormalisation of the responses before averaging for this reason; however, there’s no important need for this, as the responses vary very little (in shape/contrast) to begin with. There’s actually not even a reason for why you have to average them all; it’s just the most elegant solution in the absence of arguments for another one. I do have another alternative in mind, which I may at some point suggest in writing here or there; but again, to be honest: this won’t have any noticeable impact on your study.
So well, while going a bit off topic in point 2, essentially: I’m not surprised, and I’ve seen this more often. Actually, in the multi-tissue pipeline,
dwibiascorrect is entirely optional (and at some point in the docs history, it was even not included in that pipeline), as
mtnormalise does everything that needs to be done in terms of spatially varying as well as global intensity normalisation (and does it much better than anything that is only driven by the b=0 images). I’m currently doing a relatively in-depth revision of the FBA pipeline documentation, and adding important notes and warnings based on all FBA projects I’ve been involved in so far; one of them is exactly this fact that the
dwibiascorrect is entirely optional. The only reason why it does still sit in the pipeline (or can be considered at least to be included) is for better mask estimation at the
dwi2mask step, but then again only really in case of severe bias fields in the original data. But we’ve actually encountered cases where even the opposite is true, and
dwibiascorrect is the culprit to be blamed for less-than-great masks (often when bias fields where quite limited in presence and “intensity” in the original data). There’s definitely several projects, where I’ve advised and we’ve actually ended up not including
dwibiascorrect in the pipeline.
I hope this all makes some sense. I’ll be posting a link to the updated documentation soon, as the process of getting it properly on
master is always causing delays. Better to make sure people have access to the most up to date advice as soon as possible!