Dwipreproc error: Inconsistent left-right order stored in sform and qform

1

Hi MRTrix experts,

Using the latest git pull build of MRTrix3, I am running into an error.

Command run:

Error message:

[code]ERROR: Inconsistent left-right order stored in sform and qform in file dwi_pre_topup
Using sform instead of qform values

Image Exception : #40 :: ERROR:: Illegal NIfTI file! Inconsistent sform and qform information set in dwi_pre_topup.nii
terminate called after throwing an instance of 'RBD_COMMON::BaseException’
Aborted
dwipreproc: [ERROR] Command failed: eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy[/code]

I don’t know what this error means. Any help would be greatly appreciated!

P.S> The step prior to this was run using:

2

Doesn’t sound good… I’m worried some of the changes I made recently might be to blame, but I really can’t see how… Can you tell what mrconvert -version reports? Just so I can check exactly what version you’ve got…

3

mrconvert -version shows == mrconvert 0.3.14-35-g37587663 == 64 bit release version, built Apr 22 2016, using Eigen 3.2.0

4

Right, so that is right up to date. I’ve no idea why the NIfTI output would be affected by any recent changes… Which version of FSL is this? Let me have a look into our NIfTI handling, just to make sure it’s OK.

5

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
$ ./build

Then run your dwipreproc again.

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
$ ./build

Thanks for reporting this!

6

Sorry for the delayed response!

The FSL version I have is 5.0.9-2~nd14.04+1 and I also have the fsl-eddy package installed which is version 5.0.9-1~nd14.04+1. I don’t know if the mismatch between the fsl core and fsl-eddy versions could be the culprit.

Testing out the fix_nifti_qform branch, dwipreproc on the DWI dicoms folder results in error:

Image Exception : #40 :: ERROR:: Illegal NIfTI file! Inconsistent sform and qform information set in dwi_pre_topup.nii terminate called after throwing an instance of 'RBD_COMMON::BaseException' Aborted dwipreproc: [ERROR] Command failed: eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy

which looks like the same error.

Hope this helps! =)

7

I’m really stumped that this didn’t work… No idea what’s going on then. Just to check, what does mrconvert -version report? It should end with -ge47c108 or -g7547d47 if it’s the right version… I’m just concerned that there might be some other version hanging around in your PATH that’s being used instead of the freshly compiled version from that fix_nifti_qform branch…

Otherwise, I really won’t have time to look into this until after the ISMRM - maybe one of the others can figure it out, but currently no-one has reported being able to reproduce this. Maybe one of the other devs has a 14.04 with the latest FSL version from neurodebian installed, and can look into this quickly…? :wink:

8

I know nothing. :grin: …but sadly, I’m also wa(aaa)y overbooked until ISMRM. But from my point of view: I was unable to reproduce or otherwise run into the issue described… both master and the fix_nifti_qform run fine for me using the dwipreproc script…

9

Hey everyone,

Thanks for your assistance. Was I supposed to change my PATH to reflect the fix_nifti_qform branch, or do I leave it unchanged from before? I had the latest MRTrix3 build (but that was a few days ago, you guys update so quickly).

The mrconvert -version from the _qform branch gave me -ge47c1084, and still does return that illegal nifti file error.

I won’t be able to get to fully analyzing the DWI data until June anyway, so this isn’t too pressing yet. I mean, I could probably figure out what to do using FSL but I like the simplicity and speed of MRTrix!

10

Assuming you had the PATH set to MRtrix3’s release/bin/ folder, then you wouldn’t have needed to change it. Regardless, the version checks out, so I’m really confused… Any chance you could send me that offending dwi_pre_topup.nii image…? I notice you’ve set your tempdir, so presumably you still have it…?

One more thought: @rsmith, is there any chance your dwipreproc script might have carried on from where it left off if supplied with an existing tempdir…? In which case, the problematic nifti file wouldn’t actually have been updated…

11

The -tempdir option only specifies the location within which a new temporary directory will be created. It doesn’t retain the temporary directory contents following failure or completion (that’s -nocleanup), nor does it look for existing processed data from a prior execution of the script (that’s -continue).

@Ye_Yuan If you can let us know the strides of the NIfTI image being input to the dwipreproc script, it will hopefully be possible for us to recreate the fault without having to re-run the entire dwipreproc script each time we want to test a proposed fix.

12

Hi Robert,

Please forgive my ignorance here, I don’t quite know about nifti strides, but the terminal is saying the command is using -1,+2,+3,+4. I have not set this explicitly, so I assume it was automatically detected. I ran the dwipreproc again with -nocleanup so I can preserve the dwi_pre_topup.nii. How do I attach that?

Thanks!

13

There is no way to attach such a large file on this forum, the best thing is to upload to e.g. Dropbox or Google drive, and send us the link privately - there is a facility for private messaging on this forum.

@rsmith: thanks for clarifying re cleanup and continue. As to the strides, given that the last run was direct from DICOM, they would almost certainly be -1,-2,+3,+4. But I don’t see that making a difference, the script requests strides -1,2,3,4, so at that point the strides are known, and what it’s complaining about is a mismatch within the same NIfTI file. That seems to work fine with the fix at my end…

14

I have attached the file here. Thanks in advance!

15

Thanks @Ye_Yuan. I’ve just had a look at the file, and there is indeed an issue in that file’s qform. However, I cannot reproduce this particular problem when using the fix_nifti_qform branch,

