Hi Andrew,
We are experimenting with minc i/o code written by Bert
Vincent in Montreal. If this works out well then it should
turn up in the next release. Also, we are committed to
supporting the new nifti format, which should become the most
widely support image format, since it has been signed up
to by almost all major packages (us, SPM, AFNI, BrainVoyager, etc)
Hence we will be adding minc support if it goes well, not
switching over entirely to minc. Also, we will continue
to support Analyze for backwards compatibility. This all
means that issues of orientation, scaling, etc are far from
trivial as they need to be supported correctly across
these different formats.
As for our I/O libraries - if you look carefully you'll
see that calls to avw_read are actually funneled into
the same fslio library as everything else. So, although
we have a couple of different image structures/classes
(for historical reasons) they all make calls back to the
same I/O library. There is no mixed support (except for
FAST which is a huge exception and is dealt with by wrapper
scripts for now).
I hope that puts you in the picture.
I'll keep everyone posted on the outcome of minc support.
All the best,
Mark
On 16 Nov 2004, at 21:53, Andrew Janke wrote:
> I note there is a fair amount of skeleton code in fslio.{c,h} to read
> and write
> MINC files but no actuall code as libminc doesn't appear to exist yet.
>
> I happen to have a working libminc for previous versions of FSL but am
> interested to know what the plans for support are. I can write the new
> MINC I/O
> routines should you wish. Also, problems with orientation, scaling,
> range etc
> that exist with other formats are non-existant in MINC. There is a
> very well
> defined world co-ordinate system.
>
> It may also be nice to see if we can merge some of the functionality
> of the minc
> tools into FSL along the same lines as the avwtools. As fslio handles
> all the
> I/O this means that this extra processing need not be specific to MINC
> files
> only.
>
> Also, I note some some of the tools (bet for example) still call
> avw_read
> directly instead of using the (I presume) new FSLRead() type
> functions. I
> assume this means that these tools just need updating to fit into the
> current
> model of FSL I/O?
>
> Thanks
>
>
> --
> Andrew Janke ([log in to unmask] DOT au ||
> www.cmr.uq.edu.au/~rotor)
> Australia->Brisbane H: +61 7 3390 6332 || M: +61 4 2138
> 8581
|