 |
 |
> Thank you very much for the thorough explanation John. > so in a proper NIFTI image, you can distinguish radiological vs > neurological orientation by just using the transformation matrix. > is that true? Yes - providing the correct data has been included in the NIfTI headers. If you wish to check what orientations SPM is assuming, then try typing the following in MATLAB: help spm_orientations spm_orientations Best regards, -John > On Fri, 2010-05-28 at 07:56 -0700, John Ashburner wrote: > > In proper NIfTI images, the orientations are represented by a > > voxel-to-world mapping, which maps indices of voxels to mm coordinates. > > SPM can still read the old ANALYZE format images, but if it changes the > > headers or writes any new images, then the format will be changed to > > NIfTI. > > > > So, if ANALYZE images are used initially, it is up to the users to > > ensure that SPM is told what the correct orientation of these images is > > (because any derived images will be in NIfTI format and the NIfTI > > headers will contain the same information). The > > spm_flip_analyze_images.m function is ignored once images are in NIfTI > > format. > > > > The Display button allows you to click on different parts of the image, > > and it shows the mm coordinates (as well as voxel indices). SPM (and > > other NIfTI compliant packages) assume that the right side of the images > > has larger (or more positive) x coordinates (in mm). > > > > To answer your question, the voxel-to-world mapping is encoded in two > > ways: sform and qform. SPM primarily uses the sform, and generally sets > > the qform to have the same values (the exception being those images that > > have been imported for registration with Dartel). These fields are > > documented at http://nifti.nimh.nih.gov/nifti-1 > > > > > > Occasionally, people notice what they believe to be a left-right mix up > > when they use the slices option from the results. This is really a > > feature rather than a problem, as the idea here is to show the original > > slices in the image. For example, if the images are stored saggitally, > > then saggital slices are displayed - even if the voxel-to-world mapping > > indicates the correct transform to axial. Similarly, axial or coronal > > slices are displayed according to how they are actually stored in the > > image. > > > > Best regards, > > -John > > > > > > On Thu, 2010-05-27 at 16:26 -0400, [log in to unmask] wrote: > > > Dear John, > > > > > > In what variable of the NIFTI header is this info represented? > > > > > > Thanks, > > > Eric > > > > > > Quoting John Ashburner <[log in to unmask]>: > > > > > > > SPM assumes that the image orientation is what the data format says it > > > > is. If the data were to be correctly converted to NIfTI format, then > > > > SPM should handle them perfectly fine. With the older ANALYZE format, > > > > left-right orientations are not specified in the headers, so SPM needs > > > > to be explicitly told what the orientations are. > > > > > > > > Best regards, > > > > -John > > > > > > > > > > > > On Tue, 2010-05-25 at 17:05 +0100, Stephen Paisey wrote: > > > >> Dear Developers and users, > > > >> We have imaged rats with a brain lesion on the right hand side on a > > > >> Bruker scanner using Paravision 5.0. I have then used analyze 9.0 > > > >> to convert the raw bruker files into and img/hdr file pair. The > > > >> images in analyze 9.0 are displayed the correct way around but when > > > >> I load them in spm5 (i am using this version for its compatibility > > > >> with the spmmouse extension) i get an image which has been left > > > >> right inverted i.e. the lesion is now on the left side of the > > > >> brain. I can get around this by flipping the image the wrong way > > > >> around before i read it into spm but this is clearly a bug which > > > >> could lead to totally wrong experimental results. It is lucky i had > > > >> non symmetrical rats otherwise i probably wouldn't have spotted > > > >> the error. > > > >> > > > >> Best Regards > > > >> > > > >> Stephen > > > >> > > > > > > > > -- > > > > John Ashburner <[log in to unmask]> > > > > > > > > > > > > > > > > > > > > > -- John Ashburner <[log in to unmask]>