MINC/History

A step back in Time

MINC was originally written by Peter Neelin back in the dark ages (1992). Here is his original "Justification" for MINC:

 We have been using netCDF for over a year now for medical imaging and
 have found it to be a good basis for a file format in a development
 environment. It's great when you have to get in and muck around with
 files; I don't know what it would be like in a commercial environment
 with image databases, PACS, etc. I say that it is a good "basis" for a
 format because it does have some limitations, both in general and for
 medical imaging. We have developed an extension called "minc" (Medical
 Imaging NetCDF) that tries to overcome these limitations. I'll give
 you a brief description of the motivation for minc and what it adds to
 NetCDF.
 
 The limitations of NetCDF (in no particular order):
   1) No conventions for medical imaging : A pretty obvious one since
         NetCDF is a general data format, but one still needs to come up
         with some variable/attribute names and other conventions.
   2) Some important areas have unclear or inadequate conventions :
         The best example is scaling for images. If you put all your
         images in one byte variable (that is subscripted over time, z, y
         and x, for example), then NetCDF only allows a global scaling
         to functional values for all images. Another example would be
         the inability to specify the fact that pixels in an image are
         regularly spaced.
   3) Low-level interface only : There are lots of things missing from
         the interface at the low-level (no automatic type conversion,
         etc.), and there is no high-level interface (can I load a
         volume in one call?).
   4) Lack of generic applications : I gather that they are working on
         them, but I haven't seen any. There are no medical imaging
         specific applications. Again, no surprise, but users need
         them (resampling volumes is perhaps the most used application
         that we have).
 
 What minc gives you:
   1) Conventions for medical imaging : Attributes based loosely on
         ACR-NEMA elements (at least those that I thought were the
         most important). Dimension names, variable names, etc.
         Conventions for world coordinates (again based on ACR-NEMA).
         I haven't yet looked into DICOM (successor to ACR-NEMA), but
         I expect it to be very similar.
   2) More conventions : Image scaling. Extra attributes for dimension
         variables. Handling of unknown values (e.g. resampled pixels
         that lie outside the original volume). A scheme for a
         hierarchical ordering of data in a file.
   3a) Medium-level interface (C and Fortran) : Adds useful stuff like
         type conversion and other simple operations. Routines for
         simplifying use of some minc conventions. Automatic pixel
         conversion and image resizing (e.g. I want pixels in the
         range 0 to 200, regardless of what is in the file; I have an
         old application that insists on 256x256 images).
   3b) High-level interface (C only) : Load a volume. Get
         voxel-to-world transformation. Macros to get pixel values
         and/or functional values. General transform routines. Etc.
   4) Generic applications : Resampling, header editor, rawtominc,
         minctoraw, header info, general transform programs. I hope to
         add some more in the next few months: reshaping the image
         variable, concatenating files, smoothing images, converting
         some minc conventions to NetCDF (scaling and dimension
         coordinates).
   5) Not enough documentation yet. (3a) has some documentation, (3b)
         has no docs, (4) has some. There is no overview or easy
         introduction.
   6) Built and maintained on SGI (Irix 4). Should compile out of the
         box on SUN (SunOS 4.1.3) (without FORTRAN interface).
         Compiled on SGI (Irix 5). Compiled on VAX (VMS), but hasn't
         been tested recently (and no simple build procedure). I don't
         have access to any other machines (except an IBM RS6000 that
         isn't running properly), so that's it. I think that someone
         is giving it a shot on a PC but I haven't heard back (I tried
         to avoid problems with shorts, ints and longs, but some parts
         are bound to have problems with MS/Borland compilers - should
         work with gcc).
 
 Because of the lack of documentation in certain areas, I haven't yet
 made minc available through anonymous ftp. If you are interested, I
 can make the current version available for you.
 
 Some other notes of interest: Now that NCSA HDF has a NetCDF interface
 I want to look into that (particularly since there is explicit Mac
 support from NCSA, but not UCAR). The new Xmosaic can read NetCDF
 headers. NetCDF is really good for machines with IEEE representation,
 but apparently there are speed problems with CRAYs.

And here is his original sales pitch for MINC:

 Minc (Medical Image NetCDF) came out of a frustration with a
 proliferation of image file formats within our lab. Not only did each
 modality and scanner have a different format, but almost every
 programmer had their own. One of the original design goals was to have
 a format that was general enough to keep all of the programmers and
 users of different modalities happy. As well, we wanted a standard API
 so that we could be reasonably sure that programs could exchange data
 without trouble. 
 
 The decision was made to build the format around the NetCDF general
 data format (although it was originally designed for use in the
 atmospheric physics community, it is a general data format). This
 format is reasonably simple, extremely general, self-documenting,
 easily extensible by users and portable. By simple, I mean that the
 basic data structure is a multi-dimensional array, called a
 variable. All components of a NetCDF file are named, which means that
 the format is self-documenting. The variables in a file are related to
 each other by the use of named dimensions and can have associated
 attributes (strings or numbers). This simple set of concepts is easily
 applied to a broad range of data. A standard API ensures that access
 is only done through names (so the format is easily extended by adding
 new variables and attributes) and that data are always correctly
 stored in a form that allows transparent sharing across very diverse
 machine architectures. 
 
 Minc adds to this a number of things: First of all, it adds concepts
 and conventions at a higher level that ensure that data can be
 exchanged between programs. Simple conventions like how to store
 patient or acquisition information with standard names (many of these
 fields have been borrowed from the original ACR-NEMA documentation),
 and more complex concepts like the distinction between data (voxel)
 sampling grids and real-world coordinate systems that are independent
 of images. Beyond that, it adds a medium-level library for
 facilitating the use of the conventions and for doing things like
 automatic data conversion and file decompression, a high-level library
 for encapsulating a whole dataset in a simple internal structure (a
 volume can be loaded with a single function call), and a series of
 very general file manipulation programs and generic applications.
 
 These applications include conversion from scanner formats, raw data
 import/export, resampling, averaging, simple math, concatenation,
 reshaping, lookup table conversions, transform manipulation,
 coordinate conversion. As well, many specific user applications have
 been developed: 3D display and manual segmentation, 3D display
 (tri-slice) for manual registration and image merging (fusion),
 automatic registration, blurring, statistics (within volume and across
 volumes), intensity normalization, MRI RF inhomogeneity correction,
 image simulation, image classification and the list goes on (a
 dangerous list to make since it inevitably misses things and I risk
 offending people!). Furthermore, a matlab interface has been developed
 that allows us to interact easily with the data and which helps speed
 the development and prototyping of algorithms.
 
 We have used minc to store MRI images (3D and 4D), CT images (3D), PET
 images (3D and 4D), SPECT images, macrocryotome images (very large 3D
 RGB volumes), voxel labels, voxel probability maps, statistical
 fields, N-dimensional histograms, images in fourier space, deformation
 fields, etc. Any N-dimensional grid-based scalar or vector data can be
 stored in a minc file (NetCDF has a default limit of 32 dimensions and
 minc requires at least 2 dimensions so that we can talk about an
 image). Data types include byte, short, long, float and double with
 conversions done transparently.

Peter Neelin then maintained and coded for the minc library for the next 10 years or more at which point the reins were handed over to the current group of MINC authors.