The problem arises for historical reasons. Changing from 3D to 4D files was
problematic enough, but it was still possible to do this via the current
spm_vol code, as extra volumes can be tagged on at the end. Unfortunately,
it's a bit trickier for 5D as the 4th and 5th dimension need to be specified
when the file is created. The spm_create_vol function only has arguments
that describe the 3D volume being written to the file, but none for the 4th
or 5th dimensions of the file that is to be written.
The eventual aim is to move over to the nifti utilities, instead of using the
spm_vol code - but this will take a while.
Best regards,
-John
On Wednesday 24 October 2007 13:44, DRC SPM wrote:
> Hi all,
>
> Does anyone have much experience with NIfTI data that has non-unity
> 4th AND 5th dimensions? spm_vol is happy with 4D time-series images,
> and with single-time-point 5D vector fields, but doesn't seem to like
> data with all five dimensions greater than 1.
>
> The SPM5 nifti class library seems happier, in that
> N = nifti('example5D.nii');
> reports the right dimensions etc. But I'm running into problems with it...
>
> 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. (they pass
> spm_check_orientations when loaded as volumes -- I have an updated
> spm_check_orientations that works with 5D NIfTIs if anyone is
> interested in it).
>
> 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!).
>
> I can't put my (possibly broken?) merge script online like I usually
> would, as I'm away from UCL at the moment, but if anyone would like me
> to email them a copy, just ask.
>
> Many thanks in advance to anyone who can shed any light on this,
>
> Ged.
>
> P.S. In case any of it matters, I'm using SPM5 Revision: 958, under
> Matlab r2006a, on Red Hat Enterprise Linux AS release 4,
