The main issue is hinted at here:
dwipreproc needs to know what diffusion encoding was used to acquire the data, and this information can’t be included within the NIfTI images themselves. So you need to provide the bvecs/bvals info separately using the -fslgrad option (assuming I’ve got the names right - amend as required):
dwipreproc -rpe_none 2 HARDI193.nii.gz test.nii -fslgrad HARDI193.bvector HARDI193.bvalue
But that’s not all: you will also want to get the corrected bvecs after motion correction. Since your output image is in NIfTI format, this information won’t be provided in the output image either. To get these, you need to add the -export_grad_fsl option:
dwipreproc -rpe_none 2 HARDI193.nii.gz test.nii -fslgrad HARDI193.bvector HARDI193.bvalue -export_grad_fsl HARDI193_corrected.bvector HARDI193_corrected.bvalue
As you can see, this makes for some rather cumbersome command lines… This is one of the (many) reasons we recommend you use MRtrix3’s own .mif format, which does store this information in the image header. The above would then be accomplished by first converting your input data to .mif (or .mif.gz if you’re tight on storage) with the diffusion gradient table included:
mrconvert -fslgrad HARDI193.bvector HARDI193.bvalue HARDI193.nii.gz HARDI193.mif
which then makes for a much cleaner dwipreproc command:
dwipreproc -rpe_none 2 HARDI193.mif test.mif
Note that this produces another .mif image, which will include the corrected gradient table after motion correction. If you really want to produce a NIfTI image, you’ll still need to use the -export_grad_fsl option.
One final note: are you sure your PE direction should be 2? That corresponds to the z (inferior-superior) axis, which is quite unusual. It’s more common for it to be along y (anterior-posterior) axis, in which case you’d want a 1 here.