# Dwidenoise with dwipreproc **URL:** \ **Category:** Uncategorized\ **Created:** [March 15, 2019, 2:22pm UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358 "2019-03-15T14:22:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Matteo\_Diano](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@Matteo\_Diano](https://community.mrtrix.org/u/Matteo_Diano)\ **Post date:** [March 15, 2019, 2:22pm UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358/1 "2019-03-15T14:22:44Z")
Dear MrTrix experts, I have encountered a problem while i was using eddy (inside dwipreproc scrip) and dwidenoise. I am using mrtrix3 on centos 7. I have done 1. dwidenoise --\> dwidenoise dti.mif dti\_deno.mif 2. dwipreproc --\> dwipreproc dti.mif dti\_deno\_eddy.mif -rpe\_none -pe\_dir AP -readout\_time 0.1 --eddy\_option " --slm=linear" but it returned to me this error: **Segmentation violation, Address not mapped, Offending address = (nil) /lib64/libc.so.6 [0x7f41255b1f8f] eddy\_openmp ) [0x6075c6] [��� eddy\_openmp ) [0x60245b] [���** I tried again without using dwidenoise and everything went fine. Any advices will be very helpfulness Thanks in advance! All the best, Matteo ---
**Author:** ![mheyne](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/e9a140/32.png) [@mheyne](https://community.mrtrix.org/u/mheyne)\ **Post date:** [March 16, 2019, 8:27pm UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358/2 "2019-03-16T20:27:53Z")
Hi Matteo, You might find answers to your question here [Denoising and unringing before eddy](https://community.mrtrix.org/t/denoising-and-unringing-before-eddy/2223) and here [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1901&L=FSL&P=R48437&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4](https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1901&L=FSL&P=R48437&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4) 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). Best, Matthias ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [March 17, 2019, 6:09am UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358/3 "2019-03-17T06:09:17Z")
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. ---
**Author:** ![mheyne](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/e9a140/32.png) [@mheyne](https://community.mrtrix.org/u/mheyne)\ **Post date:** [March 20, 2019, 6:33pm UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358/4 "2019-03-20T18:33:52Z")
Dear all, 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](https://www.sciencedirect.com/science/article/pii/S1053811918306827?via%3Dihub)] Best, Matthias ---
**Author:** ![Matteo\_Diano](https://community.mrtrix.org/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@Matteo\_Diano](https://community.mrtrix.org/u/Matteo_Diano)\ **Post date:** [March 22, 2019, 9:53am UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358/5 "2019-03-22T09:53:47Z")
Dear all, @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! All the best, Matteo ---
**Author:** ![rsmith](https://community.mrtrix.org/user_avatar/community.mrtrix.org/rsmith/32/2672_2.png) [@rsmith](https://community.mrtrix.org/u/rsmith)\ **Post date:** [April 6, 2019, 4:43pm UTC](https://community.mrtrix.org/t/dwidenoise-with-dwipreproc/2358/6 "2019-04-06T16:43:53Z")
> `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…