[MINC-users] The future of MINC

[Jason Lerch]

On 2011-02-01, at 7:49 AM, Andrew Janke wrote:

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

Do they support one of the distributed version control systems yet? (git, hg, bzr, etc.) Having used them for a while now I do think that DVCS offers considerable advantages.

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

Most version control systems can import from CVS and keep the history - that is assuming folks haven't spend too much time mucking about in the private CVS bits for a project. The joys of CVS ...

> 
>> 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 completely agree with you - MINC is complex because it needs to be. Though I do think the glue libraries can access most of the complexity where need be.

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

Agreed. MINC = neuroawesome, NIFTI = pain.

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

I also don't much like this approach either - why not use libminc, it already handles all the NETCDF and HDF5 bits for you and this ensures that you stay compatible with any MINC file, not just a subset.

Later,

Jason