Dear Community,
in some rare cases (about 1 in 200 animals) our MRtrix pipeline is processing one animal for days without progress. When debugging we see an issue with the preprocessing, specifically with “dwifslpreproc”. Here FSL-“EDDY” complains: "Inconsistent b-values detected". This issue is somehow related to a recent post in the forum (Dwifslpreproc error for multishell dwi image).
I know, this is an issue which is rather FSL-related, since Eddy seems produces this error. Unfortunately, I can’t estimate a clear threshold where the b-value variation is to large to produce the variation. For the below b-table the last b-value (3338.2596) produces the error. The issue is solved when this value is closer to the median of all b-values (3342 and above works, but 3341 and below produced the “Inconsistent b-values detected” message).
I wonder whether it is allowed to replace all b-values within the same b-table with one identical b-value, for instance with the median value across b-values of the same table (without the b0-value,i.e. the 1st row). for example we have the following (shortened) b-table. Note that the last b-value (3338.2596) produces the error “Inconsistent b-values detected”
What do you think? Are there any crucial points after the preprocessing where the (true) variation of the b-values is used and mandatory, or can we simply replace the b-values by the median across b-values (within the same b-table)?
Thank you very much,
Paul
maybe of interest:
we use an multishell-approach, accordingly we would replace the b-values for each b-table separately
shellscript-command to run ““Inconsistent b-values detected”
for_each * : dwifslpreproc IN/mrtrix/dwi_den_unr_vox.mif IN/mrtrix/dwi_den_unr_pre_vox.mif -rpe_none -pe_dir AP -eddy_options " --slm=linear --data_is_shelled --verbose” -scratch IN/mrtrix/scratch
I think if you know these volumes all belong to the same shell, and should have the same b-value, it makes sense to fix the gradient table accordingly.
I would be inclined to really drill down into where this variability is coming from though. Is it really the case that the b-value for that volume is that different? If so, the validity of the analysis is going to be questionable… If not, I’d like to know what’s going on. How were these data produced, and where does that gradient table come from? If MRtrix was used for the conversion, I’d like to know that there isn’t a bug somewhere…
Hi Donald,
thank you very much.
You wrote “it makes sense to fix the gradient table accordingly”. … what would you recommend here, replacing the b-values of the same shell using the median or use the theoretical value?
The tables are directly extracted from the Bruker raw-data from one animal.
Presumably larger imaging gradients (and shorter TE’s) lead to larger variations of the b-values . For example, in a recent study we use 4 shells (b100, b900, b1600, b2500) and it seems that the variation increases with increasing b-value:
min mean max max deviation
b100 : 107 112 119 7
b900 : 880 910 941 31
b1600: 1565 1612 1642 30
b2500: 2454 2501 2555 54
(see tables below)
you will often get these variations because the vendor will include the imaging gradients in the b-value calculation, leading to deviations from the prescribed b-values/vectors – presumably because these prescriptions are used upfront to compute the intensities and directions of the DW PGSE gradient pulses without accounting for the imaging gradients.
the variations you’re showing are not enormous – though I can appreciate that they may sometimes cause failures in the shell clustering. You can control that using the BValueEpsilon config entry, which is explained in more detail in the diffusion gradient scheme handling page in the docs. See also this page for information on how to set config-file entries.
You will typically find these variations increase with b-value because they typically arise from the interaction between the imaging and diffusion gradients (so-called cross-terms). But they may also be worse on a preclinical system if the sequence isn’t geared towards minimising these terms (e.g. by applying the read-out dephaser before the PGSE pulses).
I don’t think there will be a great deal of difference between the theoretical and median values (at least, hopefully not…). What is important is that whichever value you use, you are satisfied that replacing the value shown is the right thing to do – e.g. it’s due to a glitch in the conversion or something. From what you’re showing me, that’s not the case. I don’t think replacing the values is the right course of action, or even required for the analysis – for MRtrix, you’d be better off tweaking the BValueEpsilon value to help the clustering algorithm get it right…
HI Donald,
I tried the “BValueEpsilon”-parameter (see bellow command) and tested the values 50.0; 100.0, 150.0. The error however remained (note that we have also the “eddy_cuda10.2 issue” due to missing libraries…). I think this issue is is rather FSL/eddy-related and there seems to be a hidden threshold evoking the “Inconsistent b-values detected”-error…at least I couldn’t find any parameter similar to MRtrix-BValueEpsilon for FSL-eddy (eddy/UsersGuide - FslWiki)
Thanks again,
Paul
Yes, of course you’re totally right… You still indeed need to modify the b-values to get eddy to accept these data. Whether median or expected value is up to you!
