The .mat and .mat0 fields in the SPM5 routines account for the one voxel
offset in the indexing. In MATLAB, voxel 3,4,5 will be at location (in mm):
>> mat = [0.8600 0 0 -33.9700
0 0.8600 0 -48.5900
0 0 0.8600 -32.2500
0 0 0 1.0000];
>> mat(1:3,:)*[3 4 5 1]'
ans =
-31.3900
-45.1500
-27.9500
Using the qto_xyz matrix and indexing as in C, the equivalent location is by:
>> mat1 = reshape([0.86 0.0 0.0 -33.110001 0.0 0.86 0.0 -47.73 0.0 0.0 0.86
-31.389997 0.0 0.0 0.0 1.0],4,4)';
>> mat1(1:3,:)*[2 3 4 1]'
ans =
-31.3900
-45.1500
-27.9500
So I don't see a problem.
By the way, there is a hidden "hdr" field (for debugging purposes) in the
nifti object. Try:
Ninput.hdr
All the best,
-John
On Wednesday 30 April 2008 11:42, Matthew Brett wrote:
> Hi,
>
> Is it possible you are looking at the +1 necessary to change from 0
> based to 1 based indexing into arrays (C vs matlab)?
>
> Matthew
>
> On Wed, Apr 30, 2008 at 11:36 AM, Alle Meije Wink
>
> <[log in to unmask]> wrote:
> > Dear all,
> >
> > The NifTI file that I try to open in matlab has qform_code set to one.
> > When I look at the NifTI header with nifti_tool (supplied in the NifTI
> >
> > reference library) it says:
> > > qoffset_x 200 1 -33.110001
> > > qoffset_y 204 1 -47.73
> > > qoffset_z 208 1 -31.389997
> > > qfac 212 1 1.0
> > > qto_xyz 216 16 0.86 0.0 0.0 -33.110001 0.0 0.86
> > > 0.0 -47.73 0.0 0.0 0.86 -31.389997 0.0 0.0 0.0 1.0 qto_ijk
> > > 280 16 1.162791 0.0 0.0 38.5 0.0 1.162791 0.0 55.5 0.0 0.0
> > > 1.162791 36.499996 0.0 0.0 0.0 1.0
> >
> > In words: voxel size .86 x .86 x .86 mm^3 and offsets to the centre of
> > gravity of (tx,ty,tz) = (-33.11, -47.73, -31.39) also in mm.
> >
> > When I load it as an SPM5 nifti object, I get:
> > > >> Ninput.dat
> > >
> > > ans =
> > >
> > > fname: '/tmp/transformed.nii'
> > > dim: [78 112 74]
> > > dtype: 'INT16-LE'
> > > offset: 352
> > > scl_slope: 1
> > > scl_inter: 0
> > >
> > > >> Ninput.mat
> > >
> > > ans =
> > >
> > > 0.8600 0 0 -33.9700
> > > 0 0.8600 0 -48.5900
> > > 0 0 0.8600 -32.2500
> > > 0 0 0 1.0000
> >
> > So voxel size .86 x .86 x .86 mm^3 but offsets (-33.97, -48.59, -32.25).
> >
> > The onli way that I can track this back to the original NifTI header is
> > this. Even assuming that the offset is computed as
> >
> > > [ dim(1)/2*pixdim(1) dim(2)/2*pixdim(2) dim(3)/2*pixdim(3) ]
> >
> > then it would have to be
> >
> > > [ -33.54 -48.16 -31.82 ]
> >
> > What seems to be computed instead is (!!!)
> >
> > > [ (1+dim(1))/2*pixdim(1) (1+dim(2))/2*pixdim(2)
> > > (1+dim(3))/2*pixdim(3) ]
> >
> > which makes no sense at all!
> >
> > What I'm curious about is:
> > * Was this computation of the .mat field intended?
> > * Is there a way to get the q-form from a nifti-object?
> >
> > Cheers
> > Alle Meije
|