MINC/历史
< MINC
MINC 最初是由彼得·尼林在史前时期（1992 年）编写的。这是他对 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.
这是他对 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.
随后，彼得·尼林维护并为 minc 库编码了 10 年或更长时间，之后将控制权转交给当前的 MINC 作者组。