Skip to content
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

Changed behavior of applywarp, flirt, and bet in FSL 6.0+ #118

Open
mharms opened this issue Jun 5, 2019 · 4 comments
Open

Changed behavior of applywarp, flirt, and bet in FSL 6.0+ #118

mharms opened this issue Jun 5, 2019 · 4 comments

Comments

@mharms
Copy link
Contributor

mharms commented Jun 5, 2019

FSL 6.0+ apparently expects that the -r (reference) volume will be a single 3D volume in any call to applywarp within FSL 6.0+.
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1811&L=FSL&D=0&P=74472
To me this change in behavior should be considered a bug, but based on the list-serve response above, FSL doesn't appear to consider it to be a bug. So, we need to review all our applywarp calls across the entire code base, and ensure that the -r volume is a single 3D volume in all cases.

@mharms
Copy link
Contributor Author

mharms commented Jun 5, 2019

While we are at it, we should also make sure that all flirt calls have a single 3D volume as the -ref volume, since flirt from FSL 6.0+ abends if that isn't the case (another sneaky change, although at least in that case the processing fails to complete, rather than insidiously writing out some output that is different from what we've come to expect).

@coalsont
Copy link
Member

coalsont commented Jun 5, 2019

To me, that reads only as "here is a way to work around it", while not saying anything about whether or not they are inclined to make it behave as in fsl5. There is no useful unique data that can be put in the extra frames, and this would be a very weird and unexpected place/method to specify effectively a repmat (and can very easily break scripts written under fsl5, and I very much doubt they want to break people's scripts). This deserves followup with FSL, and could merit a bugfix release by itself.

@coalsont
Copy link
Member

coalsont commented Jun 5, 2019

flirt aborting when the reference isn't a single frame sounds like a very silly change, but less likely to be accidental. Maybe it was a quick hack to prevent the extra-frames behavior we see in applywarp without rewriting the resampling code to actually fix the issue?

We should get the whole story from the FSL people, and tell them what we think about the new behavior.

@mharms mharms changed the title Changed behavior of applywarp in FSL 6.0+ Changed behavior of applywarp and flirt in FSL 6.0+ Jun 5, 2019
@mharms
Copy link
Contributor Author

mharms commented Jun 13, 2019

A note regarding how the behavior of bet has changed as well in the context of multi-frame input files:

FSL5

  • You get a single frame output, (unless you use the -F option, in which case the derived mask gets applied to all frames).

  • If you use the -m flag, the resulting mask volume is a single 3D volume

FSL6

  • You get a multi-frame output, but the mask is only applied to the first frame

  • If you use the -m flag the mask volume is now a multi-frame output, with the first volume containing an actual mask, and the other volumes being all 0’s

@mharms mharms changed the title Changed behavior of applywarp and flirt in FSL 6.0+ Changed behavior of applywarp, flirt, and bet in FSL 6.0+ Jun 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants