tsdf-fusion-python icon indicating copy to clipboard operation
tsdf-fusion-python copied to clipboard

wrong demo result

Open hua-wu-que opened this issue 4 years ago • 6 comments

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.

hua-wu-que avatar Jun 10 '20 03:06 hua-wu-que

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

remmel avatar May 10 '21 17:05 remmel

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?

shubhMaheshwari avatar Jun 11 '21 13:06 shubhMaheshwari

@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

remmel avatar Jun 11 '21 14:06 remmel

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]

shubhMaheshwari avatar Jun 11 '21 18:06 shubhMaheshwari

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?

remmel avatar Jun 26 '21 20:06 remmel

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.

shubhMaheshwari avatar Jun 26 '21 20:06 shubhMaheshwari