I put this through the ringer by feeding mrconvert lots of images with all sorts of strides, and getting mrconvert to produce NIfTI images with all sorts of strides. This highlighted a couple of other minor bugs, but these are unlikely to be the problem. These are now fixed in this branch, and check out fine in fslhd for all these different combinations of strides.

There is a faint chance that the latest commits on that branch will fix things, but somehow I don’t think this was the problem. With the strides in that image, the previous fixes should have worked out just fine. I really have no idea why the image fed to EDDY would be inconsistent like this - are you absolutely sure that there is only one version of MRtrix3 installed, and that this is the one the dwipreproc script is using…? The image you sent looks like it would have been generated without the changes on this branch…

16

Thanks for the feedback Donald. I decided to just delete my mrtrix3 folder and recompile from scratch. The error persists! My mrview -version is == mrview 0.3.14-43-gedb5eae9 == 64 bit release version, built Apr 28 2016, using Eigen 3.2.0

Error:

[code]ERROR: Inconsistent left-right order stored in sform and qform in file dwi_pre_topup
Using sform instead of qform values

Image Exception : #40 :: ERROR:: Illegal NIfTI file! Inconsistent sform and qform information set in dwi_pre_topup.nii
terminate called after throwing an instance of 'RBD_COMMON::BaseException’
Aborted
dwipreproc: [ERROR] Command failed: eddy --imain=dwi_pre_topup.nii --mask=mask.nii --index=indices.txt --acqp=config.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy
[/code]

I have also uploaded the new offending dwi_pre_topup.nii.

This time, when I try git fetch, nothing shows up. I do not see the fix_nifti_qform branch at all.

I do have an older mrtrix2 installation still residing, but I’ve renamed that folder to something else just in case any PATH assignments still point to it. Not sure if this might contribute to the current issue.

Thanks again for your (extremely fast) response times!

17

You are using the current master branch. Try

then you should see the fix_nifti_qform branch with git branch -a as remotes/origin/fix_nifti_qform. You can check this branch out via

and then build it via

Cheers,
Max

18

I do not see the fix_nifti_qform. All I see is origin/doctest…

19

I don’t know why you only see one branch but you could also download the branch as a zip archive.

20

This is really strange… I just tried with a fresh clone on my system:

donald@donald-laptop:~ $ git clone https://github.com/MRtrix3/mrtrix3.git mrtrix3_test
Cloning into 'mrtrix3_test'...
remote: Counting objects: 39398, done.
remote: Compressing objects: 100% (215/215), done.
remote: Total 39398 (delta 88), reused 0 (delta 0), pack-reused 39183
Receiving objects: 100% (39398/39398), 16.74 MiB | 275.00 KiB/s, done.
Resolving deltas: 100% (30361/30361), done.
Checking connectivity... done.
donald@donald-laptop:~ $ cd mrtrix3_test/
donald@donald-laptop:~/mrtrix3_test [master]$ git branch -avv
* master                                             edb5eae [origin/master] Merge pull request #577 from MRtrix3/dwipreproc_rpeall_fix
  remotes/origin/HEAD                                -> origin/master
  remotes/origin/bvec_rotation                       037d695 Delete file scripts/lib/getPEAxis.py
  remotes/origin/clls                                9a57d52 Merge pull request #541 from MRtrix3/build_fix_icons
  remotes/origin/connectome_no_config                0b6f067 labelsgmfix: Update for compatibility with connectome_no_config branch
  remotes/origin/doctest                             ff65d6c Docs: Troubleshooting for compiler running out of RAM
  remotes/origin/fix_alignment_for_transform_type    a925097 Make sure any class containing a transform_type also uses EIGEN_MAKE_ALIGNED_OPERATOR_NEW
  remotes/origin/fix_nifti_qform                     9f97126 more fixes to the NIfTI qform handling
  remotes/origin/master                              edb5eae Merge pull request #577 from MRtrix3/dwipreproc_rpeall_fix
  remotes/origin/mrtransform_datatype_fix            02a3b0e mrtranform: default output datatype is now float
  remotes/origin/mrview_odf_preview_fix              23d3ad1 mrview ODF tool: Update preview on DW shell change
  remotes/origin/mrview_tractography_overlay_colours 1251a27 mrview Tractography tool: Re-arrange UI
  remotes/origin/multithreaded_progressbar           a3ea100 First attempt at connectome tool multi-threaded progress dialog
  remotes/origin/registration                        d059d31 small change to population template to allow -continue to work
  remotes/origin/retina_display                      4e75a55 MRView: groundwork to support hiDPI font rendering
  remotes/origin/scalar_thresh_hotfix                895d3df Quick fix to enable Tractography tool to specify separate scalar files for Intensity and Thresholding
  remotes/origin/tcksample                           9cc6790 Unsaved help page and comment changes left out of previous commit
  remotes/origin/thread_local_osx                    00a5229 Try alternative for thread_local support in OS X as mentioned in #342, but does not compile on Xcode clang.
  remotes/origin/tractography_mesh                   ca2a6ef Mesh-based connectome: cleaning codes
donald@donald-laptop:~/mrtrix3_test [master]$ git checkout fix_nifti_qform 
Branch fix_nifti_qform set up to track remote branch fix_nifti_qform from origin.
Switched to a new branch 'fix_nifti_qform'

Not sure why this wouldn’t work at your end… :confused: