Hello,

Thank you for the wonderful acpcdetect (v1 and v2). It is working great for our dataset!
I would like to know if there is a way to derive the amount of pitch, roll, and yaw rotations that should be applied to the data once the AC and the PC voxel locations are detected? The idea is to include acpcdetect in some other preprocessing pipeline for which we would like to extract and use translations and rotations to shift the image origin to the AC (while ensuring that the PC lines up to the AC-PC line).

Thank you for your help


Best Regards
Pravesh

Originally posted by Pravesh Parekh:
Hi Pravesh,

I'm glad the program is working well on your data.   acpcdetect v2 outputs two rigid-body affine transformation matrices that contain this information.
*.mrx Transformation matrix for tilt-correction in ART format
*.FSL.mat Transformation matrix for tilt-correction in FSL format

The two matrices contain the same information in different format.  ART uses the FOV center as the origin of the coordinates system while FSL use the FOV corner.

Regards
Babak

PS:  This information is available in the acpcdetect v2 documentation.

Hello,

Thank you for replying. Once the landmarks are detected and the matrices are saved, I am attempting the following:

To figure out the translation that is needed to be applied to shift the origin to the AC: convert the AC voxel location to coordinates in mm (by multiplying with the first three rows and columns of the header matrix) and then subtract from the original images' translation (the last column of the header matrix).

However, I am unsure of how to proceed with calculating the rotations. I tried deconstructing the header matrix into components but the rotation values do not look reasonable.

Here is the FSL matrix that I have:
-0.9995 -0.0116 0.0291 189.5262
0.0093 -0.9969 -0.0776 273.5740
-0.030 0.0773 -0.9965 262.7300
0 0 0 1

