Basically, there are differing opinions on whether one should apply denoising (and Gibbs ringing correction, which I also recommend -> mrdegibbs) prior to running eddy. I have yet to see eddy fail on denoised and/or de-Gibbs-ed DWI data (the problem described in my post to the FSL forum was a field map issue).
While it looks like there’s going to be some contention about the use of denoising before running eddy, that discussion should be about the scientific merit of the methods themselves and their interaction, and not the experience of a segmentation fault.
It would certainly be interesting to know exactly what the mechanism is that’s causing eddy to fail, and whether or not there is either any blame to be placed on MRtrix3 commands, or any capacity to check the nature of the data input to dwipreproc to either predict eddy failure or modify the data to prevent it. If you have data that consistently causes the crash I’d be curious to take a quick look.
I certainly did not mean to re-open the debate about the use of denoising and/or Gibbs ringing before running eddy, I was rather trying to make the point that the segmentation fault is likely NOT due to running dwidenoise. eddy seems to be pretty sensitive to minimal discrepancies in voxel size etc. so maybe something like that might be happening during denoising.
I also forgot to include the following reference to a recent paper describing the merits of running denoising and Gibbs ringing correction prior to using eddy:
Ades-Aron, B., Veraart, J., Kochunov, P., McGuire, S., Sherman, P., Kellner, E., … Fieremans, E. (2018). Evaluation of the accuracy and precision of the diffusion parameter EStImation with Gibbs and NoisE removal pipeline. NeuroImage , 183 , 532–543. [https://www.sciencedirect.com/science/article/pii/S1053811918306827?via%3Dihub]
@mheyne thank you Matthias for your suggestions and papers about using denoise and gibbs correction before running eddy. For my experience, applying this kind of pre-eddy processes seems to improve the final results and so i would apply also to my data.
@rsmith I could sent you the data. I just need to know which methods you prefer to share data. Thanks!
eddy seems to be pretty sensitive to minimal discrepancies in voxel size
That’s an interesting thing to keep an eye out for. Because MRtrix3 performs all critical floating-point calculations using double precision, but data must sometimes be imported from / exported to single-precision (eg. NIfTI headers), or indeed maybe just due to some of MRtrix3’s internal header information handling in general, it’s possible that some combination of internal numerical operations may result in a single bit difference between values that some other process may expect to be identical.
I’m also curious as to whether negative / non-finite values in the input image may have an effect…