I am trying to follow the ISMRM tutorial to create a tissue-segmented image using the Human Connectome data. However, the first step 5ttgen fsl stuck at run_first_all command and gave me an error message below:
yukai@yukai-Oryx-Pro:~/HCP/20180121_MRtrix3/test_5ttgen$ 5ttgen fsl T1w_acpc_dc_restore_brain.nii.gz 5TT.mif -premasked
5ttgen:
5ttgen: Note that this script makes use of commands / algorithms that have relevant articles for citation; INCLUDING FROM EXTERNAL SOFTWARE PACKAGES. Please consult the help page (-help option) for more information.
5ttgen:
5ttgen: Generated temporary directory: /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/
Command: mrconvert /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/T1w_acpc_dc_restore_brain.nii.gz /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/input.mif
5ttgen: Changing to temporary directory (/home/yukai/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/)
Command: mrconvert input.mif T1.nii -stride -1,+2,+3
Command: fast T1.nii
**Command: run_first_all -m none -s L_Accu,R_Accu,L_Caud,R_Caud,L_Pall,R_Pall,L_Puta,R_Puta,L_Thal,R_Thal -i T1.nii -o first -b
**5ttgen: [ERROR] FSL FIRST has failed; only 0 of 10 structures were segmented successfully (check /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/first.logs)
5ttgen: Changing back to original directory (/home/yukai/HCP/20180121_MRtrix3/test_5ttgen)
5ttgen: Contents of temporary directory kept, location: /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/
As a result, no 5TT.mif file was generated. I checked the *first.logs and found the following files:
I’ve checked that the segmentation failure was not an issue of running out of RAM. I read through the posts of this topic on the forum but haven’t found a solution yet. I am wondering if anybody has a solution.
BTW, my operating system is Ubuntu 16.04 LTS. The FSL version is 5.0.9, and the Freesurfer version is freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c.
You will need to check the contents of the files within that directory to determine what went wrong with the run_first_all script (they’re all text files, containing the standard output and standard error contents from each registration / segmentation / processing job).
mrconvert /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/T1w_acpc_dc_restore_brain.nii.gz /home/yukai/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/input.mif
mrconvert input.mif T1.nii -stride -1,+2,+3
fast T1.nii
run_first_all -m none -s L_Accu,R_Accu,L_Caud,R_Caud,L_Pall,R_Pall,L_Puta,R_Puta,L_Thal,R_Thal -i T1.nii -o first -b
There is no standard error contents in it. I continued checking the contents of the other files (first.com, first.com2, first.com3) and did not found standard error contents either.
The “first.com*” files contain the FSL commands that are executed via the SGE jobs. These don’t provide any information regarding the outcomes of those commands.
The standard error and standard output contents of each job are written to files “first*.logs/first.e*.*” and “first.logs/first*.o*.*” respectively. If each FSL job encounters some sort of error (most likely the “first_flirt.*” job, since a failure at the FIRST step will result in failure of all subsequent jobs that depend on it), this is where that information will appear. Therefore these are the files for which the contents are important.
File “log.txt” is only a log of the commands that 5ttgen fsl executes. If an error occurs within one of those jobs, log.txt will not contain any information on this.
You can also try printing the contents of the script temporary directory, i.e.:
$ ls ~/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/
; however this will almost certainly only demonstrate the absence of the segmentation files that FIRST is supposed to produce, which is precisely what is reflected in the error message that is being provided to you.
Hopefully the contents of files “first.logs/first*.e*.*” and “first.logs/first*.o*.*” give us more information.
I did found errors in “first_flirt.*”. The outputs are: $ more first_flirt.*
::::::::::::::
first_flirt.e22386
::::::::::::::
Image Exception : #22 :: ERROR: Could not open image /usr/share/fsl/5.0/data/sta
ndard/MNI152lin_T1_1mm_subbr_mask
terminate called after throwing an instance of 'RBD_COMMON::BaseException'
Aborted (core dumped)
Could not open matrix file T1_to_std_sub_tmp_stage2.mat
Cannot read concat-matrix
Could not open matrix file T1_to_std_sub.mat
terminate called after throwing an instance of 'NEWMAT::IncompatibleDimensionsEx
ception'
Aborted (core dumped)
::::::::::::::
first_flirt.o22386
::::::::::::::
initial registration 0
Stage 2: use subcortical mask
I then checked the outputs from first.logs/first*.o*.*: $ more first.logs/first*.o*.*
::::::::::::::
first.o22529.1
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-L_Accu_first
::::::::::::::
first.o22529.10
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-R_Thal_first
::::::::::::::
first.o22529.2
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-R_Accu_first
::::::::::::::
first.o22529.3
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-L_Caud_first
::::::::::::::
first.o22529.4
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-R_Caud_first
::::::::::::::
first.o22529.5
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-L_Pall_first
::::::::::::::
first.o22529.6
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-R_Pall_first
::::::::::::::
first.o22529.7
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-L_Puta_first
::::::::::::::
first.o22529.8
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-R_Puta_first
::::::::::::::
first.o22529.9
::::::::::::::
linear transformation matrix file not found
Error: cannot find image first-L_Thal_first
I found no content in first.logs/first*.e*.*.
Finally, I checked the contents of the script temporary directory: $ ls ~/HCP/20180121_MRtrix3/test_5ttgen/5ttgen-tmp-FE7LGB/
OK, straight out of the gate, this catches my eye:
Image Exception : #22 :: ERROR: Could not open image /usr/share/fsl/5.0/data/sta ndard/MNI152lin_T1_1mm_subbr_mask
It’s unable to find a mask image that instructs flirt to prioritise the registration of sub-cortical structures to MNI space rather than using the entire brain. This suggests that you have not installed the requisite data that FIRST requires to operate. Whatever mechanism you have used to install FSL, you need to acquire the FIRST data using the same mechanism (it’s not installed as a core part of FSL because it adds another 1GB to the download).
E.g. You can see the relevant package on NeuroDebian here.
Turned out that my FSL standard directory did not have that particular mask (and was missing a bunch of files, which is odd since I installed both fsl-complete and fsl-first-data via NeuroDebian). The problem was successfully resolved after updating the standard directory.
I’m posting my question here, because I got the exact same error message and followed the error solving steps provided here. Everything the same: same content in my first_flirt.o36681 and my first.o* files.
However, my first_flirt.e36681 is empty…
I checked of course if I have the MNI152lin_T1_1mm_subbr_mask and I do.
My first.e* files give me the following error message
$ more first.e*
::::::::::::::
first.e47902.1
::::::::::::::
terminate called after throwing an instance of 'NEWMAT::SingularException'
/usr/local/fsl/bin/run_first: line 164: 47975 Aborted (core dumped) ${FSLDIR}/bin/first -i $i
mage -l $trmat -m $model -k $outname -n $modes $verbose $comExtras
::::::::::::::
first.e47902.10
::::::::::::::
terminate called after throwing an instance of 'NEWMAT::SingularException'
/usr/local/fsl/bin/run_first: line 164: 1965 Aborted (core dumped) ${FSLDIR}/bin/first -i $i
mage -l $trmat -m $model -k $outname -n $modes $verbose $comExtras
::::::::::::::
first.e47902.2
::::::::::::::
Would be grateful for some help on figuring this out!
Thanks,
Steph
PS.: I tried both unset SGE_ROOT as well as SGE_ROOT="" 5ttgen fsl T1.coreg.nii 5tt_act.mif as suggested by @jdtournier here 5ttgen 'run_first_all' error and still got the same error including the same message that 5ttgen: FSL FIRST job has been submitted to SGE; awaiting completion which then never completes…
Firstly, can you check that the gotcha reported here is not an issue on your system? I’ve in recent times had people with different issues manage to trace things back to that common underlying cause.
However from those error messages my suspicion is that there’s some kind of issue happening within the registration that is performed within FSL’s FIRST scripts. These are outside of my control so the extent of my assistance is kind of restricted by that… Only things I would suggest are:
Try to derive a good brain mask, and then use either the -mask or -premasked option to 5ttgen fsl.
Check the orientation of your input image relative to the MNI template image provided with FSL. If e.g. the axes are permuted such that there’s a 90-degree rotation between your image and the template, it’s entirely possible that the FIRST script is failing to identify this.
As far as SGE, I had a quick look, and my code is checking for the presence of that environment variable; in your case you’re setting it to an empty string, but it’s still nevertheless set, and that’s why the 5ttgen fsl script is choosing to wait for the appearance of new files in the future rather than terminating immediately. But ultimately that’s only affecting what type of terminal feedback you receive regarding the FIRST failure, not the failure itself.
It turned out that a couple of things went wrong:
As you suggested, I checked the orientation of my image and found that DWI and T1 were not oriented in the same way. I fixed that with fslreorient2std.
Next, we found that run_first_all was still trying to submit jobs to SGE. We therefore put a line of code in that particular script to prevent this from happening.
Luckily all this was enough so that once fixed, 5ttgen is now running without error.