mrview display issue with transform modified files

[chrisadamsonmcri]

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]

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]

Im using mrtransform to modify the transforms. I used flirt to perform the registration and transformconvert to change to mrtrix format so iam using mrtrix tools. I can verify that the registration works by reslicing rather than just transform modification. So it does work. If it is purely a display issue thenill just modify the option you mentioned.

Sent from my Samsung GALAXY S5 on the Telstra Mobile Network

-------- Original message -------- From: J-Donald Tournier notifications@github.com Date: 25/08/2018 12:21 AM (GMT+10:00) To: MRtrix3/mrtrix3 mrtrix3@noreply.github.com Cc: Chris Adamson chris.adamson@mcri.edu.au, Author author@noreply.github.com Subject: Re: [MRtrix3/mrtrix3] mrview display issue with transform modified files (#1439)

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 filehttps://mrtrix.readthedocs.io/en/latest/reference/config_file_options.html#cmdoption-arg-niftiusesform.

You'll find extensive discussion on the rationale behind the switch to qform in #1212https://github.com/MRtrix3/mrtrix3/pull/1212 and #1318https://github.com/MRtrix3/mrtrix3/issues/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!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/MRtrix3/mrtrix3/issues/1439#issuecomment-415773598, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AI2NVbMXmTU2OHamMhHaICec2pmJC73sks5uUAvKgaJpZM4WKt1s.

Disclaimer

This e-mail and any attachments to it (the "Communication") are, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Murdoch Children’s Research Institute (MCRI) ABN 21 006 566 972 or any of its related entities. MCRI does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.

[jdtournier]

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]

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]

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]

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]

What you said makes sense too. The way that I have seen the two transforms used in the wild is that the sform is preferred when set over the qform since the qform only applies to scanner space and, as you point out, should be a rigid body only. But scanner space isn’t really useful since the sform represents a transformation to some standard space or to the space of another image (which is what I’m talking about here). The issue is that the pixel dimensions differ from the original image due to scaling. It is kind of up to you whether your program accepts that or not, i.e. whether you treat it as a “corrupted” transform. But I guess the way that I see it is that the sform doesn’t necessarily need to match voxel dimensions in world space compared to the voxel dimensions in the actual image since this is a “transformation” of the image to another space. So the situation of having the original pixel dimensions and the original qform producing corresponding spacing in world space makes sense as well as saying that the sform requires a scaling to transform to “standard” space makes sense. So in other words, in native space the image has dimensions and spacings given by pixdim and qform, but in STANDARD or transformed space the dimensions are derived from the sform. It is more likely that someone performing analysis would want the sform, if set, compared to the qform. If they want to use the qform space then either they would set sform = qform or sform_code = 0. Anyway, that is how I see it and how I’ve seen it used in the wild in other packages.

I’m curious as to why mrview doesn’t complain when there is a scaled transfom in the mif format images?