[MINC-users] The future of MINC

[Andrew Janke]

Hi Pierre,

Sorry I never saw the original email but here goes...

> On Dec 16, 2010, at 12:06 PM, Pierre Bellec wrote:
>
>> 1. Distribution
>> Basically, outside of debian/ubuntu, it is often very difficult or impossible to install the MINC tools for simple end users.

Agree. There are some reasons for this to do with licensing of
differing packages but yes it could be very much simplified. The
catalyst for this might be shifting the MINC CVS repository to
somewhere that is more conducive to external developers. (NITRC/Google
Code/Launchpad/etc).

> could be arranged to build a TAR ball at CRIUGM for MAC OS 10.6 for example.

Sounds good to me. You mean a big .mpkg for everything? MINC has
always been something that if you build it, we/I will link to it.

>> 2. I/O
>> The libraries to manipulate MINC in C are a bit difficult to use.

I'd say necessarily difficult. Perhaps use
/usr/local/bic/include/minc_simple.h for quick and dirty projects?  I
suspect that in time people will more use things like Jason's nipy
interface.

> I am going to break a taboo, but I believe that to reach a wider audience, it is mandatory that MINC tools work with NIFTI. Whether we like it or not, NIFTI is by far the most widely used format currently.

Trust me, you are not the first to suggest this...  I too have had
thoughts of doing this but a few things always stop me before I go too
far.  The main concern is that while you can read NIFTI in one case it
doesn't mean you can read them all (consistently). The stand out
problem being of course "radio" vs "neurological" format files.

Despite that problem that saving files flipped vs unflipped is
somewhat daft (change the viewer not the data), the main issue is that
you don't know from looking at the file itself. That and as soon as
you read another format the assumption is that the conversion is
perfect (and in both directions). I myself HIGHLY value that I always
know that the orientation and world positioning of my files is 100%
bang on. (Thanks Peter Neelin! :) For that I am prepared to run
nii2mnc and mnc2nii from time to time.

Still, I am not going to stop you... :)

> Confining MINC tools to the MINC format is I think a mistake.

You might be surprised to know that MINC (well volume_io) can indeed
read another format called "free format". See start_volume_input() in
minc/volume_io/Volumes/input_volume.c

Adding a NIFTI format to the list and adding another case statement
would not be hard. I'd just caution about writing it out again.
Perhaps just a dodgy system call to nii2mnc and a tmpfile?



Andrew