-
-
Save chrisgorgo/359040 to your computer and use it in GitHub Desktop.
Case 1 | |
SubjectSource ->['4D.nii']->Spm.Realign->'4D.nii'->FSL.Smooth->'4D.nii' | |
in contrast to: | |
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->FSL.Smooth->'4D.nii' | |
Case 2 | |
SubjectSource ->['4D.nii']->Spm.Realign->'4D.nii'->SPM.Smooth->'4D.nii'->FSL.Bet | |
even thou SPM.Smooth also accept lists | |
in contrast to: | |
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->SPM.Smooth->['4D.nii']->FSL.Bet |
I don't agree this is a better way to do it from the user point of view. I understand it seams cleaner from our (developers) point of view, but iterfields/mapnode should be necessary only in cases of iterating over MULTIPLE values. This is just unnecessarily overcomplicated.
About exceptions user would get in the interactive mode. This would be just annoying - why would I need give a list if it will also work on single elements? What we need to do is to automatically generate traits constraints in the documentation so it would be clear for the user what to use.
internally for something like spm Realign, one would need to support (at the end of the day):
Any(List(List(File(exists=True, type='3d'))), List(File(exists=True, type=['3d','4d'])), File(exists=True, type='4d'))
the only addition here is the last one (for user simplicity).
alright. let's go with user simplicity for now and we'll see how things evolve. but this will require us to solve the multipath trait issue
so this is a more general problem of how to connect nodes that accept multiple inputs to nodes that don't.
so case 1:
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->mapnode(FSL.Smooth)->['4D.nii']
and case 2:
SubjectSource ->['4D.nii']->Spm.Realign->['4D.nii']->SPM.Smooth->['4D.nii']->mapnode(FSL.Bet)->['4D.nii']
actually, i think the bigger problem may be subjectsource. for a given subject, you can have say one structural scan and one functional scan. so should subjectsource return a str for the structural and a list for the functional? or should we provide a mechanism for the user to specify? or should it always return lists?