I used the spm_imatrix function (from SPM) to deconstruct it into translations and rotations:
translations = 189.5262, 273.5740, 262.7300 (x, y, z)
rotations = -3.0638 0.0292 -0.0116 (pitch, roll, yaw (the pitch value in radians is too high!)

The detected AC and PC locations are: 96.8, 141.8, 152.1 and 96.9, 118.3 152.1

To shift the origin to the AC, translation = -matrix(1:3,1:3)*AC_location - matrix(1:3,4)
which gives me 7.08, 11.29, and 9.5 mm shift in the right, forward, and up directions (seems reasonable; using these values does bring the origin to AC)

How can I go about calculating the rotations then to line up the PC? I apologize if this is trivial and/or if I am meandering down an overtly complicated path for no reason due to my limited understanding in this area.


Look forward to your thoughts

Warm Regards
Pravesh

Originally posted by Babak Ardekani:

Originally posted by Pravesh Parekh:
Hi,

Please let me know the command line you are using.

When you say: "To figure out the translation that is needed to be applied to shift the origin",

how exactly are you defining the "origin"

-BA

Hello,

I am using SPM toolbox in MATLAB to perform the following:

% Read the header of original image
vol = spm_vol(filename);

% Read the matrix
data = spm_read_vols(vol);

% voxel location where the origin of the image should be set: corresponding to the antetrior commissure detected by acpcdetect
AC_voxlocation = [96.8;141.8;152.1];

% Convert AC voxel location to mm by multiplying with the rotation part of the matrix (vol.mat has the sform matrix)

AC_mm = vol.mat(1:3,1:3)*AC_voxlocation;

% Translation to be applied (i.e. need to shift the origin by these amount in mm right, forward, and up direction to get the 0,0,0 to correspond to AC)
translation = -AC_mm-vol.mat(1:3,4);

The origin is the (0,0,0) location in mm.

Regards
Pravesh

Originally posted by Babak Ardekani:

Sorry, I should have made my self clearer.  I was asking what is the command line that you issued to run acpcdetect including all the options?

Babak

Hello,

I issued the following command:
acpcdetect -i filename.nii -no-tilt-correction -center-AC -noppm -nopng -v


Regards
Pravesh


Originally posted by Babak Ardekani:

I just realised that SPM is reporting the opposite orientation than what acpcdetect is reporting; SPM says the original image is LPI right handed while acpcdetect says the original image is RAS. Similarly, the default RAS orientation output by acpcdetect is still reported as right handed LPI. If I force acpcdetect to output LPI, SPM reports that file as left handed RAS!

Originally posted by Pravesh Parekh:
Hmm... very curious.  Is it possible that SPM and ART are using different conventions.   In ART RAS means that the x-axis is pointing TOWARDS Right, y-axis is pointing TOWARDS Anterior, and the z-axis is point TOWARDS superior directions.  

It may be that under SPM RAS means the the x-axis is pointing FROM Right (to left) and the y-axis is point FROM Anterior (to superior) etc. 

 
Originally posted by Pravesh Parekh: In NIFTI header there are three vectors:
float srow_x[4] ; /*!< 1st row affine transform. */
float srow_y[4] ; /*!< 2nd row affine transform. */
float srow_z[4] ; /*!< 3rd row affine transform. */

These are set by acpcdetect.  

NIFTI defineds the x,y,z directions as:
+x = Right +y = Anterior +z = Superior

Let's say (i,j,k) are the coordinates of the AC as detected by acpcdetect, they to get the transformed AC location you will perform the 
following:

x = srow_x[0] * i + srow_x[1] * j + srow_x[2] * k + srow_x[3]
y = srow_y[0] * i + srow_y[1] * j + srow_y[2] * k + srow_y[3]
z = srow_z[0] * i + srow_z[1] * j + srow_z[2] * k + srow_z[3]

Since you chose -center-AC option, the (i,j,k) of the AC locations should map to point (0,0,0), the center of the FOV of the transformed image.

Hope this helps.

Babak

P.S.  I should add that since in acpcdetect V2 the transformation is further adjusted using the 8 Orion landmarks, AC may not be mapped exactly to (0,0,0) by the above formula, but it will be close.  To map the AC exactly to (0,0,0) you should use the -standard option as well, that is:

 acpcdetect -i filename.nii -no-tilt-correction -center-AC -noppm -nopng -v -standard

Hello,

Thank you for the detailed reply. This is indeed helpful!

I came back to lab and tried a fresh approach:

original_header = spm_get_space(original_file.nii);
RAS_acpc_header = spm_get_space(original_file_RAS.nii);
transformation = RAS_acpc_header/original_header


This results in an affine transform matrix which I can decompose into translations and rotations and apply to my image to get the origin to shift to the AC while also doing tilt correction.

I tried the method that you had described:

srow_x = original_header(1,:);
srow_y = original_header(2,:);
srow_z = original_header(3,:);

and then used the equations with substituted values for (i,j,k) to get x, y, and z.


Between both the methods above, there are slight differences in the translations values. The first one brings me exactly to the AC (perhaps because it also computes rotations) while the second one brings me approximately to the AC (the AC was detected using the standard option).


Do you think that calculating the mapping between the two images (as above) makes sense? To prevent any orientation change, I could always check the determinant before and after?


I think you are right that acpcdetect and SPM use different conventions. The following is taken from the header of spm_orientations:
% Show the orientations that SPM assumes that the data are
% stored in. Standard Analyze format axial images will
% normally be reported as 'RPI Left-handed'. Some people
% will represent their axial images as Right-handed.
% 'RPI' means that the fastest changing direction (i.e.
% the first element of the voxel coordinate) in the
% file is Right->left, the middle (second element of
% voxel coordinate) is Posterior->anterior and the
% slowest (third element - indicating slice number) is
% Inferior->superior.


In such a case, all orientations between acpcdetect and SPM should get flipped? RAS (acpcdetect) -> LPI (SPM); ALI -> PRS; and so on?


Many thanks for your time and help



Warm Regards
Pravesh
Originally posted by Pravesh Parekh: In NIFTI header there are three vectors:
float srow_x[4] ; /*!< 1st row affine transform. */
float srow_y[4] ; /*!< 2nd row affine transform. */
float srow_z[4] ; /*!< 3rd row affine transform. */

These are set by acpcdetect.  

NIFTI defineds the x,y,z directions as:
+x = Right +y = Anterior +z = Superior

Let's say (i,j,k) are the coordinates of the AC as detected by acpcdetect, they to get the transformed AC location you will perform the 
following:

x = srow_x[0] * i + srow_x[1] * j + srow_x[2] * k + srow_x[3]
y = srow_y[0] * i + srow_y[1] * j + srow_y[2] * k + srow_y[3]
z = srow_z[0] * i + srow_z[1] * j + srow_z[2] * k + srow_z[3]

Since you chose -center-AC option, the (i,j,k) of the AC locations should map to point (0,0,0), the center of the FOV of the transformed image.

Hope this helps.

Babak

P.S.  I should add that since in acpcdetect V2 the transformation is further adjusted using the 8 Orion landmarks, AC may not be mapped exactly to (0,0,0) by the above formula, but it will be close.  To map the AC exactly to (0,0,0) you should use the -standard option as well, that is:

 acpcdetect -i filename.nii -no-tilt-correction -center-AC -noppm -nopng -v -standard

Yes, it seems that SPM's convention for naming anatomical orientation is different from that of acpcdetect and NIFTI.  

What acpcdetect and NIFTI calls RAS means +x=R, +y=A, +z=S

What SPM calls LPI means-x=L, -y=P, -z=I

They are talking about the SAME anatomical orientation.

Your approach of relating the header matrices in your original images to the header matrices updated by acpcdetect seems reasonable, although I can't help you with the details.

Good luck.

Babak