-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selecting rows in AnnData #8
Comments
For the moment I would just create a new object that is a subset of the original one. This can be stored inside the same (or in a new In the case of very large feature tables, or point tables, one may take advantage of something like an AnnData view. In implementing the backing system we need to take into account for this. |
In MoBIE, we have a concept of selected annotations, and we can also serialize them to a JSON file, which lives outside AnnData. The JSON file contains Strings that uniquely identify one row in the table (AnnData). An issue is that sometimes that comprises several columns. For example to uniquely identify an image segment we need: Any thoughts/comments about this? |
Ok I understand. If the selected entities are rows of feature tables, also coming from different tables, then we can have an in-memory and serializable representation by creating a global table and by adding a boolean column in obsm (this is similar to the Squidpy’s approach like when selecting visium spots from a napari interactive call). These selected rows are not selection regions/cells themselves, but we can easily retrieve and plot that information since feature tables are linked to regions. |
Serialization is one thing. Another related thing (in MoBIE) is that we have a text field (UI) where a user can type "a unique ID" in order to manually select a region/segment. ...or we could simply go for the |
Sorry, brainstorm mode... I do think |
For “short term usage”, when consistency over time is not a major point, the index would work. A UUID based approach (basically a name for each region), would make possible to have a persistent naming, also when merging tables, but then if the user modifies the object (like it applies a transformation creating a new image), it would fail because the UUID would change. To overcome one could use the tuple (coordinates, coordinate space), to query which region is covering that particular coordinate. This would be slower than a index or UUID, but would allow for “long term usage”. |
FWIW that's the WIP in MoBIE:
In other words any TBH, I am not sure I am getting it right yet, because now both |
Hi, here is a recap of the status of the framework with regard to this discussion. We are going through the old issues in the repo; closing the discussion. We don't have an explicit concept of "selected annotations" that is saved on disk, nor plans to have such information in the storage format. This because because the user can achieve an equivalent behavior by saving a categorical column to an annotation table. Also we provide APIs that allows to retrieve geometries based on a list of instances from the table (see this PR: #627). |
Hi,
This is more a discussion than an issue. Please let me know if we should move that somewhere else.
Let me start with a question: Do you have some mechanism to select a couple of rows in an
AnnData
object? If yes, how do you represent this in terms of python code / data structure? For example, is it just a list with the selected row indices or something else?The text was updated successfully, but these errors were encountered: