New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mrview display issue with transform modified files #1439

Open
chrisadamsonmcri opened this Issue Aug 24, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@chrisadamsonmcri
Copy link

chrisadamsonmcri commented Aug 24, 2018

I use the transform modification method to register a T1 image to a DWI image. I usually can overlay the registered T1 over the DWI/FA image in mrview. In the latest mrview this doesnt work. I get the following error

mrview: [WARNING] voxel spacings inconsistent between NIFTI s-form and header field pixdim
mrview: [WARNING] qform and sform are inconsistent in NIfTI image "..." - using qform

Since the modification of the transform occurs in the sform this causes the image to not be aligned correctly.

This is more of a concern when using the transformed images as masks for tractography. But can you advise?

@jdtournier

This comment has been minimized.

Copy link
Member

jdtournier commented Aug 24, 2018

I knew this was going to happen... I assume you're not using MRtrix3 to modify the transform? All MRtrix3 commands should produce matching qform and sform...

In any case, the quick fix in your case will be to set this option in the config file.

You'll find extensive discussion on the rationale behind the switch to qform in #1212 and #1318. But this is something I'm very ambivalent about. If you have any thought, opinions or even hard facts about what to do when these don't match, please let us know!

@chrisadamsonmcri

This comment has been minimized.

Copy link
Author

chrisadamsonmcri commented Aug 24, 2018

@jdtournier

This comment has been minimized.

Copy link
Member

jdtournier commented Aug 24, 2018

OK, not what I was expecting... The only way I can see this happening would be due to a non-orthogonal transform - i.e. the transformation contains shears or scalings, rather than pure rigid-body transformations. Is this the case?

Either way, that config file entry should fix it. It does beg the question though as to whether defaulting to the qform is the right decision...

@chrisadamsonmcri

This comment has been minimized.

Copy link
Author

chrisadamsonmcri commented Aug 27, 2018

You are right it is a 12 DOF transform. I did this because it was a DWI -> T1 and I wanted to give the linear registration the best possible chance to register as possible. According to mrtrix, what would the "correct" solution be? Modify the pixel dimensions (pixdim) field to correspond to the dimensions of the transformed sform? Given that I know that these images have been modified for registration I will only use them for masking for tractography or overlaying onto DWI images. In other words I know that the dimensions of the voxels are different than in the original image. My main concern is that tckgen uses the transformations as it did before so that the images overlay in world space. I can confirm the registration worked correctly by registering and reslicing the T1s when transforming to DWI space but I don't want to reslice.

@chrisadamsonmcri

This comment has been minimized.

Copy link
Author

chrisadamsonmcri commented Aug 27, 2018

So I have found a workaround. Use the mif format for the transform modified file rather than nii. For what I need to do this does fix the issue.

@jdtournier

This comment has been minimized.

Copy link
Member

jdtournier commented Aug 27, 2018

Right, this all makes sense. You would have been fine using NIfTIs had it not been for our recent change to defaulting to the qform when there's an inconsistency between the qform & sform. Previously we'd default to the sform, which can store a full affine transformation. The qform on the other hand is explicitly rigid only, so can never be consistent with an non-rigid sform...

We had discussed whether to force the transform to be rigid in #1364, but left it as a warning (you should have seen that when loading the image in mrview...?). Given that non-rigid transforms are being used in the wild, this actually strongly suggests that the only sane thing to do is to switch back to the sform by default, since this otherwise constitutes a loss of information. Another option would be to leave the qform blank on write if we detect a non-rigid transform - not sure how well that would play with other packages though.

Also, looking through the relevant discussions again (particularly #1212), I'm still not convinced we've really got to the bottom of things... Mark Jenkinson's FAQ entry clearly suggest that the sform and qform should be allowed to differ - but the handedness of the coordinate system should not. This matches with what we see: FSL is tolerant of differences between the two, but aborts when qform_fac is not consistent. So our handling is still not consistent with FSL, it's quite a bit stricter, and if anything takes a narrower interpretation of the standard. However, I would argue that it's the only sensible interpretation, since either way, we still can't know which of the two entries should be used if there's a mismatch. But given the current issue, it strikes me that it would make sense to default to sform to prevent loss of information...

Thoughts, @MRtrix3/mrtrix3-devs...?

@chrisadamsonmcri

This comment has been minimized.

Copy link
Author

chrisadamsonmcri commented Aug 28, 2018

@jdtournier jdtournier added this to the 3.0_RC4 release milestone Jan 30, 2019

@jdtournier jdtournier self-assigned this Jan 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment