VisionaryMind
commented
3 years ago It appears the problem is in the VoxelHashingGUI code, itself. The command line help indicates a parameter of "--intrinsics_path", however the code actually requires "--intrinsics_json". Changing this parameter allows the use of the generated intrinsics. The results are still quite inaccurate (with a great deal of drift), but at least the distortion issue has been resolved.
theNded
VoxelHashingGUI works perfectly with the Stanford dataset, but when attempting to use custom RGBD streams from the Azure Kinect, it fails to properly reconstruct the scene. The following settings were used for stream recording:
This may be partly a problem with Open3D's intrinsincs calculation for the K4A. The VoxelHashingGUI shows a camera that appears to have a very small focal length and an principal point off to the left side of the frame:
You can see that the depth cloud is compressed according to this error. Changing the GUI settings does not produce any useful changes. I presume that Open3D Azure Kinect support is still minimal. Offline reconstructions pipelines are also extremely inaccurate with this particular device. So far, only RTABMap has been able to handle K4A streams, but that solution is also lacking in robust support.
Which device did you use for the Stanford dataset? So far, K4A does not appear to be a viable device for 3D capture. Depth streams are less noisy than the Realsense cameras, but noisy enough to confuse ICP and other strategies for cloud alignment.
I understand K4A is a low-end device with very poor quality output, so our expectations are not very high. Please indicate the optimal device for a proper 3D reconstruction. So far, I have not seen a depth camera that remotely compares with solid-state LiDAR. The VoxelHashing algorithm on CUDA is very fast, and it would be desirable to use it, if possible, with a depth camera. We just need to know which you would recommend.