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

NIfTI qform / sform handling #1210

Closed
Lestropie opened this Issue Dec 5, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@Lestropie
Copy link
Member

Lestropie commented Dec 5, 2017

Thinking aloud about recent updates to this forum thread.

Firstly:

I note that the NIfTI standard states relatively clearly that the qform should be the transformation to scanner coordinates, while the sform should be the transformation to some template space.

This to me suggests that we should be reading the qform by default if present, and only using sform if qform is invalid. It might be worth trying to backtrack and confirm why MRtrix3 was switched to using sform by default: It might have been due to some other issue that's since been rectified.

Secondly:

At NIfTI write, we're writing the same transformation to both qform and sform, since the Header class only stores one transformation. However we could use a similar trick to #970:

  • At image read, additional header fields within the image format are simply written as key-value parameters in text-readable format.

  • At image write, presence of these key-value entries is detected and used to fill the additional header fields within the image format.

This already works for additional 4x4 transformation matrices stored within the "header" (footer) in the MGZ format; so using the same technique for e.g. NIfTI qform would probably be not too difficult.

@Lestropie Lestropie added the question label Dec 5, 2017

@jdtournier

This comment has been minimized.

Copy link
Member

jdtournier commented Dec 5, 2017

OK, in short: no, I don't think our handling needs to be modified particularly. I'll expand:

  • regarding whether the sform or qform should be given priority, I can see how it might seem that way. If the qform only is set, there is no ambiguity (the idea is that this is what would be read directly from the scanner). If the sform only is set, this would be unexpected, given that the intention is for the qform to store the transform to scanner coordinates, so that kinda should always be set, but at least there's no ambiguity either. It's when both are set that you have to pick one. While the qform gives you the transform to scanner, if the sform is also present, it was presumably added subsequently, and for a good reason - so if you think about it, the chances are this is the transform that the users expects to be used, but the NIfTI standard doesn't provide a mechanism to determine for sure which is the right one to use under what circumstances. So our reading the sform preferentially is I think in keeping with the spirit of the standard, trying to make the best of an ambiguous situation.

Clearly, the FSL guys have also come to the conclusion that while this qform / sform business might have been devised with good intention, the practical reality is that no software has any idea which of these should be used under what circumstances - all it achieves is to introduce ambiguity, and leaves it to the user / application to figure out. The only real way of avoiding all this ambiguity is just to make sure the two pieces of information are always strictly equivalent - this is what MRtrix3 enforces in its output, and what the FSL now enforces also for its inputs (more stringent than us...).

That last point also makes it clear that any attempt at preserving potential differences between the sform and the qform is only going to result in further pain, since it'll just mean FSL applications are going to reject these images... Not much use for us or for our users, especially since we ourselves have no use for these two transforms - and clearly, neither do FSL...

@thijsdhollander

This comment has been minimized.

Copy link
Member

thijsdhollander commented Dec 5, 2017

Yeah, in short, I also fully agree with that. There is no "right" answer here indeed, and practicality is still the best argument, I reckon. The current solution in many ways is a case of Occam's razor. It's the simplest/cleanest solution that fits the somewhat ill-defined standard.

@Lestropie

This comment has been minimized.

Copy link
Member Author

Lestropie commented Dec 6, 2017

In that case, how about: At the NIfTI import stage, if both qform and sform are valid but they are not identical, issue a warning-level message about the ambiguity and advise that MRtrix3 is using the sform and the qform will be ignored?

@thijsdhollander

This comment has been minimized.

Copy link
Member

thijsdhollander commented Dec 6, 2017

That definitely sounds reasonable. Maybe, additionally, an FAQ entry in the user documentation would be good as well, just to elaborate a bit on this issue. Those kind of things always come in handy to refer to on the forum, for issues like this that pop up every once in a while again.

jdtournier added a commit that referenced this issue Dec 7, 2017

@Lestropie

This comment has been minimized.

Copy link
Member Author

Lestropie commented May 11, 2018

Closed by #1212.

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