Hi MRtrix Team,
I am attempting to preprocess some of the DTI data provided by the OASIS-3 dataset. Upon running the dwifslpreproc script with the following arguments:
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.
Hi @rsmith,
Thanks for coming back to me.
I did some digging myself and youâre absolutely right that the data is not shelled, and going down the EDDY route is not going to be suitable.
Instead I have moved over to QSIPrep and will be using MRTrix for the reconstruction portion of the process.
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âŚ
But:
That is indeed the problem.
But also:
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âŚ
Very thank you for your kind and clear explanation. This really help me much. Thank you~ I will try other ways and conntinue learn more about Mrtrix 3.
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.
