Author: Cinly Ooi (---.psychiatry.cam.ac.uk)
Date: 10-25-07 11:20
> Are there any limits on the sizes of NIfTI files, for example
> if the number of voxels, elements, or bytes exceeds the
> capacity of the int32 data type?
This answer is probably depends on your operating system
In C, your theoretical limit is what size you can pass to malloc(). malloc actually takes a size_t, so your max is the max value of size_t. size_t is normally an unsigned integer type, unfortunately for you and me, size_t is implementation defined. However, we can assume to be at least uint32.
Of course how size_t translate to the number of voxel is dependent on your data type. You can store double the max limit for NIFTI_TYPE_FLOAT64 for NIFTI_TYPE_FLOAT32
The next question is whether your nifti routine can handle this. Your routine might artificially restrict you to smaller maximum size because you used "int" instead of size_t but this can be overcome by replacing the routines.
5D dataset, i.e., dim[0]=5 have special meaning in NifTI specs.
Given speed penalty penalty, programming penalty (difficult to find enough continuous memory to hold full 5D dataset, long time to access particular 4D dataset coz you have a large offset value), management penalty (need to copy 5D data from A to B because you need only one dataset), even if possible, I advise against storing 4D data of multiple subject as one nifti dataset.
Continuing from previous paragraph, if you find that you are hitting the limit for a N-D data, you are extremely likely to be better off storing data as N files of (N-1)-D data. Again this is for speed/programming/management reason. More importantly, hitting the limits means your data is less likely to be portable, as different applications can have different limits. Ditto for any program you write. Remember that different compiler can have different limit for size_t.
> This is particularly relevant for 5D data. In 3D, an int32
> limit could be surpassed by 1300x1300x1300 voxels, but this
> very large by current standards; however, consider a 5D dataset
> of multivariate observations for a number of subjects. As one
> example, data with 180x180x180 voxels (not unreasonable for
> 1mm-isotropic MRI, and high field structural MR could easily
> exceed this), 64 subjects, and multivariate 6-vectors stored at
> each voxel would have more elements than int32 can count. As
> another example, a 4D time-series of (univariate)
> single-precision floating-point data for 100 scans of the same
> voxel dimensions would have more *bytes* than int32 could
> index. These examples don't seem completely outrageous... but
> I'd be interested to hear what others have to say...
Let's wait for this becoming a real possibility. It is difficult to discuss things like this without a real-life example. We need a real life example in order to understand all the implications/issues (speed, failure to allocate enough continuous space etc) and find a trade-off with these issues.
> Possibly everything should be okay as long as individual
> dimensions are within the integer limits, which would almost
> always be true, but I wonder if many implementations might
> combine the five dimensions to create a single int32 index for
> the elements? What does the canonical nifti c-library do?
Let's not bother with what nifticlib until someone is about to hit the limit and there is no way to tune down his/her data size requirement. It is stupid to design any library for extreme cases that is unlikely to occur.
I am aware of some processing actually hits the 2GB (32 bit OS) limits. But it has nothing to do with NifTI, which is a data format. Rule of thumb: if you don't write to disk, NifTI need not apply.
HTH
Cinly
|
|
