OK, there was indeed an issue with the qform produced when
qfac is negative - not a common occurrence, but the recent changes in
dwipreproc related to the FSL bvecs issue do bring out the bug. Unfortunately, this has been a problem since the big update recently on March 12.
Thankfully, this would rarely affect users, since the handling within MRtrix3 remained internally consistent. NIfTI import was not affected, only the export from MRtrix3 - and this would only manifest when
qfac is negative (LHS coordinate system - not the default), and when feeding into 3rd party packages such as FSL, and if the other package reads the qform in preference to the sform (MRtrix3 defaults to the sform).
On the other hand, I’m stumped as to why this hasn’t been picked up in our internal testing, we’ve been running these scripts through their paces quite a bit over the last few weeks, I don’t understand why no-one’s version of FSL has produced anything resembling this particular error message. Which version of FSL are you running, exactly?
In any case, I’ve just pushed changes to address this, which seem to fix the issue as far as I can tell. Verified using
fslhd (from FSL 5.0.9), everything seems consistent. Do you mind pulling the
fix_nifti_qform branch, to check whether this does indeed fix it? Instructions are:
$ git fetch
$ git checkout fix_nifti_qform
Then run your
By the way, your initial
mrconvert call should be unaffected by this, the issue occurred within the
dwipreproc script itself. No need to rerun your DICOM import. Actually, there’s probably no need to run the DICOM import at all, I’m pretty sure
dwipreproc will work just as well if you just pass the DICOM folder as-is, i.e.:
$ dwipreproc -rpe_none -tempdir ./ -export_grad_fsl bvecs bvals AP DWI dwi.nii.gz
To revert back to the master branch when you’re done testing:
$ git checkout master
Thanks for reporting this!