wrong demo result #24

Activity

1. remmel commented on May 10, 2021

   

   remmel

   on May 10, 2021

   Last edited by remmel

   More actions

   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
   
   Attached plys : ply1img.zip
2. shubhMaheshwari commented on Jun 11, 2021

   

   shubhMaheshwari

   on Jun 11, 2021

   Last edited by shubhMaheshwari

   More actions

   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?
3. remmel commented on Jun 11, 2021

   

   remmel

   on Jun 11, 2021

   More actions

   @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
4. shubhMaheshwari commented on Jun 11, 2021

   

   shubhMaheshwari

   on Jun 11, 2021

   More actions

   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]
   

   👍React with 👍3Reacted by 宋秉一, nauyihsnehs and Abhishek Kashyap
5. remmel commented on Jun 26, 2021

   

   remmel

   on Jun 26, 2021

   Last edited by remmel

   More actions

   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?
6. shubhMaheshwari commented on Jun 26, 2021

   

   shubhMaheshwari

   on Jun 26, 2021

   Last edited by shubhMaheshwari

   More actions

   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.
7. remmel

   added a commit that references this issue on Jun 27, 2021

   andyzeng#24 workaround to more or less fix the double sided effect

   f8482b8