transformation to use for Jacobian 3dNwarpFuncs

AFNI Message Board
1

Hello AFNI team,

I plan to measure the Jacobian with 3dNwarpFuncs (from individual space to template).

I am confused about the correct WARP for this analysis in order the measure the deformations to the template.
can you confirm that the correct WARP to use is?

_shft_WARP.nii.gz

thank you

2

I will note that I don’t really know what others do with this information. Bob had posted this previous information on the computation.

https://afni.nimh.nih.gov/afni/community/board/read.php?1,165536,165558#msg-165558

It may be that it’s good enough to just get an affine warp and nonlinear warp together. One way to remove effects of rotation and translation might be to do a rigid_equiv transformation separately. Then use that rigid_equiv output as input to another animal_warper. The first will remove effects from both rotation and translation. Scaling and shearing would be applied in the second iteration and the nonlinear warping. You could compare the results as one or two steps.

3

I will try that, it makes sense to me!
Thank you Daniel!

4

Hi, Clément-

For calculating a meaningful Jacobian, I think you could do 2 things:
A) just take the NL warp, and get the Jacobian of what is there at each voxel. Simples.
B) remove the rigid body components of AFF (no rotation or translation), and combine the remaining shear+scale parts of AFF and combine those with NL.

Does A or B make more sense to you? (There might not be one right answer to this.) My thought for A is to to use just the “local”, not global, parts of warping for the Jacobian estimate. My thought for B is that the shear+scale could be sensical to include in shape deformation comparisons. For A, you just have the final WARP dset to use—you could remove the average shift of each subbrick, to ensure that is not present in the data.

To get B, how would this sound:


# get approximate rotation part of affine file AFF, and invert it
cat_matvec   \
    -ONELINE \
    AFF -IP  \
    > AFF_IP

# combine the inverse rot matrix with the original one,
# to remove the rotation part of the original
cat_matvec   \
    -ONELINE \
    AFF      \
    AFF_IP   \
    > AFF_noR

# remove the translation part of what we just calculated
set aaa     = `cat AFF_noR`
set aaa[4]  = 0
set aaa[8]  = 0
set aaa[12] = 0
echo ${aaa} > AFF_noR_noT

# Combine that non-rot and non-translational affine mat with the NL warp
3dNwarpCat \
    -overwrite \
    -prefix NL_noR_noT \
    -warp1 NL \
    -warp2 AFF_noR_noT

… and then NL_noR_noT is useful for B’s Jacobian estimation. NB: you might still want to remove any average delta_x, delta_y and delta_z that may be in the NL or NL_noR_noT part.

How does that seem?

–pt

5

Hello Paul,

I have done A) already, using Daniel’s previous advice but sadly the results were incoherent with what I obtained using a classical atlas-based quantification.

The B) seems logical to me, and I will try it.

However, I have to say that I don’t get how inverting the AFF and combining it with the original AFF will exclusively remove the rotations?

Otherwise, that seems perfect!

Thank you!

I will let you know if my new results make more sense!

6

Hi, Clément-

To your question about inverting the affine, please note that this step does more than just invert the affine:


# get approximate rotation part of affine file AFF, and invert it
cat_matvec   \
    -ONELINE \
    AFF -IP  \
    > AFF_IP

since both “-I” and “-P” are used:


-P = Do a polar decomposition on the 3x3 matrix part 
       of the mfile. This would result in an orthogonal
       matrix (rotation only, no scaling) Q that is closest,
       in the Frobenius distance sense, to the input matrix A.

This is then used to “unrotate” the other matrix, when applied. The idea is to remove the rigid body parts (bulk translation and rotation) from the transformation parts, leaving the shear, scale, and local warps.

–pt

7

Hmm, not sure why the results would be incoherent starting with a rigid_equiv aligned dataset. In that case, also be sure to avoid recentering on the second go-round with “-align_centers_meth OFF”. That said, I think Paul’s undoing of the rigid_equivalent matrix should work - I think.