search

WinawerLab / MRI_tools

Matlab and Python tools for MRI analyses
GNU General Public License v3.0
3 stars 3 forks source link

FSL v6.0.0 compatibility? #4

Open billbrod opened 5 years ago

billbrod commented 5 years ago

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

screenshot from 2019-01-14 13-21-40

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:

screenshot from 2019-01-14 13-24-55

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 commented 5 years ago

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

sfavila commented 5 years ago

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 commented 5 years ago

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.