Description
Summary
When porting an FSL script to nipype, I noticed different results coming from a series of fnirt commands. Looking more closely, I found the outputs of the first fnirt command were correct, but the outputs of the second fnirt command were incorrect. In investigating the input parameters of the second fnirt, I found a slight difference with intensity map file names: because nipype adds .nii.gz to intout arg for the first fnirt, the generated files were called x_intmap.nii.gz and x_intmap.nii.gz.txt. Since fnirt expects x_intmap.nii.gz and x_intmap.txt on disk, with an extensionless intin arg [0], the nipype-generated commands are incorrectly accessing intmap files on disk.
0: from https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FNIRT/UserGuide
If specifying only the "basename", fnirt will find the relevant files itself. If fnirt was e.g. run with
fnirt --ref=... ... --intmod=global_non_linear_with_bias ... --intout=my_intensity_mapping
in the previous run it will have produced two files: my_intensity_mapping.txt containing the global mapping and my_intensity_mapping.nii containing the bias-field. If then in the next run fnirt is passed the parameters
fnirt --ref=... ... --intin=my_intensity_mapping
both my_intensity_mapping.txt and my_intensity_mapping.nii will be read and used.
Actual behavior
fsl.FNIRT()'s intout and intin arguments have .nii.gz extensions (different depending on fsl output type).
Expected behavior
fsl.FNIRT()'s intout and intin arguments have no extension, which means fnirt will make use of previously created ...intmap.nii.gz and ...intmap.txt files.
More details, and scripts for testing effects of intin and intout
I have a script that details the effects of various combinations of intin or intout for the fnirt command: https://gist.github.com/cgc/5f465adeb6f544efc6a3eed2478d38c1
In summary, having both the .nii.gz and .txt files on disk (produced by an intout argument without a file extension) and passing them into a fnirt command with an intin argument that has no extension (as the extension means one file won't be processed, per fsl codebase) seems to be the ideal/correct way to use intensity mappings.
Platform details:
running the test script in docker image williamspanlab/gear_base
{'nibabel_version': '2.1.0', 'networkx_version': '1.11', 'numpy_version': '1.12.0', 'sys_platform': 'linux2', 'sys_version': '2.7.9 (default, Jun 29 2016, 13:08:31) \n[GCC 4.9.2]', 'commit_source': 'installation', 'commit_hash': u'a4d1e07', 'pkg_path': '/usr/local/lib/python2.7/dist-packages/nipype', 'sys_executable': '/usr/bin/python', 'traits_version': '4.6.0', 'scipy_version': '0.18.1'}