How to use fslmaths efficiently with NiPype?

[Michael]

I am used to do lots of operations with fslmaths which can do complex tasks in a one-liner. However the NiPype warper of fslmaths seems especially difficult and cumbersome to use, but maybe i'm using it wrong.

The fslmaths wrapper expects in_file for the first input and op_string for a list of all other inputs. So even if i can't create a node to make lists of any length with NiPype, creating fixed length nodes (makePairList, makeTripletList, ...) would not work for all my different operations because these list-making nodes could only be used once right? Then how to write fslmaths commands with a varying number of arguments efficiently?

As an example I created a Node to encapsulate a fslmaths command i want to run on several different inputs (in_file and op_string list, both changed for each command). This means that i would have to create a MapNode, create lists ([in_file1, op_string list1], [in_file2, op_string list2], ... ) for each inputs of this map node and inside these lists create lists for op_string (op_string1=[myFileFromNode1, myFileFromNode1], ...). This seems a nightmare to implement.

Does anyone see an easy solution to this issue? fslmaths is an extremely convenient command-line tool so having it work efficiently in NiPype would be particularly useful.

[Satrajit Ghosh]

hi michael,

every software package that implements their ImageMaths command (e.g., FSL, ANTS, c3) tend to make it the swiss army knife and implement a mini grammar on the commandline. unfortunately we cannot support all of those variations from a dataflow centric perspective. 

however, in this case one possibility is to use the approach that DataFinder uses, but on the input side. one could write an augmented FSLmaths interface such that the op_string could look like: `-sub {input1} -mul {input2}` and this will internally create input ports for that node named input1 and input2. the good news i think is that FSLmaths always produces a single output.

what do you think? would having this augmented interface solve your problems? we'll have to think a little more about the interaction with mapnode. for now though, you might be better of calling fslmaths within a function node.

cheers,

satra

--
 
---
You received this message because you are subscribed to the Google Groups "NiPy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nipy-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael]

Hi Satra,

Yes i think augmented interfaces bypassing list creations would be great as lists seem to make the use of nodes much more cumbersome. In general do you recommend a specific Swiss army knife with NiPype? 

Also it is not entirely related but how would you reproduce the same simple operation (say binarize) many times in a pipeline (not applying it to many files at the same pipeline step, but at many different steps within the pipeline)? If one has 15 binarize operations, does he need to define 15 Nodes?

I am new to NiPype so maybe this is a stupid question but could we imagine a future Node constructor which defines a Node not only by his name and interface but also by its input and output so that the same Node could be used at many different places in the pipeline?

Maybe i should have created a post for each question, sorry if this is a problem.

Best,

Michael

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "NiPy Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nipy-user/CtJfK9YKr-s/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to nipy-user+...@googlegroups.com.

[David Gutman]

Michael--- I'm glad your bringing this up... especially reuse of nodes.    There's already a mechanism to copy a node and reuse it.

But I like your idea----  Satra/Chris would have to comment on the feasibility of doing this, but basically it would be nice if I had a prototype "binarizer" that I create the node for.

But then during the

myworkflow.connect( datasource,"t1",  binarizer[instance1],"in_file")   or something similar--- basically some sort of wrapper/parameters that would automatically create an instance of binarizer in the workflow.connect stage..  binarizer.instance1, binarizer.instance2, etc... would still be separate nodes..  but the code would be a lot cleaner if it could be done that way...

Right now I do something like

binarize_t1 = new pe.node(interface=fsl.Binarize(), name='binarize_t1')

binarize_t2 = new pe.node(interface=fsl.Binarize(),name='binarize_t2'), etc, etc, etc...

and then when a node has additional parameters becomes even longer redundant blocks..... 

Just a thought....

David A Gutman, M.D. Ph.D.
Assistant Professor of Biomedical Informatics
Senior Research Scientist, Center for Comprehensive Informatics
Emory University School of Medicine

[Michael Waskom]

It's not completely clear what you're specifically trying to do, but I wonder if you're aware of the interfaces.maths sub-package? This is intended to make it more straightforward to do some of the things that fslmaths is capable of.

Replacing a complicated one-liner with a few nodes strung together is definitely more verbose. But when you're writing  workflow once that you'll then use repeatedly, sometimes the interpretability/maintainability that comes with that extra verbosity is nice..

[Chris Filo Gorgolewski]

On Thu, Jun 13, 2013 at 12:20 AM, Satrajit Ghosh <sa...@mit.edu> wrote:

however, in this case one possibility is to use the approach that DataFinder uses, but on the input side. one could write an augmented FSLmaths interface such that the op_string could look like: `-sub {input1} -mul {input2}` and this will internally create input ports for that node named input1 and input2. the good news i think is that FSLmaths always produces a single output.

I was thinking of such dynamic interface as well. It would be very useful!

[Michael]

Hi Michael,

Thanks for your post, indeed the interfaces.maths sub-package is useful and goes in the right direction. With regards to applying the same operation sequence to multiple images, cloning Nodes or workflows seems also the more appropriate solution so far and can sometimes add more clarity as you suggested. 

However with respect to using a one-liner fslmaths operation sequence which does not correspond to any standard operation as available in the maths subpackage (random example: fslamths myfile -thr X -bin -dilM -dilM -ero -mul X -sub mymask -thr 0 -bin) then it is particularly hard to do a concise equivalent in NyPype, especially due to the required creation of lists, and the extra nodes created for this purpose often do not result in increase interpretability.  The solution proposed by Chris and Satra bypassing list creations would be definitely a step forward to improve the implementation of such operation sequence.