"Dir cos" refers to "direction cosines", which is one possible way of
representing rotations. If you take the simple case of rotating in the x-y
plane (i.e. about the z axis), then a rotation can be specified by
R = [...
cos(theta) sin(theta) 0
-sin(theta) cos(theta) 0
0 0 1]
Rotating a point [x0,y0,z0], to produce [x1,y1,z1] can then be done by
x1 = R(1,1)*x0 + R(1,2)*y0 + R(1,3)*z0;
y1 = R(2,1)*x0 + R(2,2)*y0 + R(2,3)*z0;
z1 = R(3,1)*x0 + R(3,2)*y0 + R(3,3)*z0;
Translations are done by augmenting the 3x3 matrix, such that
x1 = R(1,1)*x0 + R(1,2)*y0 + R(1,3)*z0 + R(1,4)*1
y1 = R(2,1)*x0 + R(2,2)*y0 + R(2,3)*z0 + R(2,4)*1
z1 = R(3,1)*x0 + R(3,2)*y0 + R(3,3)*z0 + R(3,4)*1
If you rotate by 180 degrees (i.e. theta=pi radians), then
R = [...
-1 0 0
0 -1 0
0 0 1]
So basically, one of your datasets was acquired rotated by 180 degrees.
Another way of thinking about it is that if you flip something twice in
different directions, then you would merely rotate it.
The DICOM conversion in SPM keeps each plane of data in the same orientation
as it was acquired. A .mat file is generated that encodes what this
orientation is. If your data are coronally acquired, then they will be
stored coronally. If you have saggital images, then they will be stored as
saggital. If you have axial, but rotated by 180 degrees, then they will be
stored axially and rotated. etc.
The way that an image is stored may depend on something as simple as the way
that the radiographer (or whoever did the scanning) drew various points,
lines etc on the screen, when setting up the scan. If drawn one way, then
the images will be acquired a certain way. If drawn another, then the images
will be acquired another way.
Sometimes, the way that an axial image is acquired is flipped. The conversion
keeps each plane in the same orientation. To compensate, it will reverse the
order the slices. This is analagous to flipping twice - i.e. rotating. This
ensures that the handedness of all the images remains the same.
If your "defaults.analyze.flip" global variable is set to 1, then the order
that the voxels are stored in the file will be left-handed. If it is set to
0, then the order of storage will be right-handed. Whatever value you have
in your spm_defaults.m file, the co-ordinates of the points in space will be
interpreted as right-handed. Take a look at
http://www.fil.ion.ucl.ac.uk/~john/misc/handedness.gif in order to understand
the difference.
When you segment, the printout just shows slices through the image in the
orientation that the data are stored on disk (this is also the case for the
"slices" option that you can use for superimposing results on an image). If
they are stored rotated, then this is how you will see them. After spatial
normalisation, the order that the voxels are stored will no longer be
rotated.
With the Display button, if any flipping of coordinates takes place, then this
would be encoded by a negative zoom, rather than by the direction cosines.
The negative voxel size in the x direction that most people see (i.e. those
who have defaults.analyze.flip=1), is there so that a left-handed order of
storage can be visualised in a right-handed coordinate system.
I hope this helps,
-John
> I am encountering a strange orientation problem with SPM2 after converting
> images to ANALYZE format.
> Perhaps someone could help me to understand what is going on:
> I have two sets of images (SPGRs), which were converted at different times.
> Both display correctly in SPM2 in the three view windows and the left side
> of the brain is on the left side of the displayed image.
> Dimensions: 124x256x256
> Datatype: Int16
> Intensity: Y=1X
> Voxel size: -1.5x0.938xx0.938
> are the same for both image sets.
> However, Dir cos is:
> 1 0 0
> 0 1 0
> 0 0 1
> for set number one and
> -1 0 0
> 0 -1 0
> 0 0 1
> for the other set.
> Although we kept the SPM2 default settings one image group changes their AP
> position on the spm2.ps file after normalization (VBM).
> So basically we get a print out for group one on the spm2.ps file like
> this: both times nose up in the 4 columns (T1,GM,WM,CSF) for the printout
> in native space and in MNI space.
> for the second group:
> nose down in native space and nose up in MNI space.
>
> I would like to know, what cos dir actually means and if such a flipping
> issue could cause problems.
|