UMAP colouring beyond adata.X or adata.obs

[ajitjohnson]

Hi I think by default sc.pl.umap looks into adata.X and adata.obs for coloring UMAP. Is it possible to force the function to look into adata.uns or adata.obsm where the cells are ordered in the same manner as that of adata.obs.index. Thank you.

[LuckyMD]

Why not store whatever you have in adata.uns that you want to colour by in adata.obs? adata.obs is designed specifically to store univariate data with dimensions of (n_obs,1). As colouring can also only work with univariate values, I currently don't really understand the need for this. Could you elaborate why this is needed?

[ajitjohnson]

Yes, that is what I currently do. It is just a matter of aesthetics. Since I have a large number of variables that I generate with custom functions, I wanted to store them separately based on what they represent in separate modules under (adata.uns).

Adding everything to adata.obs quickly gets cluttered. No worries just wanted to see if it was an option. Thank you.

[LuckyMD]

I think adata.obsm could make sense, but adata.uns would maybe be a bit too messy given the unstructured nature and the assumptions and tests that would have to be added.

[ajitjohnson]

Yeah, that makes absolute sense.

Even better would be to add layers similar to adata.X and pass that into any function. Something like adata.obs_custom. In which case adata.obs_custom will inherit the same properties as that of adata.obs and users can make as many as they need in an organized manner. It will also allow users to store different values with the same column name (of course in different layers). e.g. adata.obs_custom['same_column_name'] and adata.obs_custom2['same_column_name']

[ivirshup]

@ajitjohnson, I think you could use dataframes in obsm for that. We are planning on letting you plot colors from obsm, which is being worked on in this PR: scverse/anndata#342

[ajitjohnson]

that sounds awesome.