I am re-processing diffusion data with MRtrix version 3.0.0 (but also tried version 3.0.1) to make use of the advances in dwidenoise.
For some of my subjects, when using dwidenoise with dwi.nii.gz as input, I receive a warning “dwi_output.nii.gz contains non-rigid information - qform will not be stored”. This leads to misalignment and other problems later in my pipeline, when using FSL and other tools. Interestingly, I do not get this problem in all my subjects and did not encounter this problem when using the MRtrix3/RC3-68 version. I thought I could prevent it by using the mif format as input for dwidenoise, but I do need the NIfTI format at a later stage and when going back from .mif to .nii.gz using mrconvert, I encounter the same error “[…].nii.gz contains non-rigid information - qform will not be stored”.
In case it helps, the output of fslhd dwi.nii.gz gives me the following:
This is due to changes we made to try to handle non-rigid affine transformations gracefully. Such transformations can be represented with the NIfTI s-form, but not the q-form (it can only represent rigid-body transformations). As part of that, we try to detect when the s-form contains a significant non-rigid component – and clearly that test may in some cases be too stringent…
I assume the data you’re talking about have been converted straight from DICOM? If that’s the case, then I think we’ll need to reduce our tolerance values for that test. In the meantime, you could try less stringent thresholds for the test on this line, e.g. use 1e-4 instead of 1e-6 (simply edit the file core/file/nifti_utils.cpp, line 518, save, and type ./build again). It would be great if you could confirm whether or not that worked so we can update the code for the next release.
You are right, the data have been converted straight from DICOM (using dcmstack).
I tried 1e-4 instead of 1e-6 and proceeded as you suggested, thank you! For some of my subjects, this worked, but for others this did not do the trick. Even 1e-2 is too stringent in some cases.
What would in your opinion be the lowest threshold that I could go for?
OK. I would have considered 1e-4 to be kind of acceptable, given that the DICOM standard can be a bit loose with precision. But for the transformation to fail to pass a test as loose as 1e-2 is frankly worrying. There’s something else going on here…
I’ve not heard of dcmstack, but the first thing I would do is verify whether your sequence would be expected to produce non-orthogonal slice stacks – i.e. with slices that aren’t stacked directly on top of one another, but offset in some way (i.e. like a sheared deck of cards). I would personally find that very unusual, but it’s a possibility.
Assuming that’s not the case, can you try converting your most problematic images using mrconvert directly, and check whether that produces NIfTIs that include the qform, and whether the images display in their expected location in mrview. If it all checks out, that doesn’t mean that mrconvert got it right and dcmstack didn’t – it could well be that there is a slight angle to the stack away from the expected normal to the slice, and that MRtrix effectively ignores that (since we compute the slice normal based on the cross-product of the row & column vectors, effectively assuming that the slice stack is orthogonal). I’d need access to the data to verify exactly what’s going on…
I have also recently been getting these errors in my pipelines. We changed the preprocessing steps, which includes a new DICOM to NIfTI converter - so based on this discussion I am guessing that’s the source of the problem.
Honestly I have been ignoring this error… and haven’t been noticing anything downstream in my prob track connectome pipelines. But now I am more worried (probably always should have been). So what should I check to see if this caused a significant problem?
OK, it’s difficult to say whether there’s a problem without checking the raw data to see what the actual answer should be. If you really want to get to the bottom of this, I’d encourage you to run the following command on your raw DICOM folder. Amend that FOLDER variable to point to the right folder – preferably the dataset with the worst mismatch:
FOLDER=dicom/; for n in "$FOLDER"/*; do dcminfo -a "$n" 2>/dev/null; done | grep '\(Orientation\|ImagePosition\)' > pos.txt
This will produce a file pos.txt with all the information that would normally be used to figure out the orientation of the data. If you could post or attach this information back here, I can take a quick look and try to figure out what’s going on.
Note that for this to run correctly, you’ll also need to make sure that folder only contains the single series of interest. In other words, running:
mrinfo $FOLDER
should report back immediately, without you needing to select the image series – otherwise the file produced above will contain information from a mix of different series, which would make things difficult to figure out…
Ahem. @rsmith has just pointed out that there probably is a bug right at the point that check is performed (all entirely my fault ). Could you try changing this line (core/file/nifti_utils.cpp:516) to
Q.coeffs() = -Q.coeffs();
then ./builld again and see if that fixes it – preferably using the original threshold of 1e-6?
I just tried with the suggested change (but original threshold of 1e-6) on multiple subjects of two different studies and did not receive the warning anymore, plus the qform was accurately saved. This fixed the problem - thank you!!
Just to come back to this point: the only effect of this bug was that the qform was not written to the NIfTI images. The sform is unaffected, and all MRtrix3 applications will use that if present anyway. So this should only affect 3rd party tools that rely on the presence of the qform, and don’t take the sform into account.
I’m surprised this would cause issues with FSL, but it’s possible some of their tools rely on the qform exclusively. My apologies if that’s caused issues in your analyses…
Ok, so I was getting the error converting my DWI and T1 NIFTIs to .mif using mrconvert. Then I would register T1 to DWI using MRTrix3 commands.
Then I use MRTrix3 commands like 5ttgen, labelsgmfix… etc. that rely on third party tools, but keep everything as a .mif.
So do you think I need to re-run all my pipelines? I know you’d need the original data to officially say, but it’s non-trivial to do so at this time so I’m just asking for your initial opinion All of the registrations visually appear correct, so I’m guessing this didn’t have any effect, but if it’s subtle then I easily could have missed it.
From what you say, the ROBEX part should be OK since you register to the DWI after that. In general, I’d expect that if any stage relied on the qform, it would be very unlikely for the transform information to somehow match the sform, and so I’d expect you would see fairly obvious misalignment issues at that point, at least on some of the subjects.
As you say, it’s commands that rely on 3rd party tools that I’d be worried about, including dwifslpreproc, 5ttgen, and dwibiascorrect. I’m guessing the exact version of the 3rd party tools is also likely to make a difference here, but I’m not sure. But in any case, the above applies: if the sform was completely ignored and the qform was simply not there, that should result in some misalignment for at least some of the subjects…
What you could do is check the different stages of the pipeline with mrinfo -transform, which should show up even subtle differences. If it all checks out, I think that’s pretty compelling evidence that there’s no need to re-run anything.
Sounds good - thanks for the info! I’ll do some digging.
Any idea on the timeline for when this will be incorporated in a release? Asking because I install MRTrix3 during singularity image builds and would be nice not to have to do a custom mod in my recipe files
). Could you try changing 
All of the registrations visually appear correct, so I’m guessing this didn’t have any effect, but if it’s subtle then I easily could have missed it.