There is definately a problem here.

> after my mail to the list on monday about different results with 3D or 4D
> images I did some further test which lead me to the assumption that the 4D
> support in SPM is broken or at least totally different to 3D support.
>
> I took a 2 volume 4D-nifti file (orig.nii) that was coregistered to a
> structural image (struct.nii) but not realigned yet.
>
> I split this image using fslsplit to split0000.nii and split0001.nii then
> took spm5 (rev958) and glued them back together ->4d.nii
>
> Now I did the realignment (to first image) separate for each volume pair.
> The results (rp_*.txt files) were totally identical for the 4D files but
> slightly different for the 3D files.

The 0.13E-06 errors are to be expected because the orientations are saved in 
the NIFTI headers for the 3D volumes (32 bit single precision floating point) 
but in .mat files for the 4D (64 bit double precision floating point).  
Accuracy of single precision representation is only one part in 8388608 
(whereas double precision ius accurate to one part in 4.5036e+15) so slight 
differences in the values shown in the rp_*.txt files are normal.


>
> I now used the struct_seg_sn.mat to write normalised images of the 3 pairs
> and compared the first normalised volume of the 3 pairs.
>
> The normalised 4D-images (worig.nii and w4D.nii) were totally identical,
> but the intenisty of the wsplit0000.nii was 1% higher because of a
> different scaling. While this should only be a scaling issue I still have
> the different results described in my last mail. So I am not sure if
> results with 3D-image are comparable with those of 4D images.
>
> I also did some other more extensive tests that support this: As dicomnifti
> creates a different orientation than spm-dicom-convert, I converted a data
> set with dicomnifti and fslsplit (4d_dini.nii+ 3d_dini*.nii) and with spm5
> + 3d-to-4D conversion (3d_spm.nii+4d_spm*.nii) resulting in 2 3d and 2 4d
> dataset. After the identical preprocessing I get virtually the same results
> within the 3D and the 4D data sets but totally different results between 3D
> and 4D results. I attach a pdf documenting this.


The reason for the discrepancy is that SPM currently uses spm_write_vol.  Data 
that is represented by integers (eg int16) has an associated scalefactor, and 
spm_write_vol currently attempts to determine the appropriate scalefactor so 
that the maximum range of integer values is used.  This works fine for 3D, 
but for 4D, it can only rescale according to the intensities found in the 
first 3D volume written.  This leads to truncation of the intensities if the 
maximum intensity in subsequent volumes exceeds that of the first volume.

I've just created a fix for this, which is currently being tested.  Resliced 
or spatially normalised data are now written with the same intensity scaling 
as the original data.  Note that a possible side effect of this is that if 
the dynamic range of the images is not very high, then smoothing is likely to 
cause a loss of precision if the output is written as one of the integer 
types. There should have been some incompatible scalefactor warnings 
appearing as a result of the problem.

I would recommend not using 4D data with the current version of SPM5 - unless 
the data is stored as one of the floating point formats.  The problem 
manifests when reslicing realigned images, and also writing spatially 
normalised data.

Best regards,
-John


> On Wednesday 24 October 2007 16:47, John Ashburner wrote:
> > 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,