Dear John,


Thanks a lot; that's very helpful.

It sounds like all should be well IF my images in MNI space have the origin at the centre of a voxel, too. I note the new matrix for 1x1x1mm images in MNI space allows this as its extents are odd numbers in each dimension (181x217x181), but there are no 1x1x1 images released with SPM5.

So far, I have worked with the origin as written by SPM2 when normalising with a 1x1x1 output and the MNI matrix (already 181x217x181 in SPM2), namely 91 127 73. Obviously by going to the 1mm-cubic voxels, I have a whopping eight possibilities of placing the origin within the previous 2mm-cubic origin voxel - the 91 127 73 option sounded good as it was compatible with SPM2, but clearly I'm running into slight difficulties now, and from what you say I need even numbers for x/y/z.

As there is no predefined "template bounding box" option any more in SPM5 (so no default setting through which you define the "correct by convention" origin), I am wondering what your recommendation is?

Thanks a lot in advance,

All the best,

Alexander

-----Original Message-----
From: John Ashburner [mailto:[log in to unmask]]
Sent: 16 March 2006 13:08
To: Hammers, Alexander; [log in to unmask]
Subject: Re: [SPM] writing an image using *_seg_inv_sn.mat in spm5:
extra planes problem



> I use the *_seg_inv_sn.mat (i.e. derived from the fabulous SEGMENT module)
> to write images in MNI space into native MRI space. John's help details
> that for this to work, both the bounding box and the voxel sizes need to be
> set to something like NaN.
>
> This procedure works very well, except that the resulting images have
> exactly one plane more in each dimension than the native MRI.
>
> My questions:
> 1. Why does it do that? (If that's known, maybe we can stop it altogether).

Because it uses some old code from an older version of SPM where the origin
was rounded to the nearest voxel. The alternative was to either write .mat
files for spatially normalised images or to have the data mis-aligned by up
to half a voxel.

> 2. Where exactly are the planes added - x: right or left [or, less
> controversially, low x or high x ;-)]; low or high y, low or high z? (If
> that's known, I can remove them post hoc).

It's probably not as simple as that. The code that puts the images to the
closest voxel is at around line 460 of spm_write_sn.m
bb(:,1) = round(bb(:,1)/vox(1))*vox(1);
bb(:,2) = round(bb(:,2)/vox(2))*vox(2);
bb(:,3) = round(bb(:,3)/vox(3))*vox(3);

and line 476:
of = -vox.*(round(-bb(1,:)./vox)+1);

I haven't tested this, but commenting out the three lines around 460, and
changing line 476 to
of = -vox.*(-bb(1,:)./vox+1);

may do the trick. All the template etc data released with SPM has the origin
at a voxel centre, so I didn't encounter this one when testing.

Best regards,
-John