UZ-SLAMLab / Endo-Depth-and-Motion

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ask for help

kaikoko opened this issue · comments

Can someone help me deal with this problem? Thanks for your help.

Traceback (most recent call last):
File "apps/tracking_ours/main.py", line 427, in
main()
File "apps/tracking_ours/main.py", line 236, in main
pe.run(new_frame, True)
File "/home/liu/disk2/nxq/cook/Endo-Depth-and-Motion-main/edam/optimization/pose_estimation.py", line 146, in run
gauss_newton(
File "/home/liu/disk2/nxq/cook/Endo-Depth-and-Motion-main/edam/optimization/optimization_algorithms.py", line 41, in gauss_newton
torch.pinverse(jac[torch.abs(error_o) > 0, :])
RuntimeError: svd_cuda: For batch 0: U(4,4) is zero, singular U.

Hi,

Just seeing that error log is pretty difficult to find the root of the problem. Describe a bit your environment. Things like, which data are you running the algorithm on? Custom data? That problem arises too using the data of this repository?

Thank you very much for your response. The issue originates from the use of my own monocular endoscopic data. We employ the COLMAP algorithm to obtain depth maps, and then when we input them into the tracking step along with the original images, the algorithm reports the above error when automatically processing to the 92nd frame image.

I think COLMAP gives you sparse depth maps. Even if you use dense reconstruction, there could be some null pixels. In that case, this algorithm was designed to deal with dense depth maps, i.e. a depth value for every color pixel.

Maybe you can fix it easily densifying the sparse depth maps with a third-party algorithm.

Another option is modifying the tracking code so the invalid pixels are not used. However, there could be some part of the pipeline that needs dense input.

Hope this helps you. I would try the first option.

Thank you very much for your comments. With my best regards!!