MINC/History

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.