CAVEconnectome / MeshParty

Apache License 2.0
34 stars 16 forks source link

Mesh cellbody interior #85

Closed 0xJustin closed 1 year ago

0xJustin commented 1 year ago

Maybe this is more of a cloudvolume issue, but I'm doing som mesh-based algorithms, and some steps have edge cases that occur in sections of the mesh like this:

image

As far as I can tell, the segmentation is contiguous in 3D in this part of the EM, and I can't filter it out with connected components because it is connected. I was trying to look at how to filter out interior regions in Trimesh, but I couldn't come up with a solution that computed in a reasonable amount of time. Any tips for dealing with these or filtering them out?

fcollman commented 1 year ago

Hi Justin,

Yes this is an issue, but its sort of the flip side of a feature, which is that the chunkedgraph and the meshes are able to represent neuronal self contacts without having the mesh merged across those self contacts. What has happened is that the nucleus was segmented separate from the cytosol, and then I automatically merged the nucleus at one spot. however, the opposite side of that nucleus is not "local" in the chunkedgraph. This is topologically similar to when an axon from a cell comes into contact with its dendrite, or when two dendrite branches come into contact. There we don't want the meshes to be be merged. To handle this, all local regions of the mesh are calculated independently using the PCG graph to make sure that the adjacent "local" parts of the mesh connect.

So workarounds.. We have created a set of somatic region meshes that fixes this issue for analysis of the soma in particular. We have done analysis that substitutes these "fixed" meshes for analytical reasons. You could use those, or simply redo this "fixing" which is simply remeshing the soma region after naively downloading the segmentation.

Second, you can change the way analysis works near the soma region to reflect that biological prior. Given that there is a nucleus annotation and segmentation surrounding that region, there is a data driven way to make such a process. How you do this might depend on what your pipeline is really trying to do.

One computational way to fix things in this reason is to use occlusion from rays shown from different angles to detect and remove "internal" faces from the mesh. I haven't automated such a process, but have used it in meshlab successfully.

One thing you might leverage is that each mesh fragment exists at a "level 2" fragment, and so you can effectively tag each component of the mesh with where it exists in the cells "level 2 graph". You could virtually 'merge' all level 2 ids that are near the somatic region of the cell, and then remove all vertices in either mesh that is 'close' to the merged mesh fragment.

We have discussed adding more "merge" locations in the soma region in order to remove these internal faces, but I don't have an algorithm in hand to faithfully identify all these merges, not to mention the pipeline it would take to apply these edits across the entire dataset, and remesh all the components. Edits and remeshing events on the same cell must be done serially, so there is a dependency tree across these edits.

0xJustin commented 1 year ago

Thanks for your detailed response, I really appreciate it. I think for now I might elect to absorb the edge cases then, and maybe I can use your idea to use the occlusion based approach in case these edge cases turn out to be over-representative. I'm trying to be computationally light, so I'm a bit worried in the other approach you mentioned about pulling the segmentation in case my runtime is wrapped up in API calls, though maybe there is a sufficiently course mip level to do it. You've given me good ideas to think about thank you!