If you can display the images in SPM5 and they appear to be OK, then it
probably isn't an endian issue. In the NIFTI images used by SPM5, the
origin information has moved to another part of the header, so you can't
compare this way.

The problem is most likely because the patterns of signal intensities in
dynamic PET images changes dramatically over time. This means that the
least-squares objective function does not work so well. Very early
frames are also likely to be pretty close to pure noise, so there is a
good chance that the registration drifts off entirely. Where there is
no overlap of the field of view with one or more of the images, these
regions will be set to zero in all images in the time series. This is
probably what happened with your data.

The solution to these problems would involve combining registration and
time series fitting in the same generative model. There is a high
demand for such a solution, so I'm surprised that nobody seems top have
done this yet.

Best regards,
-John

-----Original Message-----
From: SPM (Statistical Parametric Mapping) [mailto:[log in to unmask]]
On Behalf Of Mark Daglish
Sent: Friday, September 15, 2006 11:01 PM
To: [log in to unmask]
Subject: [SPM] 4D dynamic PET realignment problem

Dear All,

I am trying to use SPM5 (update 573) to realign / motion correct a 4D
dynamic PET image. The image is in Analyze 7.5 format with 26
consecutive frames of 128x128x95.
I can display these images in SPM5 or SPM2 and the origin is reported as
[0 0 0], presumably because it is not set.

If I use SPM5 to realign frames 5-26 then the image will no longer
display properly. (I don't want to realign the first 4 frames.) The
origin is reported as [512 512 0]. This happens even if I select
"Estimate" as the realign option, and only create a mat file with no
reslicing.

If I look at the hdr with spm_read_hdr, the origin in hdr.hist.origin
goes from [0 0 0 0 0] to [512 512 0 63 -32768].

I suspect this is some sort of endian problem. The images are created
originally as big-endian (Sun/SPARC) but I am working on little-endian
(x86/Linux).

The date on the header file shows it was modified at the same time as
the mat file was written.

Any help to solve this would be really appreciated.

Regards,

Mark