Closest point inside object

[bdpedigo]

Hi @william-silversmith - I've been running into a use case pretty consistently that I wonder if you've thought about or have a solution for.

I often generate or receive point annotations, either points inside an object or annotations on the surface (mesh) of that object. In order to create a bound point annotation in CAVE, I need to find a voxel coordinate roughly in the same position as my initial point, and I need that voxel coordinate to 100% be in the object I care about.

Because I am often dealing with floating points in relation to the mesh, I'm finding there is often sufficient wiggle room that if I round my point to the nearest voxel coordinate, I might end up just outside of the object I care about. I think this might also come from the mesh being somewhat downsampled?

In any case, my solution so far has been:

• Cast each point to voxel coordinates
• Look up each point using scattered_points
• Ensure that point is part of my root ID
• For any points that are not part of root, expand my search radius by +1 voxels in all directions, recurse

You can see that logic in code here:
https://github.com/bdpedigo/cave-mapper/blob/main/src/cave_mapper/mapping.py

It is clunky, but it works OK. The downside is that just doing these lookups can be slow, slow enough that they might be a limiting factor in my pipeline.

So - I wonder if you have a better idea for how to go from (points roughly in object, root ID) -> points in object that haven't moved too much

[william-silversmith]

Hi Ben,

This is pretty close to the strategy I would use, however there are two important changes you can take advantage of.

1. Use a CloudVolume LRU to accelerate scattered_points. Even if there is no spatial clustering, repeated queries using expanded radii will still benefit.

2. Expand your search using the chunk size. A chunk is downloaded whether you are searching for a point or a group of points, so why not explore all of that in memory at once? Most of the time is probably in the chunk graph query though, so....

3. If things become really too difficult, you can request the generation of a "flat" segmentation that doesn't require dynamic remapping from the chunk graph. This should be much more efficient to manipulate.

[bdpedigo]

Thanks for these thoughts, @william-silversmith. I'll definitely look into the caching/chunk size points.

I was using agglomerate=False and then doing the lookups for all points at once using chunkedgraph directly in one call - does your comment about most of the time being in the chunk graph query still hold, or is that not an issue with agglomerate=False?

[william-silversmith]

Glad you find it useful Ben! If you're using agglomerate=False, then the PCG query time is zero and you will likely see a tremendous benefit from setting lru_bytes if there is spatial clustering.