Hi John,
Sorry, I threw you a bit of a red herring there by mentioning spm_vol;
in fact, the problems I was having were with the nifti class library
under spm5/@nifti (SPM5 revision 958).
I now wonder if the problem is something to do with integer size
limits somewhere in the code... If you have time, please could you
check out the attached test script, which reproduces some errors that
I got.
I've just posted to the nifti message board about size limitations,
but I'm guessing it's more an implementation-specific thing. I'm not
at all familiar with the internals of the @nifti or @file_array
classes, but is it possible they have some 32-bit limits somewhere?
Many thanks,
Ged
> > I've tried to write a simple script that concatenates a bunch of
> > single-time 5D images into one 5D series, essentially looping over
> > time t and setting
> > im = Ims(t).dat(:, :, :, 1, :);
> > Out.dat(:, :, :, t, :) = im;
> > where Ims is a "NIFTI object: 1-by-t", and Out is a new NIfTI, with a
> > correctly sized 5D file_array dat (with a new fname, same data-type as
> > originals, and the standard 352 offset) and the other nifti fields
> > (mat, mat0, descrip and intent) are recycled from the input Ims(1).
> > All Ims have the same dimensions etc.
> > The merging process appears to complete without any errors, and the
> > result loads with
> > test = nifti('merged.nii')
> > and shows the correct dimensions. However, any attempt to access the data,
> > e.g. test.dat(1, 1, 1, 1, 1)
> > produces the error message:
> > ??? File is smaller than the dimensions say it should be.
> > Error in ==> file_array.subsref>subfun at 80
> > t = file2mat(sobj,varargin{:});
> > Error in ==> file_array.subsref at 60
> > t = subfun(sobj,args{:});
> > Error in ==> nifti.subsref>rec at 219
> > t = subsref(t,subs(2:end));
> > Error in ==> nifti.subsref at 45
> > varargout = rec(opt,subs);
> >
> > Which is confusing, not only because the simple merging code looks
> > okay to me, but also because the error message seems wrong... The
> > outputs from the following two lines are identical in this case:
> > test.dat.offset + prod(test.dat.dim)*4 % data is float32: 4bytes/voxel
> > file = dir(test.dat.fname); file.bytes
> >
> > More worryingly, when I use the same merge script on a fairly large
> > number of images (the above is a test with just three images), the
> > resulting 5D NIfTI really *is* smaller than it should be, by a
> > dramatic amount (i.e. 2Gig rather than 9Gig -- not just a few bytes
> > offset!).
