1 / 20

The future of MINC

The future of MINC. Robert D. Vincent bert@bic.mni.mcgill.ca. Outline. Background New features and functions Compatibility Programming and other nerdy stuff. Background. MINC is built upon a general format netCDF: Network Common Data Form MINC 1.0 is a specialization of this format

phuoc
Télécharger la présentation

The future of MINC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The future of MINC Robert D. Vincentbert@bic.mni.mcgill.ca

  2. Outline • Background • New features and functions • Compatibility • Programming and other nerdy stuff

  3. Background • MINC is built upon a general format • netCDF: Network Common Data Form • MINC 1.0 is a specialization of this format • NetCDF Disadvantages: • Not hierarchical • Limited data types • 32-bit file size • Simple, contiguous data storage

  4. Motivation for change • File sizes are increasing • Functional imaging, high-resolution anatomical imaging • May easily exceed 2 gigabytes • Efficient online viewing • Storage of multiple pre-computed resolutions • Richer data types • Vector, tensor, complex voxels • Labeled voxels

  5. Hierarchical Data Format 5 • NetCDF Disadvantages • Not hierarchical • Limited data types • 32-bit file size • Simple, contiguous data storage model • HDF5 Advantages • Fully hierarchical • Rich set of data types • 64-bit file size • Complex, powerful data storage model

  6. MINC 2.0 Features • Block-structured storage • Labeled volumes • Internal compression • Multi-resolution images

  7. Block-structured storage • Stores image in a series of N-dimensional blocks • May improve performance in some cases • Enables internal compression

  8. Block-structured storage • In an ordinary MINC volume, data is stored in a simple linear arrangement • Example: Simple 2x4x4 3D image 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 00 01 02 03 04 05 06 07 08 09 10… 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

  9. Block-structured storage • In block structured file, nearby voxels are grouped together • Example: 2x4x4 image with 2x2x2 blocks 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 00 01 04 05 16 17 20 21 02 03 06… 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

  10. Labeled volumes • Associates text labels with voxel values • Appropriate for classifier output, for example • 0 = “Background”, 1 = “White matter”, 2 = “Grey matter”, and so forth • Furthers the MINC goal of “self-describing” data files

  11. Internal compression • MINC 1.0 External compression • External program must decompress an entire file • File must be fully decompressed to read a single voxel • Uses temporary disk space, bandwidth, and time • MINC 2.0 Internal compression • Data is compressed on a block-by-block basis • Invisible to user, compression is internal to library • Nearly random access • Parts of the file may be left uncompressed

  12. Multi-resolution images • Applications • Visualization over networks • Multi-resolution algorithms • Design – Multiple image objects • Normal data stored at full resolution • Additional images stored at 1/2, 1/4, 1/8, etc. • Initially will use a simple voxel averaging algorithm • May be enhanced/replaced by us or third parties • Adds at most 1/7 of full-resolution size for 3D images

  13. Compatibility • MINC programs still support NetCDF • Input – Tools automatically “do the right thing” • Output – User must explicitly specify “-2” flag for HDF5 • MINC 1.0 “libminc” still supported • Minor enhancements, new flags • Some new functions • Very few changes to MINC 1.0 code • It might actually keep working!

  14. MINC 2.0 Programming • Philosophy • Formalize MINC 1.0 programming idioms • Provide a complete set of functions for manipulating image data • Backward compatibility • Design • http://www.bic.mni.mcgill.ca/software/minc2/api_doc-2003-10-31 • Initial implementation in “C”, with additional language bindings to follow…

  15. MINC 2.0 Programming • New concepts • volume type – image objects • Voxel data • Attributes • Dimensions • dimension type – individual coordinate axes • Orientation • Spacing

  16. MINC 2.0 Programming • MINC 1.0 • Functions tend to be very general • Many of functions serve multiple purposes • Programmer must understand both netCDF and MINC concepts • MINC 2.0 • Functions tend to be more specialized • Completely hides details of HDF5/netCDF • MINC 2.0 must define many more functions (129 and counting vs. less than 50)

  17. MINC 2.0 Programming • Example – get one “real” valued voxel • MINC 1.0 icv = miicv_create(); miicv_setint(icv, MI_ICV_DO_RANGE, TRUE); … miicv_attach(icv, fd, var_id); miicv_get(icv, coords, lengths, &value); • MINC 2.0 miget_real_value(volume,coords,3,&value);

  18. MINC 2.0 Programming • Example – direction cosines • MINC 1.0 miattget(fd, varid, Midirection_cosines, NC_DOUBLE, 3, cosines, &length); • MINC 2.0 miget_direction_cosines(dimension,cosines);

  19. The future of the future • Language support • Perl, Python, Java, C++ • New data classes • Geometric objects • Transform information • Additional compression methods • bzip2 • “Lossy” image compression

  20. Credits • Leila Baghdadi • Design, documentation, and programming • John Sled • Design, documentation, and sanity checking • Many others who have offered advice and opinions! • netCDF created by UCAR • HDF5 created by NCSA • Financial support from NIfTI

More Related