sc.pl.dotplot() `standard_scale='var'`: should scaling be changed?

[sjfleming]

This issue references the following line of code:

https://github.com/theislab/scanpy/blob/560bd5d348a502d5152eaf20f5f8bef794562a97/scanpy/plotting/_dotplot.py#L185

The documentation accurately describes the standard_scale='var' normalization strategy as
"Whether or not to standardize the given dimension between 0 and 1, meaning for each variable or group, subtract the minimum and divide each by its maximum."

Something about this normalization has bothered me for a long time, and I finally realized: it's the subtraction of the minimum value. This subtraction means that the minimum valued dot will have color = 0. Imagine a case with only two groupby groupings: healthy and disease. In that case, one of the dots will always have color 0, and the other will have color 1. Totally binary, no matter how close the actual values are.

I feel that this kind of normalization is very misleading for scRNA-seq data!

A random example follows:

This image makes it look like these genes are very specific to one tissue or another ---------------

But in reality, if we had scaled by just dividing by the max (and not first subtracting the min), then we'd see -------

which is much more realistic, and much closer to what you'd see if you used a log-scaling instead, and made several different plots for genes expressed at different levels overall.

I leave it up for discussion, but I would suggest two types of fixes:

1. delete the above line 185 (and the other places it shows up...)
2. allow the user to specify a custom normalization function (but change the default to x / max(x) instead of (x - min(x)) / max(x))

[ivirshup]

This has been discussed previously: #1451, mwaskom/seaborn#1423

I don't think that this sort of normalization is necessarily invalid or wrong, just situational. I also think it makes sense to mimic prior art, and this is how the argument works in seaborn. I do agree that just x / max(abs(x)) is useful, and more often what people want to use here (if scaling at all).

I like suggestion 2. more for this. I would suggest the following api:

normalization: Optional[Union[str, Callable[np.ndarray, np.ndarray]] (default: None)
    Normalization to apply to values. Can be selected from "z-score", "minxmax_scale", etc. or a Callable.
normalization_axis: Literal["var", "group"] (default: "var")
    If a `normalization` is passed, which dimension of the data to normalize along.

It would be nice if the normalization method was mentioned by default in the legend, but that can be difficult with how matplotlib doesn't really do text wrapping with it's notebook backend.

Arguably, for dotplot normalization should be available for both size and color.

What to you think @gokceneraslan @fidelram?

[gokceneraslan]

I also like the normalization and normalization_axis suggestion, I use z-score also all the time but it's very painful right now. I also agree with Stephen's concerns, minmax is not perfect and can be misleading, and it's safer to be more flexible, provide more normalization options and let the user be responsible for how the plots look like IMO. As I mentioned in #1913, we have to write in the legend that it's min-max scaled expression. We can even remove the color legend labels (0.0, 0.5, 1.0) if minmax is applied.

[gokceneraslan]

Btw I think the color map contributes to minmax scaling being more misleading in the upper dotplot, i.e. white color gives the impression that the gene is not expressed. So I wonder if it's equally misleading if a divergent color palette is used (e.g. RdBu_r)... Just a thought :)

[Hrovatin]

A few comments from my endeavors:

• Not sure how good is max scaling on groups for differently strongly expressed genes, especially due to mean-var bias - e.g. 0.8 of max expression for highly expressed genes is probably more meaningful difference than for a lowly expressed one.
• m=0 s=1 z-standardisation can be problematic if you have a small vs large population that has high expression (relatively to the size of whole data) - in former case you get much higher scores than in the latter as whole data seems higher
• If you have many cells doing [0,1] across cells rather than groups and then averaging may be good option as well (see below). Potential problem if you have outlier cells (less likely if log-norm before), but in this case you could normalise from 1st to 99th percentile - still may be problem for rare populations but at least you can regulate the threshold (so better than z-standardisation maybe).
• [0,1] on groups is not too bad when you expect large variation anyway by definition (e.g. plotting top data-defined markers), but agreed too often misleading so should not be default

Example: See gene Trp53bp1 under old - not much difference across groups:

• [0,1] on groups - seems very variable
  
• no normalisation (currently only other option) - bad for multiple marker comparison
  
• max_abs scale on groups - probably still exaggerates variability
  
• [0,1] on cells (before averaging) - the only one that does not exaggerate between group variability; similar with max_abs scaling on cells - probably as some cells are 0 - but much better in terms of time for large sparse matrices. however, this type of normalisation makes differences way less distinct - problem as weak markers look indistinguishable across groups.
  

@LuckyMD @Zethson what would be your best practice?

[ivirshup]

I'm pushing this from 1.9, but am also considering how well posed the issue is. There's a fairly complicated relationship between this kind of "normalization" and the norm, vmin, vmax, etc. arguments. I think this would need a tutorial (at least) to go with it.

Some thoughts:

• Basically, what this feature is is an additional transformation applied to the summarized values before they are mapped to colors. This could (and probably should) also be available for sizes of the dots.
• This is kinda covered by matplotlib's norm values, but those can only be applied to all the data at once – not per group.
• If we make it easier to split out getting summarized dataframe then plotting the values, this could largely be handled in user code.
• If you are doing a z-score normalization, surely you'd want a centered colorbar and diverging palette?

[rgranit]

@ivirshup @gokceneraslan any tutorial on how to apply z-score scaling or plans to add this feature in pl.dotplot? I believe this is the default with Seurat and it would be great to have such option for cases where the genes have very different expression scale

[adRn-s]

(Sorry to necrobump) FWIW, I'm using Seurat and customized my DotPlot function to use MinMax Normalized Log1P RNA counts after a colleague pointed out that Scanpy's DotPlot look better for the cells and gene markers in our study.

We aimed to avoid negative values for a marker that is expressed across all clusters. Although some clusters have below-average expression levels (resulting in negative values after z-score normalization), this is counter-intuitive because the cells were FACS-sorted, and negative expression doesn't align with expectations.

Seurat is using R-language base function scale() and that's not that a well thought fully aware decision (my speculation. Otherwise, we'd have options to switch and customize normalization methods there) Same applies to Scanpy, coming from a machine learning framework (Python) it's only natural they chose what was more "close" to them...

All this is to say, that options to choose different normalization are very welcome. Passing over a callable to be used in there would be nice, or some string argument where we can switch from "z-score" to "minmax", or "minmax modified"... Users should also be encouraged to try different settings. And papers should explicitly tell what they applied... So far, they don't. I only know now, that Scanpy and Seurat are divided (among other stuff) by this subjective decision. So whenever I see a DotPlot in a paper, I need to keep this in mind, check what they're using.

PS. I did "standard" MinMax Normalization because couldn't see a reason to only divide by max, as Scanpy does. To me, that decision was probably biased by some developer and the dataset they had at hand, where they preferred to avoid zeroes.