[MINC-users] The future of MINC

[Andrew Janke]

>> catalyst for this might be shifting the MINC CVS repository to
>> somewhere that is more conducive to external developers. (NITRC/Google
>> Code/Launchpad/etc).
>>
>> I couldn't agree more. Having a proper development environment would
> certainly help making a leap forward in terms of external contributions and
> cleaning up the installation procedure.

Well then my decree is for NITRC, I know it's not really my decree to
make but nonetheless I have made it.  I know some of the others
(launchpad, google code) are more pretty but at least NITRC is
something that we (MINC people) will actually have a hope of
changing/updating if the need arises.

FWIW: this topic has been beaten around the BIC for a long time now,
one of the concerns was keeping the MINC CVS history but the NITRC
Boffins tell me that this is possible.

> I had the feeling that EZminc was developped to cope with some shortcomings of the existing
> libraries.

EZminc to my understanding was a bit of glue between the C MINC
interface and ITK for vlads needs. Sort of akin to what volume_io was
originally for Dave McDonald. Still I don't think the C MINC2
interface needs changing, it works and works well. Pity none of the
minc tools use it yet but that's another issue....   I think dumbing
down the C MINC2 interface would be a bad idea, very few people use
all the features of MINC (eg: block structured files, MINC ID's,
automatic History, world + voxel co-ordinates, Big vs Little endian
resistance) and most of the glue (R/Matlab/Octave/python) libraries
from what I have seen take a very simplistic approach to reading a
file. That is: gimmie the file, gimmie all of it, I'll put it in a big
short/float array called minc.img. This approach is fine and serves a
purpose (and usually well). The point is
mincmath/mincaverage/mincresample/minccalc/mincstats _can_ be used on
multiple MINC files that are over 10GB in size and yet only use a
small amount of memory/CPU.

I myself do this on a day to day basis with 19T micro-imaging data on
mice/zebrafish. There are pretty much no other tools out there that
can handle this sort of analysis gracefully. It's for this reason that
I like MINC, it was designed to be flexible not just handle a
particular users needs at the time. Thus because of the above the MINC
C library is always going to be complex, and will continue to be so.

>> 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.

Guess we should dump gcc and shift to Visual Studio then too... :)

Myself I think we have "sufficient" compatibility with Nifti right now
(nii2mnc, mnc2nii), I view Nifti as a transfer format not as a primary
storage format but then I'm elitist. To me Nifti is overly simple.

> I am currently looking into that for the NIAK nifti reader/writer, and at
> this stage I don't think I mastered the subtleties  of NIFTI space
> orientation.

:) The point is you can't. The different packages (SPM, FSL, etc)
write and treat Nifti differently. How they write them depends on
certain global variables that you won't have access to when someone
sends you a file.

> Getting MINC tools to enter, say, NIFTI and
> produce MINC sounds dangerous, but as long as you stay in one format I don't
> see major problems.

Ack! count me out... Again I won't stop you/anyone doing this but I
don't have plans on doing this, perhaps in a restricted application
area (like fMRI) this will be fine though.

> I am not sure if that outline makes sense or if this is
> applicable with the existing C MINC libraries. But that's pretty much how I
> do it with NIAK.

Sounds reasonable and again I applaud you for writing NIAK, in time I
can see it making a lot of (MATLAB/Octave) peoples lives easier.

> I can only speak for my limited experience : Matlab/Octave. Emma is a pain.

<tick>

For quite some time now if anyone asks me about EMMA / MATLAB I have
been pointing the to NIAK.

> In my spare time, I am working on a MINC1 & MINC2
> reader/writer <http://code.google.com/p/mominc/> that directly use the
> NETCDF and HDF5 libraries of Matlab, and this seems to work *much* better.

Hrm... I did notice this :) I never have been a fan of this approach
but then you are more than free to do as you want, that's the good bit
of the MINC license. John Ashburner also wrote a MINC reader a yonk
back in SPM that would hunt for the image variable in a netCDF file.
If I could make a suggestion for NIAK and mominc it'd be this:

   * User installs NIAK + mominc == read MINC only, r/w Nifti

   * User install NIAK + MINC, r/w MINC, r/w Nifti


a