[MINC-users] The future of MINC

[Pierre Bellec]

Dear all,

My apologies for being so late following up on this thread. First I would
like to thank everyone who sent feedback, either directly to me or through
the list, which has been quite reinvigorating. The main conclusion I drew
from these emails is that there is much to do and lots of MINC fans out
there, that we need to discuss about what the main priorities are and find
resources to implement them quickly. I am very happy to see that Louis has
taken the lead on these points, and I am looking forward to the upcoming
round of discussions. But because good things can't wait, I have merged
below my responses to the detailed emails that Andrew and Jason have sent.

@Andrew

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

> 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.
>
>
Maybe not a package per say, at this stage I was more thinking about a big
.tar.gz with a full minc bundle in it. There have been some discussions
going on to see if some of the resources of the Québec bio-imaging network
could be used to prepare this kind of archive. Nothing conclusive yet but I
have good hope.


> >> 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.
>
>
An interface to high-level languages like python are certainly going to make
life easier for a lot of developpers. I am afraid I am not exactly the right
person to discuss the C libraries, as I don't actually use the C MINC
library. I wanted to raise the issue hoping that other people (Nico ?
Pierrick ? Vlad ?) would jump into the discussion. I had the feeling that
EZminc was developped to cope with some shortcomings of the existing
libraries.

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

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. In any case, what I plan on doing is reproduce most of the
header from the input into the output. In most operations, being in "radio"
or "neurological" convention does not matter. The only scenario I can think
of where that would be a problem would be coregistering two volumes under
different conventions.

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

I do agree that the MINC files have straightforward orientation infos and
that it is extremely valuable. 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.

>
> Still, I am not going to stop you... :)
>
>
Good ! I am not exactly proposing to do it myself though, at least at this
stage. Just testing the idea ...

> 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?
>
>
I don't like the solution of double conversion. You're pretty much bound to
mess up with field values. Again, the easiest solution I see would be to
keep somewhere a full version of the header of the input file, whatever its
format may be, and have some header structure common to all three formats
(MINC1, MINC2, NIFTI) that is used internally. When time comes to write, you
use the original full header and just update the infos based on the common
structure. 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.

@Jason

1) yes, MINC could be easier to install. There are a series of packages
> around for MAC, linux, etc., but clearer instructions or more centralized
> locations for all that would indeed be good. That being said, anybody who
> wants to install minc and is slightly persistent can get it done without
> great difficulty.


I guess it depends where you set your expectations. Basically mine are :
download, untar, run a configuration script, voilà. Or better, get a
package, say install, and it works. In Ubuntu, that's pretty much already
how it is (minus some small glitches, see "testing" below). I am afraid such
expectations are largely shared by end users. But I tried to install a 32
bits OSX 10.5 (or something along those lines) recently and it hasn't been
smooth, to say the least. Central location/documentation are in
place<http://en.wikibooks.org/wiki/MINC/Installation> but
I still think that there is room for marked improvements. I don't think that
there is systematic testing of releases yet, and that's something that could
be arranged easily across a couple of sites in order to make sure that the
experience of new users is a pleasant one.


> 2) How are the MINC C libraries difficult? Sure, the MINC 1 ICV stuff was
> something only Peter ever understood, but volume-io is quite useable and
> the MINC 2 API is actually glorious to use.


As I have already confessed in my answer to Andrew, I don't actually use
those libraries. I was just repeating things I heard to start a discussion.
I guess I was successful, in a way. I would love to hear from Vlad where
EZminc stands compared to the regular MINC C IO libraries.

And you contradict yourself on the next line: there is an R reader for
MINC (two,
> in fact - mine, which is a bit simplistic, and Jim's, which is quite
> glorious), there are two for matlab (EMMA and yours), there are two for
> python (mine and John Sled's - which have suffered from not being released;
> seelaunchpad.net/pyminc and launchpad.net/pyminctools for my morning's
> remedy of that). There are three minc readers for ITK (ours, David Gobi's,
> and Vladimir's). There are converters to and from the OBJ format for
> Inventor and VTK among others. So no, I don't think it's hard to work with
> MINC at all.


I can only speak for my limited experience : Matlab/Octave. Emma is a pain.
The current NIAK reader is not too bad, but slow and dirty (basically
anything exotic will crash ungracefully). And it requires the MINC tools to
be installed, so it does not make development with MINC straightforward
either. So altogether, dealing with MINC in Matlab/Octave is not, at this
stage, painless. 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.
Unfortunately, those libraries don't exist in Octave, so this is not the
ultimate solution. The python library has not been out for very long but it
certainly is a great addition to the MINC arsenal, which I will definitely
use myself.

And I certainly see no reason why the MINC libraries have to read NIFTI -
> there are enough meta-libs like ITK that can handle both if that's what a
> user really wants.


The reason is : make the MINC tools easy to use for the vast majority of
neuroimaging applications. Meta-libs are one thing, but image analysis
software that only deal with one file format while ignoring the most common
one are hard to find. On top of that, I don't think it would be that hard to
do even though I don't know much about the design of the MINC C IO libraries
(did I mention that before ?).


> 3) I completely agree that a better development location and model would
> help. We have this discussion on this list about once a year, with those
> outside the BIC agreeing, and those inside the BIC just remaining silent.
> Louis? Claude? Anyone? The fact that MINC is hidden behind the MNI's SSH
> access is ridiculous. Something like launchpad, githug, google code,
> anything would be better than its current fortified location. But I don't
> think we can force a centralized prioritization of development - different
> labs will do what they have interest in and resources for.


Centralized prioritization is indeed not something that is feasible or that
I would want to do anyway. But there could be some initiatives taken as a
community and we could probably find some funds for that. The python IO
libraries is an obvious example of a development that would benefit
everyone. Having a forum (like a MINC meeting at HBM or a MINC workshop or
tconf) to discuss such initiatives would help keeping the community aware of
what's going on and stay as active as can be.

>
> And I also don't agree that nothing is being developed with MINC anymore -
> there are plenty of labs, not all of them in Montreal, that use MINC exclusively,
> and do develop new stuff all the time.


Hehe great to hear that. I do myself think that there are lots of good stuff
currently developed in MINC, I guess I was being a bit provocative. Yet,
some of the developments do not make it to MINC releases (EZMinc, CIVET,
latest PVE estimation by Jussi Tohka and Jose Manjon amongst others). The
improvements we've been talking about would help to feed the MINC bundle
with cutting-edge developments.

Sorry for the long post. Best regards,

Pierre Bellec, PhD
Chercheur adjoint
Centre de recherche de l'institut de Gériatrie de Montréal
Département d'informatique et de recherche opérationnelle
Université de Montréal
http://simexp-lab.org/brainwiki/doku.php?id=pierrebellec
(001)(514) 340 3540 #336730