[enh] discuss strategy on multi region selection
on superset (e.g. cerebral cortex)
or unrelated region(s)
how do they affect:
- connectviity ?
- ebrains datasets ?
Now (as of v.1.0a01) that volumes can be used to query features and volumes can be merged, one can do this by merging the mask volumes of desired regions. Is there a specific request? Or any additional features needed for the explorer?
When the idea was conceived, I believe we were interested in exploring the selection two semantic region, and what it means for features fetching.
the two examples in the original issue:
- re: regional connectivity: an example where multi selection of regions of interet is suitable. siibra-python can show connection strength between two selected regions of interest (list of studies where the connections are observed, strength of connection, and/or geometry of physical connection (fibre?))
- re: ebrains dataset: in features: not so fitting, but how would siibra-python deal with this situation gracefully
We need to specify what multi-region selection would mean at all. siibra-explorer today avoids any form of it to my knowledge. Siibra-python avoids it in general, e.g. I could not create an actionable object from hOc1 and hOc3 in the left hemisphere., but allows to use parent regions such as hOc1 which is a selection of two regions (left and right hemisphere).
Let us assume we had a general mechanism to put multiple regions into one actionable object, say RegionSelection. The regions could even be from different parcellations. We had that in early siibra-python versions. How to use it?
- create a mask in a space: query each region's mask in that space, return the boolean and of the volumes (if needed, resample). Rais an exception if any of the subregions is not mapped in the space. A similar approach can be define for probability maps, requires more careful thinking but will work.
- spatial queries: trivial via the generated mask, if available.
- Semantic queries: Run a query with each subregion (recursively!), merge the search results, tag them with the most specific match. This can get very slow, we probably need a stop criterion (imagine search gene expression for the top parent of DiFuMo1024).
- Region operations: If the multi-region behaves similar to a region, maybe even is a region, we need to implement properties like "is_child_of" etc. This might not always be possible.
So two things to consider as next steps:
- Do we want this discussion for finishing siibra python v1? My clear opinion: No, it will take us much too long. We should invest in a discussion for siibra v2 once v1 is out.
- Revise the above bullet list. It is certainly incomplete and will lead to more complicated edge cases. Which supports my take on 1.
siibra-explorer today avoids any form of it to my knowledge.
Ctrl + left click: toggles a region (requested by user, as it is useful for visualizing multiple region meshes)
/what multiselection mean for feature queries/
I have grave concerns about the performance in this case. But we will have more time if we choose to implement in siibra v2
Do we want this discussion for finishing siibra python v1? My clear opinion: No, it will take us much too long. We should invest in a discussion for siibra v2 once v1 is out.
Agreed.