[MINC-users] The future of MINC -> I have some $$ to help; coder(s) needed

[D. Louis Collins]

Hi all,

I agree with much of what Pierre described below and I would like to help push MINC forward.  In addition to the points raised by PIerre, I think we need additional documentation + examples (both for coders and users, but more for users).   I still have questions about NIFTI support, but I'm willing to be convinced...

I have some money available and would be willing to apply it to consulting salary to address some of the problems raised in terms of distribution and installation issues, documentation, .  I have one constraint - the money needs to be spent before the summer.  At the same time, this is an advantage - we could move forward towards solving some of the issues quickly.  

So, are there people out there that would be willing to trade time for cash?  

If you are interested or know who is interested, please get in touch with me directly.    Feel free to forward this message.

best regards,

-Louis

ps - please note that there will be a discussion of minc development on the geeks user list


D. Louis Collins, PhD			McConnell Brain Imaging Center
Associate Professor			Montreal Neurological Institute
Neurology & Neurosurgery	WB-314
Biomedical Engineering		3801 University St.
louis.collins at mcgill.ca		Montreal, Quebec.
voice: (514)-398-4227/8554	CANADA               H3A 2B4
Fax:   (514)-398-2975
http://www.bic.mni.mcgill.ca/PeopleFaculty/CollinsDLouis


On Dec 16, 2010, at 12:06 PM, Pierre Bellec wrote:

> Dear MINC fellow users and developers,
> 
> I am writing to you regarding a number of issues that I think are pressing regarding the future of MINC. I have been using the minc tools and the minc format for a while, and it has helped me tremendously in my work over the past couple of years. I am grateful to the community that develop this software, and it is because I like MINC so much that I am worried about what I see as major challenges :
> 
> 1. Distribution
> 
> Basically, outside of debian/ubuntu, it is often very difficult or impossible to install the MINC tools for simple end users. Even on debian/ubuntu, with the current level of testing for released packages some minor issues remain. Also, there are well over 10 packages to install to get the full MINC suite. This is confusing for end-users, to say the least. Andrew has made a great job at simplifying all that. He notably made a bundle for ubuntu that comes with all the tools at once and is a life saver. But Andrew alone can't support all platforms and do all the testing. One way around that would be to have a number of sites/individuals committing to release OR test tar balls/packages for a given platform. I believe that something could be arranged to build a TAR ball at CRIUGM for MAC OS 10.6 for example. I can certainly commit to make tests for all releases of the bundle on a fresh Ubuntu system before release. We would need a tutorial to build a complete MINC bundle with static libraries such that end users can just download, run an installation script/install package, and have the full MINC suite up and working.
> 
> 2. I/O
> 
> The libraries to manipulate MINC in C are a bit difficult to use. And there are no tools easy to install to manipulate MINC in the major data analysis languages, say R, Python, Octave & Matlab. There are efforts in these directions : I am myself working on something for Matlab/Octave to replace EMMA, I know that Vlad has an alternative C library (EZminc), Jason/Jim have developed I/O libraries in R and there are efforts towards MINC integration in NiPy. Those efforts are important but may not be sufficient. 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. Confining MINC tools to the MINC format is I think a mistake. That would involve redesigning the I/O C library to make use of MINC or NIFTI transparent for the coder. I have developed something like that in NIAK, and it works well. 
> 
> 3. Community of developers
> 
> Current changes made to MINC are essentially maintenance rather than integration of new methods. There are actually new methods being developed, but they don't necessarily make it to the CVS repository (e.g. ITK-SNAP, ELASTIX). There is currently no roadmap for the future. How can we be aware of current initiatives such that we can give feedback / participate ? How do we prioritize areas of developments ? What new developments should be included in the MINC bundle and which ones should not ? The developer mailing list is not super active. There has not been a workshop for years. There are no mechanisms like in google code or (better) track to define milestones, open tickets, prioritize, assign tasks, review commits etc. Students are not encouraged to commit changes and new tools. Developing for the MINC tools may simply not be attractive enough, notably because of issues 1&2 above.
> 
> Those 3 points are closely related, because as long as MINC is not easy to install and interface with new code (points 1/2), it will not attract users/developers. If the package does not include new method, it will die. I still believe MINC has the potential to remain one of the best available image analysis libraries around for the years to come, but it needs an electroshock. Dedicated resources (like one full-time maintainer/developer) would help a lot, but I believe the points 1-3 can be addressed by the community as it is today with proper organization and enthusiasm. 
> 
> I am curious to hear what you guys think about all that. 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
> 
>