You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the nanostring_cosmx dataset each row of the annotation matrix is associated to two regions, since each set of cells is saved both as a Labels and as a Points (with variable radius for the cells).
With the current specification each row of the table can annotate only one regions, I think we should support the above case, we have to explore how.
So they have two representations for the same regions? How common is that?
I think I'd be fine with making the metadata basically act as default arguments, then letting people specify they want to use a different region set with arguments.
It actually will be very common when building graphs on top of labels, since you would have points (with the graph in obsp) for the same regions, and you may want to plot sometimes the labels in the background and sometimes the points.
Possible workaround following your suggestion: if the column corresponding to regions_key(the one that for each row of the annotation matrix has a reference to a Regions object) is a numerical index instead of the full path, then the user (or our methods) could quickly switch the target regions by simply modifying the values of regions.
It actually will be very common when building graphs on top of labels, since you would have points (with the graph in obsp) for the same regions, and you may want to plot sometimes the labels in the background and sometimes the points.
Possible workaround following your suggestion: if the column corresponding to regions_key(the one that for each row of the annotation matrix has a reference to a Regions object) is a numerical index instead of the full path, then the user (or our methods) could quickly switch the target regions by simply modifying the values of regions.
mmh think using indexes rather than explicit values would be tricky. What about using multiple regions_key and instances_key?
This is solved by the new multi-table PR #455. We don't allow to annotate multiple elements, but we have an helper function to quickly choose what the table is annotating:
Just for completeness, you could potentially add now also two tables, one annotating Points and one annotating Labels. Ofcourse the solution which @LucaMarconato mentions would be better.
Activity
ivirshup commentedon Oct 11, 2022
So they have two representations for the same regions? How common is that?
I think I'd be fine with making the metadata basically act as default arguments, then letting people specify they want to use a different region set with arguments.
LucaMarconato commentedon Oct 11, 2022
It actually will be very common when building graphs on top of labels, since you would have points (with the graph in
obsp) for the same regions, and you may want to plot sometimes the labels in the background and sometimes the points.Possible workaround following your suggestion: if the column corresponding to
regions_key(the one that for each row of the annotation matrix has a reference to a Regions object) is a numerical index instead of the full path, then the user (or our methods) could quickly switch the target regions by simply modifying the values ofregions.giovp commentedon Oct 13, 2022
mmh think using indexes rather than explicit values would be tricky. What about using multiple
regions_keyandinstances_key?LucaMarconato commentedon Feb 2, 2023
I proposed a solution here: ome/ngff#64 (comment)
LucaMarconato commentedon Feb 15, 2023
Related #99
LucaMarconato commentedon Feb 22, 2024
This is solved by the new multi-table PR #455. We don't allow to annotate multiple elements, but we have an helper function to quickly choose what the table is annotating:
melonora commentedon Feb 26, 2024
Just for completeness, you could potentially add now also two tables, one annotating
Pointsand one annotatingLabels. Ofcourse the solution which @LucaMarconato mentions would be better.