I have encountered an error in my analysis that has started happening half way through my patient cohort. Part of the way through the 5ttgen fsl script this error occurs and I don’t know how to get around it:
[ERROR] Unable to find FSL output file for path “first_all_none_firstseg”
There have been no updates to any of the software to my knowledge in this intervening time. I am currently stuck as I can’t produce any more 5ttgen maps for my analysis and was wondering if anybody had a solution.
FSL’s FIRST tool is genuinely failing for some of your subjects. Unfortunately
5ttgen fsl is producing an intermediate error regarding one of the internal library functions, rather than providing the error it was intended to (see code here); however fundamentally the issue is that the
run_first_all script is failing, and hence
5ttgen fsl cannot proceed.
While I have implemented improvements to the Python library regarding how the outcomes of the
run_first_all script are assessed & reported to users, and hope to push this to users, I cannot provide support on the underlying operation of FSL commands themselves. Unless by chance your failure is being caused by unnecessary image down-sampling.
Jan / anybody else who has had issues with
5ttgen fsl or
labelsgmfix (I know there’s plenty of you out there),
I’ve now merged an update to the MRtrix3 master branch that alters how these scripts assess the outcomes of the FSL
run_first_all script and report any issues back to the user. It should also negate the necessity to disable SGE. While it can’t prevent overall failure of the script if FIRST is genuinely unable to segment one or more structures, I’m hoping that this new solution will be more robust and provide more meaningful feedback. So any independent testing of these changes with problematic data would be very much appreciated.
Note that updating MRtrix3 via the master branch will not alter the outcome of any command, unless the existing outcome is considered egregious. Any changes to MRtrix3 that alter outcomes that may otherwise be considered reasonable are reserved for a tagged update, with associated announcement about those changes. Therefore, updating MRtrix3 on the
master branch can be done without fear of altering experimental outcomes.
Thanks so much for your rapid response. I have now solved my particular problem.
In my case I was mistakenly using skull-stripped T1-weighted images for the 5ttgen image creation which was never going to work. It now makes sense now that I know that the FIRST algorithm was failing.
I am regularly using skull-stripped T1 images (from FreeSurfer) for
5ttgen without any problem. In that case
-premasked option has to be specified. I consider avoiding
bet (which is run as part of
5ttgen when using not skull-stripped image) even beneficial due to the common difficulties with accuracy of
bet on T1 structural images.