 |
 |
Dear Nate, IMHO it would be so much better if all files were written as nifti except when it really cannot be a avoided, in which case the offending packages (that can't deal with nifti) should have wrappers around *them* that converts to and from the other format. Nifti is the best hope we have of getting packages working cleanly together. That's my 2 cents worth anyway. All the best, Mark P.S. Writing two different output formats from the one command sounds like a hideous feature and I really do think it should be broken down into simple steps of writing consistent outputs and then converting when necessary. That seems sensible in general and particularly for a pipeline! On 18 Sep 2009, at 16:31, Nate Vack wrote: > On Fri, Sep 18, 2009 at 2:29 AM, Mark Jenkinson > <[log in to unmask]> wrote: >> Dear Nate, >> >> I was explaining why we took our original decision when >> switching from Analyze to Analyze/Nifti. At this point it is >> really quite embedded in how things work and in our libraries >> so it would require a huge effort for us and so we are not going >> to make these changes - sorry. > > Bummer. Couldn't hurt to ask, though ;-) > >> I would have thought that you only need to keep up one >> wrapper script - something that took in the fsl command line >> and then either determined the output type itself or had this >> passed to it as one of the arguments: e.g. >> fslstarterscript NIFTI_PAIR bet in.img out.img >> fslstarterscript NIFTI_GZ bet in.img out.nii.gz >> where fslstarterscript just did: >> export FSLOUTPUTTYPE=$1 >> shift >> $@ > > Ah, I was thinking of doing something more elegant, to detect the > desired output from the requested filename and set the variable based > on that... then, however, you've gotta understand the command-line > parameters, so it's probably one wrapper per script. And as options > may change as new versions are released... gah. It's a Project*. > > Anyhow, the easy workaround is tell people "FSL writes only .nii > files. If you want something else, convert the files post-hoc." > > Pipeline, like all neuroimaging analysis software, Works The Way It > Works. The hope is that it can help us abstract the mechanical > differences between running bet and 3dSkullStrip, and let our > researchers concentrate on the scientific differences. Trick is, the > mechanical differences are pretty pervasive :( > > Thanks for the info! > -Nate > > * For an advanced exercise, consider a script to handle the case in > which you request that two output files have different formats ;-) >