so3_log_map unexpected behaviour

[eduardohenriquearnold]

Unexpected output of so3_log_map. so3_log_map and so3_exponential_map are inverse functions. However composing them for some rotation matrices do not result in the original rotation matrix R. Please note the code below.

Instructions To Reproduce the Issue:

import torch
from pytorch3d.transforms import so3_exponential_map, so3_log_map
from pytorch3d.renderer import look_at_view_transform

R,T = look_at_view_transform(1, elev=50, azim=0)
print(R)

log_R = so3_log_map(R, 1e-8)
R_hat = so3_exponential_map(log_R)
print(R_hat)

The output is

tensor([[[-1.0000,  0.0000,  0.0000],
         [ 0.0000,  0.6428, -0.7660],
         [-0.0000, -0.7660, -0.6428]]])
tensor([[[1., 0., 0.],
         [0., 1., 0.],
         [0., 0., 1.]]])

The matrices do not match, as one would expect. I cannot tell why, but I have noticed that this happens for any elevation angle <90 when azim=0.

[davnov134]

Hi,

unfortunately, for rotation angles close to PI or 0, the so3_log_map is (by definition) numerically unstable due to divisions by zero.

For more details on why this happens, please refer to https://en.wikipedia.org/wiki/Axis%E2%80%93angle_representation#:~:text=In%20mathematics%2C%20the%20axis%E2%80%93angle,the%20rotation%20about%20the%20axis , section "Exponential map from so(3) to SO(3)"

For better numerical stability you might want to switch to quaternions that do not suffer from these issues.

[eduardohenriquearnold]

Hi. Sorry, I should have realised this earlier. Thanks for the great explanation though.

[tomer-grin]

@davnov134
Hey,
I also encountered this issue (within a bigger pipeline).
It caused problems on a few samples and diving into them revealed this issue.
does it make sense to add a warning to so3_log_map function when the input matrix might be close to 0?