On 21 Nov 2018, at 01:15, Forrest Koch <[log in to unmask]> wrote:

Hi,

I have some questions regarding troubleshooting the QC output of eddy_quad.  The QC result in question can be viewed at:
https://drive.google.com/file/d/1200_hCTj28baeSfpYQCmzP0geTr0Gy7q/view?usp=sharing

As you can see, on the very last page,  there appears to be a large number of outliers in the first half of the scan, and I am wondering if this may indicate a processing error, scanning error, or whether it is even something to be concerned about.  This is observed on all of my scans.

The DWI data is a multishell sequence (25 * b = 700, 40 * b =1000, 75 * b = 2800, 8 * b = 0 @0,20,40,60 ...) TE=0.1152, TR = 4.245 acquired on a GE Discovery MR750w.  As you can see, the number/intensity of outliers seems to be related to the shell (volumes 1-27 are worst, then 28-68, and the remainer barely have any outliers).

yes, we see this too. It is a consequence of how I have implemented the threshold for outlier rejection in multi-shell data. I was basically faced with a choice between keeping type 1 errors (false positives) or type 2 errors (false negatives) constant across shells. The default is to keep type 1 errors constant, which means that type 2 errors (i.e. sensitivity) varies between the shells. Therefore it is more sensitive at detecting outliers in the lower b-value shells.

There is an undocumented (and I think hidden) option to keep type two errors constant instead (--ol_ec=2). The “problem” with that approach is that shells with very few observations will end up with poor estimates of uncertainty.

Overall eddy is quite sensitive when it comes to detecting outliers so I suspect that if you do a careful occular inspection of one of your data sets you will probably think that it is “overly fussy” in the lower b-value shells, and any slice that has severe dropout will be detected even in the higher shells.

Jesper

 

I have used this data to produce DTI (only from the first 2 shells), DKE, and NODDI output.  None of the maps appear to have any major problems.

A quick outline of my workflow:

1) Run topup using a reverse phase encoded image

2) Use the output of topup to run eddy_openmp -- (this was actually done using 5.0.11; however, the change-logs indicate that nothing has changed moving to 6.0.0 so this shouldn't be causing any problems)

3) Run eddy_quad using the output of eddy_openmp

Any insights would be much appreciated.

Kind Regards,

Forrest

---

To unsubscribe from the FSL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=FSL&A=1