FSL v6.0.0 compatibility?

[billbrod]

I tried running the pipeline with a new install of FSL, which I assume means it installed the newest version, v6.0.0 (I cannot figure out how to check that). I ran into a weird issue in the reg2distort step (picture attached).

When I investigated, going to the working directory and trying to run the command directly, I found it was a flirt command: flirt -in sub-wlsubj001/ses-02/func/sub-wlsubj001_ses-02_task-sfpconstant_run-01_sbref.nii -ref sub-wlsubj001/ses-02/fmap/sub-wlsubj001_ses-02_dir-PA.nii -out sberf_reg.nii.gz -omat sbref2dist.mat -dof 6. Running the command directly (adding the verbose flag to try and get more details) gives the following error:

I then went and checked, and the sbref file is 3D. The reference file is 4D, but I don't think that's the issue? I'm able to run this on the cluster using FSL v5.0.10 without an issue, has anyone else had something like this happen / is anyone using FSL v6.0.0?

[billbrod]

Just checked and it looks like downgrading to v5.0.10 fixes the issue.

[sfavila]

Hmm, I don't see anything about this in the release notes, but I'm guessing it's the same issue as this. Previous default behavior was to grab the first volume of a 4D image, but that's no longer true.

I confirmed that on v5.0.10, passing the whole 4D distortion scan as the reference produces the same output as passing only the first volume of it. I think adding one more node to the workflow and passing only the first volume explicitly should work for v6. Could also add some more complexity and motion correct and average the 3 volumes in the distortion scan, though that would produce slightly different output than in past versions.

[billbrod]

Ah good catch, that's probably it. I guess we should decide, as a lab, which of those two choices we would like better: just taking the first volume or doing the motion correct + average of the three volumes. I don't have a preference, and both would be relatively straightforward to implement.