extending_nifti
extending_nifti > RE: Extending NIFTI Discussion
Feb 28, 2011 11:02 PM | Gael Varoquaux
RE: Extending NIFTI Discussion
Originally posted by Satrajit Ghosh:
Indeed, I agree with Satra that as data gets bigger and computing power increases faster than bandwidth, storing huge data to disk is going to become more and more of a bottleneck. In other words, I/O on large data files will be very problematic soon.
Two methods are usually employed to mitigate these problems. First making the data access local on the disk. This requires abandonning the hyper-cube representation for storage and saving the data as blocks, or chunks, that can be sliced locally on the disk in every direction.
Second, compression, if it is implemented with a seekable and stream-capable compression algorithm (not gzip), can render the I/O faster. Both approaches can be combinned.
Optimal implementation of the above suggestion is a lot of work. However, the HDF library has tackled these problems efficiently, and it already available in most scientific computing environment. As a matter of fact, even Mathwork, a company with huge resources, ditched their own I/O library to use HDF5 for the most recent data saving formats.
a. serializable compression and the ability to
operate on a single voxel/plane time-series or a single volume of a
4D-volume.
one option that addresses (a,b) is HDF5 (http://www.hdfgroup.org/HDF5/). the MINC2 (link) format uses HDF5 and is a good option to look into as a starting point.
one option that addresses (a,b) is HDF5 (http://www.hdfgroup.org/HDF5/). the MINC2 (link) format uses HDF5 and is a good option to look into as a starting point.
Indeed, I agree with Satra that as data gets bigger and computing power increases faster than bandwidth, storing huge data to disk is going to become more and more of a bottleneck. In other words, I/O on large data files will be very problematic soon.
Two methods are usually employed to mitigate these problems. First making the data access local on the disk. This requires abandonning the hyper-cube representation for storage and saving the data as blocks, or chunks, that can be sliced locally on the disk in every direction.
Second, compression, if it is implemented with a seekable and stream-capable compression algorithm (not gzip), can render the I/O faster. Both approaches can be combinned.
Optimal implementation of the above suggestion is a lot of work. However, the HDF library has tackled these problems efficiently, and it already available in most scientific computing environment. As a matter of fact, even Mathwork, a company with huge resources, ditched their own I/O library to use HDF5 for the most recent data saving formats.
Threaded View
Title | Author | Date |
---|---|---|
Mark Jenkinson | Feb 28, 2011 | |
Jon Clayden | Feb 11, 2013 | |
Cinly Ooi | Mar 24, 2011 | |
Andrew Janke | Mar 25, 2011 | |
Jon Clayden | Mar 5, 2011 | |
Satrajit Ghosh | Mar 5, 2011 | |
Satrajit Ghosh | Feb 28, 2011 | |
Andrew Janke | Mar 1, 2011 | |
Stephen Strother | Mar 5, 2011 | |
Gael Varoquaux | Feb 28, 2011 | |