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.