Creating root mesh

[FedeClaudi]

Hey,
for the human brain atlas, there's no 'root' mesh, I think that the annotated volume only has the labels of the 'leafs' of the structure tree (the same goes for the rat atlas):

So I'm creating the root mesh by taking all voxels that have value >0, setting them to 1 and reconstructing the surface from that. However, in the case of the human brain there is still some structure 'under the brain surface' which makes the root mesh kinda ugly:

Does anyone know of a better way to create the root mesh?

[adamltyson]

It appears to work OK in ITK-snap, I don't know what's different. Is the image volume solid before mesh extraction?

[FedeClaudi]

The surface of the mesh looks fine:

The problem is that the root is rendered semi transparent usually, but if I do that all the internal structure shows:

This is the inside after cutting out the frontal lobes

[adamltyson]

Can you use something like scipy.ndimage.morphology.binary_fill_holes before extracting the surface?

[FedeClaudi]

I can sure try

[vigji]

The zebrafish atlas has the same problem. I reported that and trying to see whether they want to fix it but I am wondering whether, as the root meshes have to render "look nice" we should potentially have a passage through blender to clean them up.

[vigji]

It would also potentially fix the "lego aspect"

[FedeClaudi]

That's also a possibility. Though ideally something automated because:

• if I want to create meshes for other non-leaf structures, I will probably have the same problem
• if people want to create their own atlas...

[adamltyson]

I think standard image processing (filling etc) should be fine to create OK meshes.

There's a question about whether we want to spend time making them as attractive as the Allen meshes. It shouldn't be hard to do though, apparently it's all in VTK.

[FedeClaudi]

It's worth giving a shot to the way Allen did it. anorak got in touch for help with brainrender once, maybe he found a way to create clean meshes in the meanwhile

[adamltyson]

This would be cool for the combined ara/f-p too because those meshes aren't great

[FedeClaudi]

Okay, I'll work on making prettier meshes tonight, then we can apply it recursively to structures.json if necessary

[vigji]

Okay, I'll work on making prettier meshes tonight, then we can apply it recursively to structures.json if necessary

Love our nightly sprints 😄 Amazing - if you figure that out I will steal everything for the zfish atlas :)

[FedeClaudi]

Sure, if we find a way that works it will be a standalone function/piece of code that prettifies meshes so can be used whenever

[FedeClaudi]

mmm I failed. I tried morphological transformations but I could't get a way to get rid of the inside stuff that didn't completely alter the mesh' shape.

I couldn't get vtk marching cubes to work, I can't figure out how to use vtk so I've used vtkplotter.Volume.isosurface to extract the mesh, but it's still full of stuff.

I tried decimating and smoothing the mesh, and while that helps it still didn't get rid of the stuff inside.

any other ideas? I'll try again tomorrow maybe with a fresher brain

[vigji]

For the morphological transformations approach: I know there is a transformation that is supposed to find the external surface of a binary image with holes. I am trying to dig out the name

[FedeClaudi]

let me knowif you find anything

[vigji]

This was the algorithm I was thinking about https://en.wikipedia.org/wiki/Active_contour_model.

I guess there's mesh generation routines created from it but I have not digged into these options - I hope you can find something!

[FedeClaudi]

Making some progress...

I've found an implementation of active contour model, but it was very slow. In the process I've discovered this neat marching cubes implementation whose 'smooth' option works well (though it's a bit slow).

That, combined with some morphological operations and a bit of vtkplotter magic yields better looking meshes (the red is the inside):

There's a bit of tradeoff between cleaning up internal srtucture and introducing artifacts though.

Btw this approach adds vtkplooter and pymcubes as requirements, but they can be just for the [dev] option for people wanting to develop atlases with our tools.

[adamltyson]

Looks nice.

Btw this approach adds vtkplooter and pymcubes as requirements, but they can be just for the [dev] option for people wanting to develop atlases with our tools.

I think this is fine, we can have everything in the [dev] list of requirements, but be careful what goes into the main list.

[vigji]

As a tangential note, This raises in general the point of whether we should use the meshes to calculate if a point is in a region.
My general approach would be no, but I would like to know what you guys think as @FedeClaudi was using meshes for such calculations in brainrender and it's important that such things are handled in a single point not to have too many moving parts and mesh generation produces ambiguity

[FedeClaudi]

I don't mind either way.
I was using different things for different functions

1. to know in which region a given point is, I was using this:
   https://github.com/BrancoLab/BrainRender/blob/5d71c7026e42f39ed461d039a7f5f9ed5aaa68fe/brainrender/atlases/aba.py#L838
   which uses the annotated volume
2. to know if a point is in a given region, I was using the mesh loaded as vtkplotter Mesh

I agree that all of this operations should be handled by core.Atlas

[adamltyson]

As a tangential note, This raises in general the point of whether we should use the meshes to calculate if a point is in a region.

I would prefer that we use the image (as is done with amap), for two reasons:

• In cellfinder we are usually more interested in what region a given point belongs to, and I think the image is more efficient for that.
• Many of the atlases we will use are defined as images. The mesh extraction is unlikely to be 100% perfect, and so there could be overlaps or gaps between meshes.

I would vote for using the atlas image for analysis purposes (when accuracy is important), and then this allows us to post-process the meshes so that they are more attractive, without worrying about them being perfectly accurate.

[FedeClaudi]

sounds good

[FedeClaudi]

Mesh generation should be improved as of #27

[FedeClaudi]

Should be fixed by #27