[ERROR]: Not classified into shells

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:

dwifslpreproc sub-OAS30141_dwi_den.mif sub-OAS30141_dwi_den_preproc.mif -nocleanup -rpe_none -pe_dir j- -eddy_options "--slm=linear --data_is_shelled"

I recieve the following error:

[ERROR] DWI volumes could not be classified into b-value shells; gradient encoding may not represent a HARDI sequence

This the values from my .bval file:

0 50 350 600 900 1150 100 400 650 950 150 450 700 1000 1300 200 500 800 1050 1350 300 850 1100 1400

Any clues on how to fix this?

Many Thanks,
Christopher Fleetwood

Welcome Christopher!

Could you please try re-running, but simply inserting a seemingly pointless space in between the opening double-quote and “--slm”?

So it would be:

dwifslpreproc sub-OAS30141_dwi_den.mif sub-OAS30141_dwi_den_preproc.mif -nocleanup -rpe_none -pe_dir j- -eddy_options " --slm=linear --data_is_shelled"

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.


1 Like

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.

Many Thanks,
Christopher Fleetwood

1 Like

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.

Hi Michael,

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

  1. mrconvert data.nii.gz -fslgrad dtiraw.bvec dtiraw.bval data.mif
  2. dwi2response tournier data.mif wm_response.txt
  3. dwi2fod data.mif wm_response.txt fod.mif
  4. tckgen fod.mif track_roi.tck -include 1_mask.nii 2_mask.nii
  5. tckstats track_roi.tck
  6. tcksample track_roi1.tck FA.nii.gz FA_roi1.txt -stat_tck mean
  7. tcksample track_roi1.tck MD.nii.gz MD_roi1.txt -stat_tck mean

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.

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.

Hi all,

I should clarify an initial mistake on my part:

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.

Thank you for your supplement.