Inverse normalizations

[quentinblampey]

It could be great to be able to inverse each of the normalization transformations.

When running normalization, we can store some attributes in adata.uns and then we can re-use them for the inverse transformation.

I have already implemented this for a few normalization functions in scyan, so I can do a PR if you find it interesting.

[mbuttner]

I think that's a good idea. I think that keeping the parameters for normalization would also help to increase the interoperability of pytometry with FlowJo. Both tools have fairly different approaches when it comes to data transformation or normalization, but I think that keeping the parameters and implementing inverse normalizations is a step forward.

[quentinblampey]

Great, I'll work on this!
I'll try to do a PR next week with inverse_asinh, inverse_logicle, and maybe inverse_biexp

[grst]

Certainly agree on storing the parameters in adata.uns for posteriority.

About the inverse transfromations, could you clarify when you need them instead of just keeping the untransformed data in an adata.layer?

[mbuttner]

That's a great point.
By default, pytometry does not keep an untransformed version of the data right now, which is why it would make sense to me to implement inverse transformations. @grst has a point, though, and an alternative solution is to create a copy of the untransformed data in adata.layers for all normalizations and keep the normalization parameters for interoperability.
Given those two solutions, I would prefer @grst's suggestion.

[quentinblampey]

I completely agree that keeping the untransformed data is better. Still, the inverse transformation can be used on batch corrected data, for which we don't have the untransformed values (for instance, after batch effect correction with Scyan). This way, we can visualize the corrected data in FlowJO.

But I agree that it's a very specific use case, and maybe a bad practice to do that anyway. So I'll only work on storing the parameters in adata.uns!

[grst]

Ok, then let's do it like that for now. If it turns out there are more broadly applicable use-cases we can still add inverse transformations later.

Related: in that case working with layers should become more convenient, e.g. all preprocessing functions should support storing the result in a separate layer. There are some ideas how the API for this could look like in scverse/anndata#706:

sc.pp.compensate(adata, in_layer="raw", out_layer="raw_compensated")