Hi John and List,
I was unsure about SPM5's ability to handle 4D nifti files, so I wrote a
quick function (see the attached file, spm_4dto3d.m) to convert 4D files
to 3D. Would this function be affected by the problem described below?
I don't think it would be but I just want to be sure. Also I wanted to
pass along the function in case it is useful to anyone else.
Thanks,
Matt Senjem
-----Original Message-----
From: John Ashburner [mailto:[log in to unmask]]
Sent: Thursday, October 25, 2007 7:00 AM
Subject: Re: 4D-support broken? was: [SPM] 5D NIfTI files, @nifti class
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,
|