[FIX]: AFNI Allineate #2098
[FIX]: AFNI Allineate #2098
Conversation
Errors in OutputSpec mapping for Allineate, where out_file name was not successfully generated or mapped. Added xor options for some input options that are mutually exclusive. Included new "overwrite" feature to overwrite output if it already exists.
Codecov Report
@@ Coverage Diff @@
## master #2098 +/- ##
==========================================
- Coverage 72.25% 72.25% -0.01%
==========================================
Files 1168 1168
Lines 58405 58418 +13
Branches 8400 8404 +4
==========================================
+ Hits 42203 42208 +5
- Misses 14868 14870 +2
- Partials 1334 1340 +6
Continue to review full report at Codecov.
|
nipype/interfaces/afni/preprocess.py
Outdated
| outputs['out_file'] = self._gen_filename(self.inputs.in_file, | ||
| suffix=self.inputs.suffix) | ||
| outputs['out_file'] = self._gen_fname(self.inputs.in_file, | ||
| suffix='_allineate.nii') |
There was a problem hiding this comment.
does this command always produce a .nii file?
There was a problem hiding this comment.
No, sorry! That was an oversight on my part that I'll resolve shortly. However, it does lead to a somewhat interesting discussion...
If generated, the out_file dataset will always be a neuroimage; however, Allineate doesn't necessarily need to produce an out_file at all. If you don't specify any of (1) out_file, (2) out_matrix, (3) out_param_file, or (4) out_weight_file, but you do specify a base and source, 3dAllineate will happily run and print the fit parameters to stdout.
As such, I can remove the current _list_outputs section if you'd like and just do a few
if isdefined(self.inputs.X):
outputs['X'] = self.inputs.Xfor the various potential OutputSpec files in a new commit.
However (and I know I'm going a bit overboard in response to a pretty straightforward question) dealing with the uniqueness and variability of AFNI outputs is something that hasn't really been addressed in nipype. For many AFNI programs, you don't need to specify an output file/prefix--AFNI will simply default to outputting BRIK/HEAD files with a moderately relevant name. While this wouldn't necessarily be a problem, AFNI also adds the "view" (+orig/tlrc/acpc) to the output (i.e., instead of output.BRIK and output.HEAD, you get output+orig.BRIK and output+orig.HEAD).
In order to allow piping in a workflow, these output files would need to be properly specified in an interface; however, you can't know the output view without calling additional commands (i.e., 3dinfo -view) on the input datasets, and even then there's a possibility they might be different for the resultant dataset. As such, many of the AFNI interface out_file parameters are going to be mis-specified, unless you coerce them (i.e., via to generate .nii files. Given that the ability to integrate nipype interfaces into workflows is critical, I think it might be worth discussing how to deal with these "atypical" AFNI outputs and potentially devising a mechanism for standardizing them to work seamlessly with nipype workflow chaining. I'd be happy to open an issue with a few examples of these features and some potential solutions if you think this would be a worthwhile discussion.
There was a problem hiding this comment.
@rmarkello - thanks for this clarification and sorry for the delay in responding to this. perhaps we can do this in two stages. first lets fix this interface. then we can use a separate PR to implement the logic you outlined above.
Fixed output mapping in Allineate. Ensures suffixes are in line with AFNI standards.
|
@rmarkello - could you please merge master and push? |
|
@rmarkello - since i merged @Shotgunosine's PR before this there are some conflicts. perhaps you guys can resolve and update this. |
Edited AFNI Allineate interface to accommodate updated master branch. Updated xor options for allcostx.
Changes proposed in this pull request