 |
 |
Hi all, Similar to the email below, I have also noticed that the output of eddy_openmp looks worse than the output of eddy. In the eddy_openmp output, the DWIs don't line up with the b0s, which wasn't the case for the input to eddy_openmp or for the output from eddy. This is a problem for some participants, not all. I saw Jesper's suggestion below and I tried adding the --dont_peas flag to eddy_openmp, but this didn't seem to help. Do you have any suggestions? Many thanks, Claire Claire Kelly BSc (Hons) Research Assistant Victorian Infant Brain Studies (VIBeS), Clinical Sciences Murdoch Childrens Research Institute The Royal Children’s Hospital Flemington Rd Parkville, Victoria 3052 AUS E: [log in to unmask] www.mcri.edu.au<http://www.mcri.edu.au/> ________________________________ From: FSL - FMRIB's Software Library [[log in to unmask]] on behalf of Vasilis M. Karlaftis [[log in to unmask]] Sent: Wednesday, 1 February 2017 4:37 AM To: [log in to unmask] Subject: Re: [FSL] eddy_openmp correction seems worse than eddy Dear Jesper, Thank you for your time to give me a very detailed response on my question. I will give a try on the --dont_peas option and see. Best regards, Vasilis On 31 January 2017 at 17:15, Jesper Andersson <[log in to unmask]<mailto:[log in to unmask]>> wrote: Dear Vasilis, > Dear FSL experts and users, > > I recently updated my FSL version and gave a try to the new eddy version, which includes some really cool and useful features (like rms movement, bvec rotation). So I decided to estimate the motion of each participant using the restricted_rms_movement output as previously suggested in this list. However, I noticed that the ecc output is different than what I got with the previous eddy version (505 build) and it looks to me that it is worse in general (for some participants at least). > > The issue is that the algorithm detects a "jump" in motion when it goes from a b0 to a gradient volume.In most data I get restricted rms value of ~1 for 2nd volume compared to the 1st. The other values seem very small at ~0.1-0.3 range (relative to previous volume). Comparing the eddy_parameters files, there was also a big inconsistency on the values estimated by the two algorithms, with the new version assigning much higher values for the second volume. > > Visual inspecting the ecc files, I believe that the "old" version did a better job (at least in the data I checked so far). I would like to ask if someone else has experienced the same issue and if there is a way to "improve" or make the two outputs more similar? I _think_ this is what you see: In eddy all the dwi:s and the b0:s are aligned independently of each other. In the previous version of eddy there was no explicit alignment of the dwi:s with the b0:s. Instead it relied on the assumption that the first b0 and the first dwi (who are reference locations for the b0:s and dwi:s respectively) are acquired close in time, and that therefore there is no/little movement between the two. This would for example be the case if the first volume is a b0 and the second volume is a dwi. Since that release I came across several data sets where this was not the case, so I decided to include a “post eddy aligmnment of shells” (peas). This is based on averaging all dwi:s and all b0:s and do a mutual information alignment between the two. As with all mutual information alignment the accuracy is so-so (~0.3mm in the experiments I did, compared to ~0.1mm for the within shell precision), but at least it guarantees that there aren’t any really large misalignment between b0:s and dwi:s. As a “precaution” against large misalignments it performs the “peas” by default. If your data is of the kind that the first b0 and the first dwi really are very close you can probably do better by adding the --dont_peas flag. This turns off the “peas”, and you wont have the ~0.3mm uncertainty in relative location between the b0 and the dwi shells. Jesper > > I used the exact same call for both functions: > <eddy> --imain=subjXX --mask=eddy_mask --acqp=acqparams.txt --index=index.txt --bvecs=subjXX.bvec --bvals=subjXX.bval --topup=AnP_topup --fwhm=0 --flm=quadratic --out=subjXX_ecc > > Best regards, > Vasilis > > PS: I have prepared a folder with all the relevant files to upload if anyone is willing to take a look at this :) ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com If you have any questions, please contact MCRI IT Servicedesk for further assistance. ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________