HCPpipelines icon indicating copy to clipboard operation
HCPpipelines copied to clipboard

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

Open mharms opened this issue 5 years ago • 4 comments

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 avatar Jun 05 '19 18:06 mharms

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).

mharms avatar Jun 05 '19 18:06 mharms

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 avatar Jun 05 '19 18:06 coalsont

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.

coalsont avatar Jun 05 '19 19:06 coalsont

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 avatar Jun 13 '19 22:06 mharms