[MINC-users] The future of MINC

[Pierre Bellec]

Dear MINC users list,

Here's a follow-up on the lattest contributions regarding "the future of
MINC" to keep the ball rolling.

@Giovanna

Thanks a lot for taking the time of expressing your views. We would need
more contributions of this kind from people that can be legitimately
identified as end-users, rather than insiders that spent a couple of years
at the MNI coding applications within or around MINC. Needless to say I
totally second your diagnosis : it is currently hard to make any use of the
potential of MINC without first-hand training with an enlightened one. We
could definitely use contributions in the form of documentation, the
MINC<http://goog_1515729400/>
 wikibook <http://en.wikibooks.org/wiki/MINC> is already in place and a
friendly medium to do that. We would still need a roadmap before starting up
the work though.

@ Andrew

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

The "Gimmie the file, gimmie all of it" approach clearly is what most coders
will want. The simpler the better. fMRI datasets are comparable in size to a
5 Mpixels digital picture. Complex code designed to spare memory in that
context is a waste of time. The push for higher resolution may be a valid
rationale to keep that level of complexity (even though a 160G SSD is ~400$
at futureshop). If there is something already in place (EZminc) that can
simplify the life of some developpers, why not support both libraries rather
than stick to the most complex one only ?

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

Well, we disagree on that one. If NIFTI is good enough for FSL and SPM it
should be good enough for us. I don't want to start a full NIFTI vs MINC
debate here (on which I am sure we would agree point by point anyway), but
NIFTI is an established file format that is widely used. A lot of existing
databases are in NIFTI and asking to users to first convert everything
before using the MINC tools is quite dissuasive. Most importantly, for
someone like me who wants to develop on top of the MINC tools and obviously
want to provide support for NIFTI, the support of NIFTI is a major feature.
I found my way around the lack of NIFTI support, but I am pretty sure this
has discouraged a fair amount of potential contributors in the past. I don't
want to unilaterally disclose names here, but spontaneous testimonies are
welcomed ;)


> > 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.
>
>
Well, I agree that ANALYZE is absolute chaos, and does not have orientation
infos built in anyway. See this excellent
post<http://www.rotman-baycrest.on.ca/~jimmy/UseANALYZE.htm> by
Jimmy Shen at the Rotman for details. By contrast, NIFTI seems to have a
clear convention, as explained in the NIFTI
FAQ<http://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q14>.
It is right-handed (i.e. left's on the left). More specifically X = left to
right, Y = posterior to anterior, Z = ventral to dorsal. From the
voxel-to-world LSQ12 transformation matrix, it is relatively straightfoward
to pull out the start, steps, direction cosines and dimension order. So at
this stage I don't see the problem. You obviously experienced some problems
first-hand, so would you mind sharing some confusing cases you encountered
?


> > 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 sorry to hear that you think this is not worth the effort.


> > 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
>
>
I see one major advantage to build a reader/writer based on native
NetCDF/HDF5 libraries : you download the routines and you're done. Nothing
to compile, no dependency to install. I am curious to see how the NiPY
community will react to the Python MINC2 IO tool of Jason for example (great
job BTW, that convinced me to start using python for some projects). It does
add a dependency on the development MINC libraries. Not a problem for MINC
developers, but will it make it to the standard distribution of NiBabel ?
we'll see. In Matlab/Octave I want to avoid compilation if I can. What I
like about the libminc2 library option (called in MEX) is that it would work
for both Octave and Matlab. I'll think about it :). In any case, the
specifications of MINC2 are pretty clean and it is fully HDF5 compliant as
far as I can see. I thus don't see why taking that route would be a problem
in principle. You're not the first one telling me that the reader's OK but
the writer would fail. I haven't tried the writer yet (my reader 90% fine
and fully fixable I believe) but is there a dirty secret I should know ?

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 #3367




2011/2/2 Giovanna Pellecchia <giovanna.pellecchia at camhpet.ca>

> Howdy all,
> the debate is taking an interesting turn, especially after Louis Collins'
> offer (and not for the reasons you may think!).
>
> I have a limited experience with MINC, but if you are interested in
> expanding the MINC end-user base, with the ultimate goal of generating more
> MINC development, maybe my experience might be representative of the world
> out there.
>
> I joined Antonio Strafella's lab here in Toronto in 2006 and started by
> installing the MINC tools on his computers.
>
> The most frustrating issue for a newbie was that I could not find a single
> accessible place where to get code, packages, documentation and help.
> Finding the right tools still requires an insider's knowledge and there is
> no user-friendly documentation to be found.
> As a complete outsider of the BIC and isolated from the MINC community at
> large, I would have been in deep trouble, if it had not been for Jason Lerch
> (who trained at the MNI), who helped me with finding the code, understanding
> abstruse compiling errors, pointing at known (for long-time MINC users)
> issues, and making everything work seamlessly.
>
> There are a few contributors who are extremely prolific, but as it stands
> now, MINC is a closed community of people who used to know each other. As I
> see it, unless MINC is able to generate a wider interest, it will not
> trigger more development or original contributions. It is a more general
> issue than just deciding where to shift the code development.
> That's why I think Louis Collins' offer hits the mark. Increasing the
> end-user base requires an investment in training and tutoring, and may
> require (an) “official” coordinator(s) that deploy(s) resources as seen fit
> by the community.
>
> I am certain that there are a few labs, like mine, who are developing with
> the MINC world and would be happy to contribute, if not with good code at
> least with good documentation, if given a chance to do so in a simple and
> welcoming way.
>
> Just my one cent.
> Cheers,
> Giovanna.
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>