Question about the thresholding in proj()

[xwjabc]

The projection function proj() in droid_slam/geom/projective_ops.py (L44) has a threshold for Z. Similar thresholding for Z is also applied in projective_transform() to generate a valid map. I am confused about the the way of thresholding and its aim:

1. In projective_transform() and proj(), it seems the threshold is used to exclude points too close to camera. However, Z is the third coordinate in the 3D homogenous coordinates, which is not the actual depth. The actual depth should be Z/D. Thus, why does it threshold Z instead of Z/D?
2. projective_transform() and proj() have different thresholds for Z: MIN_DEPTH and 0.5*MIN_DEPTH respectively. Is there any reason?
3. I am curious why we should exclude points too close to camera. Is it because if the points are too close, the division might be inaccurate and lead to large error? However, the threshold is not very small (MIN_DEPTH=0.2), which seems too loose for the division stability.

[Willyzw]

Hi, I encounter the same question why the third one of the homogenous coordinates instead of last. Any idea about it??

Btw the replacement for the clamped values are different in py and cuda. Its everywhere replaced with 0.0 e.g. in

DROID-SLAM/src/droid_kernels.cu

Line 302 in 92027b3

const float d = (Xj[2] < MIN_DEPTH) ? 0.0 : 1.0 / Xj[2];

in cuda, whereas its clamped to 1.0 in python see

DROID-SLAM/droid_slam/geom/projective_ops.py

Line 44 in 92027b3

Z = torch.where(Z < 0.5*MIN_DEPTH, torch.ones_like(Z), Z)

This is somehow inconsistent.

Thanks in advance for any input!