andyzeng / tsdf-fusion-python

Python code to fuse multiple RGB-D images into a TSDF voxel volume.
http://andyzeng.github.io/
BSD 2-Clause "Simplified" License
1.25k stars 219 forks source link

wrong demo result #24

Open hua-wu-que opened 4 years ago

hua-wu-que commented 4 years ago

There is double sided effect in the extracted mesh as well as point cloud in the demo code. The other side is not correct, how can this be fixed? Thank you.

remmel commented 3 years ago

I also have the same problem, even with 1 img of the sample dataset : n_imgs = 1 Photo "inside" the table with the side duplicated image Attached plys : ply1img.zip

shubhMaheshwari commented 3 years ago

I am facing the same issue. I tried with different examples from an RGBD dataset and all result in this double side effect. I also tried using a different algorithm for marching cubes, PyMCubes but I got the same result. Using Open3D ScalableTSDF gives the correct output. @remmel and @hua-wu-que were you able to find the cause of this bug?

remmel commented 3 years ago

@shubhMaheshwari , no I was not able to fix that pb, I didn't look further neither. The problem might comes from skimage which changed its implementation. Anyways, thank you for the alternative

shubhMaheshwari commented 3 years ago

So I found out why it's happening. The tsdf is initialized as 1. Due to truncation, the tsdf crosses 0 twice. One near the surface, and another from -1 to 1 at the end. eg. [1.0,0.5,0.0,-0.5,-0.9,1.0]. This leads to the 2 surfaces. A simple workaround is to pass a mask for the skimage marching cube algorithm. so update: fusion.py#L307

verts = measure.marching_cubes(tsdf_vol, mask=np.logical_and(tsdf_vol > -0.8,tsdf_vol < 0.8), level=0)[0]

and fusion.py#L328

verts, faces, norms, vals = measure.marching_cubes(tsdf_vol, mask=np.logical_and(tsdf_vol > -0.8,tsdf_vol < 0.8), level=0)[0]
remmel commented 3 years ago

thanks @shubhMaheshwari it removes part of the "double" mesh in my case using 0.5 instead of 0.8. By the way fusion.py#L328 should not end by [0] Do you think that problem is caused by changes in skimage?

shubhMaheshwari commented 3 years ago

Yes, their implementation of mask for marching cubes is not in-line with our usage. Basically in skimage they check if the mask is true, then they would run marching cubes on that voxel. Eg. If mask for X=Y=Z=0 is true. It would run marching cubes on voxel corresponding to it. Instead it should have checked if mask for all X=Y=Z={-1,0,1} is true. The mask for the voxel and it's neighbouring voxels. Only if the the mask of all of them are true. Run marching cubes. Adding a if-condition of satisfy this in skimage worked for me.