I’m facing a problem running fslpreproc, both in Mac OS or Linux. The same error:
(base) eduardo@eduardo-X555UB:~/DWIPaper2020/MRtrix3/mrtrix3_preprocess$ dwifslpreproc dwi_den_unr.mif dwi_den_unr_preproc.mif -pe_dir AP -rpe_pair -se_epi mean_b0.mif -eddy_options " --slm=lienar"
dwifslpreproc:
dwifslpreproc: Note that this script makes use of commands / algorithms that have relevant articles for citation; INCLUDING FROM EXTERNAL SOFTWARE PACKAGES. Please consult the help page (-help option) for more information.
dwifslpreproc:
dwifslpreproc: Generated scratch directory: /home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/dwifslpreproc-tmp-9LSZGK/
Command: mrconvert /home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/dwi_den_unr.mif /home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/dwifslpreproc-tmp-9LSZGK/dwi.mif -json_export /home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/dwifslpreproc-tmp-9LSZGK/dwi.json
Command: mrconvert /home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/mean_b0.mif /home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/dwifslpreproc-tmp-9LSZGK/se_epi.mif
dwifslpreproc: Changing to scratch directory (/home/eduardo/DWIPaper2020/MRtrix3/mrtrix3_preprocess/dwifslpreproc-tmp-9LSZGK/)
dwifslpreproc: [ERROR] Unhandled Python exception:
dwifslpreproc: [ERROR] IndexError: list index out of range
dwifslpreproc: [ERROR] Traceback:
dwifslpreproc: [ERROR] /home/eduardo/mrtrix3/bin/dwifslpreproc:378 (in execute())
dwifslpreproc: [ERROR] se_epi_num_volumes = se_epi_header.size()[3]
I kept going with the BATMAN tutorial without motion correction. Running dwi2response I have verified the following error in the error.txt file of the folder dwifslpreproc-tmp-9LSZGK:
“Unable to construct A2SH transformation for shell b=1000;”
“lmax (10) may be too large for this shell”
I also verified an error message, in some step that I don’t remember, that the dwi.mif image and the b0.mif image have different volumes (34 e 33).
It looks like the DW encoding table is not the same size as the number of volumes. You can verify this using:
mrinfo dwi_den_unr_preproc.mif
and checking whether the number of volumes matches the number of entries in the dw_scheme.
Assuming that’s the problem, we’d need to figure why that happened, and for that, we’d need to see all the commands that were run to get to that point. Could you post those commands exactly as you ran them?
While I don’t like leaving unhandled Python exceptions lying around, it is nevertheless indicative of erroneous usage in this case. Use of the -rpe_pair option necessitates that the image series provided via the -se_epi option contain an even number of volumes, so that the phase encoding of those volumes can be inferred from the command-line usage. But the fact that this particular error is generated means that the image you have provided via the -se_epi option is a 3D image, which by definition does not contain an even number of volumes.
If you truly have a single image volume that is to be used in conjunction with the input DWI b=0 volumes, this can be done, but it necessitates:
Using -rpe_header (and having the phase encoding information encoded in the input image headers);
Using the -align_seepi option.
But the fact that you usage is: -se_epi mean_b0.mif
suggests that you’re combining multiple image volumes into one before running dwifslpreproc. It’s preferable (though takes longer to execute) if topup is instead provided with the original volumes, as this allows it to additionally estimate the motion between those volumes and the way that motion affects the manifestation of the inhomogeneity field in those images.
“Unable to construct A2SH transformation for shell b=1000;”
“lmax (10) may be too large for this shell”
The only way I can see this being generated is if you have fewer than six unique diffusion sensitisation directions in your b=1000 shell, which would exclude even a tensor model fit. While we can’t see your complete diffusion gradient table in the default mrinfo output (try mrinfo -dwgrad), my best guess is that you either have some number of repeats of the same set of directions, which is far from ideal, or your directions are arranged in such a way that many directions have equivalent elevation angle from the xy plane.
In retrospect this particular check is actually too severe, and is likely a remnant of the initial construction of the method within the amp2response command. It fails to take into account that if the estimated fibre orientation in a voxel is not along the Z-direction, then the transformation may be better-posed than it would be if the fibre orientation were exactly along the Z-direction. Indeed it even mis-reports the issue, as it’s the A2ZSH transformation, not the A2SH transformation, that is invalid. So ideally it would be a little more permissive and only exclude those particular voxels where the transformation is ill-posed. But it’s likely nevertheless flagging a non-ideal acquisition strategy that’s worth looking into.