Nope - from a C perspective it would be +2!
Alle Meije
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
>>
>
|