 |
 |
Hi Jesper and Sjoerd, what about an option "--omit-check" or similar. If the checks are too liberal, then they might miss some problematic cases and no-one realises because the data were checked. If the checks are, on the other hand too strict, then some people might not be able to use eddy which might decrease the analysis' quality. If eddy refuses to process your data it is a strong indication to verify the data/ method again but if one is sure that they are ok, there would be a possibility to go on. Cheers, Jan On 10/20/2015 01:02 PM, Sjoerd Vos wrote: > Hi Jesper, > > Thanks, I know from previous messages DSI acquisitions are not > supported, and I think it's very good there's a check for that in eddy. > As you say though, it's a bit too strict - at least for our protocol. > Our protocol is to acquire a 11 b=0-images, and then 8/32/64 DWIs at > b=300/700/2500 s/mm2, respectively. I know this is a protocol used in > more locations, not only throughout UCL but in other universities as > well. I'd be happy to send through and example dataset for you to check. > Is there a way to update eddy to ensure these checks are less strict? Or > to estimate the distortions on a densely sampled subset (e.g., the b=700 > and b=2500 shells) and then apply to everything? Given that the eddy > source code is not available I can't change it myself and recompile so I > hope this is something that can be changed from your end. > > Cheers, > Sjoerd > > On 20 October 2015 at 11:24, Jesper Andersson > <[log in to unmask] <mailto:[log in to unmask]>> > wrote: > > Dear Sjoerd, > > this is a consequence of a test in eddy to ensure that data is > indeed shelled (i.e. not DSI). It looks for things like number of > different b-values (shells), minimum number of scans with a given > b-value (shell), minimum and maximum proportion of scans within > shells etc. If the data doesn’t fulfil these criteria it will be > assumed that it is DSI and give the error message you saw. > > However, I have come to realise that the way we design our multi > shell protocols isn’t universal and that the test might be too harsh > sometimes. The more examples of protocols I get from different > people the better, because then I can modify my criteria to allow > for these. > > Jesper > > > On 20 Oct 2015, at 10:12, Sjoerd Vos <[log in to unmask] > <mailto:[log in to unmask]>> wrote: > > > Hi, > > > > I was trying to run the new eddy_openmp on my multi-shell > diffusion data, and I got the exception copied below. eddy in v5.0.8 > had no problem correcting the same dataset, but I'd like to get the > rotated bvecs that v5.0.9 outputs. This exception was irrespective > of how my data/bvalues were ordered. For simple single-shell data > (extracting the b=0 and b=2500 data from my multi-shell data) the > new version works fine. Any suggestions on this issue? > > > > Thanks, > > Sjoerd > > > > Reading images > > Running Register > > Loading prediction maker > > Evaluating prediction maker model > > Calculating parameter updates > > Iter: 0, Total mss = 257.21 > > Loading prediction maker > > Evaluating prediction maker model > > Calculating parameter updates > > Iter: 1, Total mss = 229.195 > > Loading prediction maker > > Evaluating prediction maker model > > Calculating parameter updates > > Iter: 2, Total mss = 228.106 > > Loading prediction maker > > Evaluating prediction maker model > > Calculating parameter updates > > Iter: 3, Total mss = 228.035 > > Loading prediction maker > > Evaluating prediction maker model > > Calculating parameter updates > > Iter: 4, Total mss = 227.975 > > Running sm.Setb0Reference > > Running sm.PolateB0MovPar > > Running Register > > Loading prediction maker > > Evaluating prediction maker model > > I'm thrown > > terminate called after throwing an instance of > 'EDDY::KMatrixException' > > what(): KMatrixException: > msg=MultiShellKMatrix::SetDiffusionPar: Data not shelled > > Abort > >