Consistent ordering of surface points on meshes generated by SPHARM-PDM

Community SlicerSALT
1

Hi,

I am using SPHARM-PDM downloaded from spharm-pdm_v1.13_linux64.zip.
My inputs are binary image files (*.nrrd). My expectation is that SPHARM-PDM can output triangle meshes that have a consistent ordering on the surface points. For example, those meshes are ordered from top to bottom, left to right, etc. The result is not, as shown in the picture below. This picture shows three surfaces (transparent ellipsoidal ones) generated by SPHARM. I connect the i_th point between surface a and b, forming the cyan line segment; I connect the i_th point between surface a and c, forming the red line segment. These two line segments share a same end on a. However, the other two ends apparently are on different sides, despite they have the same ordinal position on the respective mesh.

spharm_inconsistency
spharm_inconsistency597×573 62.4 KB

Please help me look at the way I call the program. I guess that I missed some parameters but I don’t know which. I know there are some about flip … But I’m not sure this is a general solution, i.e., I may need watch out the correspondence of every surface I generated; otherwise, I may have inconsistently oriented surfaces. Anyone had such a problem?

I call SPHARM-PDM like this:

GenParaMeshCLP --label 255 image.nrrd output_para.vtk output_surf.vtk
ParaToSPHARMMeshCLP output_para.vtk output_surf.vtk final_mesh --subdivLevel 10

Also, I noticed that there are some updates in SPHARM-PDM. If a new version is suggested, could you please also suggest a convenient way to use SPHARM-PDM in a python script like the above or better?

Thanks in advance.

2

Hi Zhiyuan
the newest SPHARM-PDM distribution is part of SlicerSALT. We do not update the binary distributions on NITRC anymore. So, you may want to check out SlicerSALT.

In addition, SPHARM-PDM will not give you good correspondences for objects with symmetry (in your case you have several symmetry axes) as the alignment of the parameter space is based on the first order ellipsoid. And I think that’s exactly what’s happening here, i.e. that one of the spherical parametrization phi or theta is flipped. You can manually force un/flip the parametrization using the final flip option in ParaToSPHARMMeshCLP

Martin

3

Thanks Martin. I guess for shapes that are slightly bent or twisted ellipsoids, the near-symmetry causes the same problem.

Zhiyuan