MINC/Future/Actions201102

Initial List of action items to improve MINC

Make list of code/programs/packages available

We need to generate a list of all software tools written with MINC that have been created (in the BIC or elsewhere). For each item in the list, we need to know at least

• the name of the software
• a short description of what is does, list of functions, list of parameters
• who is the author of the software
• who maintains the software
• is the software publicly available? and if not, can if be made available?
• is documentation available? and if so, where is it
• is the software stable or still in development (if the former it could potentially be in a massive MINC bundle).
• what are the software's dependencies
• minc1/minc2 compatibility

• need makefile for all of minc tools (Vlad has a build all makefile)
• need makefile to build minc library only (subset of Vlad's makefile)

an initial list of minc tools is here

Make a list of documentation available

For each piece of documentation,

• what software or process does it document
• who wrote the doc, who maintains the documentation
• user doc or tech doc
• rating for the documentation (quality control, reviewed by pro)

Need plan for future documentation

• wiki.bic.mni.mcgill - should be open to the outside (I think)

I am not adverse to using a BIC hosted site for documentation but would prefer a most "neutral" hosted site to encourage others to contribute. - AJ

If we are to use NITRC as the main host of MINC, why not use the NITRC wiki as a developer's wiki for technical stuff, early stubs of documentation and discussion pages like "the future of MINC". I suggest that the MINC wiki book should be reserved to clean, stable and user-oriented documentation. BTW, it would be good to be able to produce a PDF as well. - PB

• need examples of good documentation to use as a guide

FSL has good docs

SPM on wikibooks - http://en.wikibooks.org/wiki/SPM - AJ

Check out the NIAK pdf overview - http://www.nitrc.org/frs/downloadlink.php/2726 - PB

any other examples?

• API docs vs USER guides

they serve very different purposes. users could be engaged to write user manuals

• need to find out what documentation already exists
• Training / courseware

a first step would be a workshop for existing minc users & developers. I volunteer to help set that up in June soon after or before HBM (probably after). We would probably need better documentation and a clear idea of what softwares can be considered part of the MINC suite before organizing an actual minc course, but this clearly could happen in the near future. - PB

• need a good MINC preamble

why is MINC worth the trouble? what makes it so good?

there are two "introduction" and "history" section on the wiki book. It might be better to merge those. - PB

Evaluate NITRC as a host of MINC tool development

We need to evaluate NITRC ( http://www.nitrc.org ) to host the MINC development project. We need to know

• does NITRC use a distributed version control system

Yes, GIT. I have already done a little test project with mincmorph and it works well. GIT is not yet integrated into their source code viewer thing but it is planned. At least with GIT you can clone to multiple repositories. (https://github.com/andrewjanke/mincmorph)

• does it allow a forum? a wiki?

Yes and Yes. And the wiki on NITRC would be a very good place to host discussions like this -AJ Agreed - PB

• any licensing issues?

Not that I can see. In addition, there is no restriction on the license you use for your own package -AJ

• does it have a long future?

I have been recently involved in a conference call re the future of NITRC. They are definitely going to be around for the next couple of years. It seems that the NIH is not ready to support them fully in the long term, but they are actively working on an alternative economic model (maybe involving fees or ads) for the future. They are apparently very much commited to exist as a long-term resource. - PB

• any issues wrt NeuroDebian ( http://neuro.debian.net )

None, you will note a number of MINC packages in there already (N3, mni_autoreg, minc, classify?) I helped Michael with these many years ago and have always meant to get back to it in deference to my own packaging. I see neurodebian as the way forward for minc packaging at least for debian/ubuntu. My plan was then to use alien to convert these to RPM's for the distro impaired. (CentOS, RedHat, Fedora) - AJ

Basic strategy for MINC tools development

• development of code / potential need for coding guidelines
• documentation for code
• testing suite
• packaging
• MINC1 vs MINC2 support

Multiplatform development

• Platforms to be supported
  • Linux (ubuntu, debian, redhat?, what else?)
  • MAC
  • Windows (see below, next item)

I dont think native windows packages are worth the pain they invoke. It's all fine to get the core packages working but we will suddenly find ourselves re-packing parts of CPAN for ActiveState Perl (Perl on windows) to make all the various perl scripts work. That and things like grid engine is just not possible. The only real alternative here is Cygwin, but the packaging system leaves things to be desired. For one there is no way to automate an install with a script, it HAS to be point and click in the first instance. You can then install apt-cyg manually and script the rest from there. The approach of other major packages has been to suggest that windows users use a virtual machine. Most CPU's are now plenty powerfull enough to do this and it will make things a LOT easier for us. We can also piggyback on the neurodebian efforts in this area. -AJ

• how to achieve multiplatform support
  • CMAKE? Cpack?

MINC already supports CMAKE, I will admit its a bit of a pain to keep both CMakeLists.txt and Makefile.am/Configure.ac up to date in parallel but I have been doing it. -AJ

• • what are the options?

None. automake/CMAKE is the choice. I still prefer automake as it integrates with deb a whole lot better. -AJ

If you want to support Windows, to any extent, CMake is a much better choice, because you only need to maintain the one CMakeLists.txt file, and from that CMake can generate Visual Studio project files (and Xcode projects on Mac OS X). --anon

• resulting packages must be easy to install
• resulting packages must not conflict with existing software

On this note, there are other packages out there (I'm looking at you freesurfer) that install a whole minc "distribution" as part of their install and cause all sorts of grief for users as they often contain older versions of the MINC. We have no real way of controlling this. The only "fix" is to add /usr/local/bic/bin after freesurfers path. Still perhaps if we make our own install a whole lot easier then freesurfer would just use our packages. -AJ

Evaluate pertinence of a MINC Windows .dll

• basic MINC API should be supported on windows
• we probably don't have the resources to support windows
• Bert has already done this. See Makefile.msvc-win32 in MINC CVS. It still works with Visual Studio but with Bert now gone I dont see us having the local expertise. (Bert was an ex-windows programmer, we did what we could for him). Still I question the motive of getting the minc API working in Windows. The only use I can see is so that a windows viewer could load MINC files. -AJ

re use of minc in windows : if we want minc to be widely used as a file format, it should be easy to interact with on a variety of plateform. For Matlab, it's either I have access to mincheader, rawtominc and minctoraw, or I code something directly based on netcdf/hdf5, which raise some concerns about full compliance to the MINC API.

Determine how CBRAIN fits in

I can't speak for Alan, but I would rather say that MINC fits in Cbrain. Cbrain offers a distributed platform for neurimaging analysis. MINC-based pipelines should be available in there (CIVET already does, NIAK fmri pipelines soon will). But Cbrain is not limited to the MINC tools (SPM for example is already integrated to some extent, maybe PLS and NPAIRS too, I am not sure. There are some talks about FSL-based pipelines). I believe there may be ways in which the Cbrain infrastructure could contribute in the future to the development of MINC-related software. This will depend very much on the type of funding that will be found to continue supporting Cbrain, and this is not settled at this stage. - PB

Evaluate level of NIFTI support within MINC API and MINC Tools

We need to evaluate the pros and cons of supporting NIFTI files within the MINC environment

points:

• need to verify/test nii2mnc to make sure floats properly supported
• do we want to read NIFTI files with MINC{1,2} API
• conversion nii->mnc and mnc->nii is not a serious overhead; but still a pain for some click&point users

pros:

• could give minc access to lots of users
• There is already a stub function in volume_io to do this.

cons:

• issues with file compatibility in intensity mapping
• issues with spatial coordinate mapping
• MAJOR issues with user understanding of how they can control L-R neuro/radio mapping in their files. I do not want MINC to enter or indeed even entertain the thought of entering this world of pain and gnashing of teeth. I already have users telling that they "dont like MINC because the images display 'funny'". ie: in neuro orientation.. -AJ