[MINC-users] The future of MINC

[Sean McBride]

On Sat, 5 Feb 2011 10:17:42 -0500, Jason Lerch said:

>The dirty secret, such as it is, is two-fold as far as I understand it
>(and I might very well be missing something obvious too).
>
>* while I don't doubt that you can get a correct MINC implementation by
>making all the appropriate NetCDF and HDF5 calls, the risk of avoiding
>the MINC libs is that subtly incompatible volumes will be created which
>we then have to work around in the future. This can be avoided with some
>care, I'm sure, but has the potential to be tricky.
>* the more important one is forward incompatibility. Any desired change
>to how MINC reads and writes volumes (such as the switch from NetCDF to
>HDF5) will now have to consistently be coded in more than one place.
>Having the MINC2 lib not read MINC1 files already leads to enough
>mayhem, so the thought that going forward different tools will read a
>different range of MINC files scares me.
>
>So with that in mind we have to make libminc has ubiquitous and easy to
>install as possible so that a dependency on it causes little penalty. 

VTK's MINC reader/writer use NetCDF directly:

<http://vtk.org/gitweb?p=VTK.git;a=blob;f=IO/
vtkMINCImageReader.cxx;h=59e630aa7545b7906130655357efc3d09e01ee71;hb=HEAD>

IIRC, the reason was exactly because building libminc has several
dependancies and is a pain to build.

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada