Dealing with additional atlas resolutions about brainglobe-atlasapi

[adamltyson]

If we don't have urgent considerations on GIN space

This shouldn't be an issue, we're only ever going to be downsampling, so the space needed will be relatively small.

[FedeClaudi]

Yeah sounds good, I don't mind having extra atlases/resolutions.

How slow is the downsampling? Should we just host the high res version and implement the downsampling locally?

[adamltyson]

I'd like all resolutions to be hosted for testing and troubleshooting. If we need to download and then downsample the atlas, a lot of the amap & cellfinder tests would time out.

[FedeClaudi]

ok no prob

[vigji]

If we don't have urgent considerations on GIN space - which I don't think we have ATM - I would go for hosting multiple resolutions versions, making sure they are generated with the same scripts changing resolution only

[vigji]

Related to this so I won't open another issue - the meshes should be generated all in the same measurement units - matching the resolution metadata specification, I would say in microns - although this might be weird for big things like human atlas. @FedeClaudi what do you think? What units are they currently in the human stack?

[FedeClaudi]

I'm not sure if microns is the best or if it can be specified on a per-atlas basis (which should be fine since you'd only be using one atlas at the time).

Either way, we can add code to `mesh_utils.extract_mesh_from_mask' to enforce a certain resolution (which ultimatly consists of multiplying each vertex's coordinates by some scalar factor no?)

[vigji]

It's just that ideally the user is never really exposed to the numbers and we don't care about that too much. But then I wonder if it affects file size and read speed - maybe yes, as they are saved as ascii?)...?

So my proposal:

• if resolution does not change file size, we keep microns and forget about the problem;
• If resolution does change significantly (>20%?) file size and reading speed, then let's add that as an option to be specified per-atlas.

[FedeClaudi]

we can check I guess. But given that all it changes is a constant factor for all vertices coordinates, you can save it in a more economical way and then multiply the values when loading, though that's not the best.

Maybe it's worth having slightly larger files for the sake of consistency

[vigji]

Ok, I did a quick test and it does not change anything over 6 orders of magnitude as full floats are written anyway. So I would opt for consistency - the only place where this could come out is scalebar in visualisations, and that would be quick to automatically change.

[FedeClaudi]

okay, where how do we want to implement this?

[vigji]

So, I will make in half an hour another PR - finger crossed you won't kill me :p - that cleans up a bit more the saving part of the atlas generation so that all the files will be saved by the same function. So ideally the scripts will be loading/polishing the data, but all the final saving for all files is handled by a single function for all atlases - I am sure we must have this for consistency.

So in this schema you load you meshes, in the script you do the multiplication on the vertices to ensure they are in microns, and then you pass to the saving function some meshes objects (or even better, vertices-faces-edges tuple) with vertices in microns coordinates that will be saved.