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 ;-)
>