If my suspicion is correct, that will prevent the Python argparse module from erroneously discarding the first entry in the content specified via the “-eddy_options” command-line option, which will in turn prevent the dwifslpreproc script from going down this code path unnecessarily. This glitch is unfortunately out of my control unless I completely implement a Python command-line interface for MRtrix3 from scratch…
I would also express caution at using FSL eddy for pre-processing these data: while providing “--data_is_shelled” may get the command to execute, your data are in fact very clearly not shelled, and I don’t know exactly what eddy will do in this circumstances, because the Gaussian Process it uses to generate predicted images for registration does not operate across b-values.
Hello, I also met the similar question with you and I used the FSL to do the pre-processing but want to use the ‘tckgen’ to track. Also appeared ‘DWI volumes could not be classified into b-value shells; gradient encoding may not represent a HARDI sequence’, which kind of code should I use to track between the two ROIs’(ROI1 and ROI2) tckgen? I am appreciate that you can help me about that.
You would need to be more specific about your issue for us to provide useful advice. If you have the same problem as the original poster, then your data inherently can’t be pre-processed using FSL (or at least, not using eddy). We’d need to know a lot more about your sequence and the specifics of the DW encoding scheme before we can comment on whether your sequence can be processed using MRtrix at all.
If your DW encoding doesn’t use a shell structure, but something like a DSI acquisition, I think you can use QSIPrep (as suggested above) to do the preprocessing, and as I understand it, that can then be used to generate data suitable for use with tckgen. But I don’t know the specifics of how that might work…
Hello,sorry for I didn’t make my question clear.
And very thank you for your reply. I am using the same DTI dataset from the OASIS with the original poster said and with the same.bval file. I tried to use the FSL’s ‘eddy_correct’ to do the pre-processing and it did work. ‘eddy’ I want to try this next step and thank you for telling me this will not work. As I used the code bellow in Mrtrix3 (whether this can get what I want: fiber cross the two mask ROIs and it’s count, length and mean value of FA/MD):
data.nii.gz: zip dwi image after eddy_correct;
MD/FA.nii.gz: after I did the FSL’s dtifit get the two images
Yes, eddy_correct makes very minimal assumptions about the data, and should ‘work’ for any dataset – as long as the registration between the b=0 volume and each individual diffusion-weighted volume works correctly (not always the case), but it also ignores susceptibility-induced distortions (not necessarily a problem in your case, I expect these datasets don’t come with the reversed PE scans needed to perform the correction anyway), and doesn’t perform outlier rejection and correction. In my experience, eddy_correct often introduced more problems than were originally present…
That is indeed the problem.
Both of these steps also rely on the data being multi-shell, so won’t work with your data – at least not in their current form. We had a brief look at the acquisition details, and assuming the diffusion encoding is as described on page 12 of this document (25 directions, none of which have the same b-value), I’m afraid there isn’t much you can do with it other than regular DTI…
While providing the --data-is-shelled to eddy has the potential to convince eddy to proceed with processing even with data it deems to not be arranged in shells, the originally reported error message was actually generated by an MRtrix3 command; presumably the internal dwi2mask call. So no amount of coercion of eddy would have actually gotten around this.
Hopefully in 3.1.0 we will have these changes to DWI masking, which (following appropriate configuration on your part) will allow MRtrix3 scripts that may want to execute dwi2mask to still proceed, by selecting a masking algorithm that is compatible with non-shelled data.
But nevertheless, the fact that both MRtrix3 and FSL would classify this as a non-shelled acquisition means that eddy is likely not the right choice anyway.