Thanks for the contribution. Would we conceptually also need a CenteredSymLogNorm?
Im wondering whether we could get away without creating new classes. I suspect it needs to be a new class because the behavior wrt. to limits from data is different than for the uncentered variant (it's not just a prametrization change from vmin, vmax to vcenter, halfrange).

Thanks for the contribution. Would we conceptually also need a CenteredSymLogNorm? Im wondering whether we could get away without creating new classes. I suspect it needs to be a new class because the behavior wrt. to limits from data is different than for the uncentered variant (it's not just a prametrization change from vmin, vmax to vcenter, halfrange).

Good question , but i think it could be useful for consistency but i do suggest we can start with CenteredAsinhNorm firstsince:

• Issue[ENH]: A "CenteredAsinhNorm" would be useful #30679 specifically requested this for AsinhNorm
  -AsinhNorm is newer and gaining popularity for diverging data
  -We can add CenteredSymLogNorm later if users request it

Catching up as I just saw this linked to the issue I raised.

Would we conceptually also need a CenteredSymLogNorm?
I had actually assumed thatSymLogNorm was centered (I haven't used it in a while), as it seems like you would always want that to be the case.

I agree that aCenteredSymLogNorm would be similarly useful, so really maybe this is suggesting that some way to consistently specify the center ofany norm would be beneficial. I'm just a user and haven't looked at the implementation in detail, but being able to specifycenter=0 onany norm would be a welcome feature (and would supersedeCentered* versions of each norm)

While I would like to not build separate centered versions of the norms, we'd need to carefully think through behavior and API implications. Some incomplete

• The standard way for auto scaling is to use min/max of the data. That's easy to change to expanding the smaller limit.
• We may need to expose vcenter and halfrange properties, which is okish for AsinhNorm and SymlogNorm, as they have a natural center.
• The verbose usage would be to pass the norm explicitly e.g.plt.imshow(values, SymLogNorm(...), where we have to encode the centering behavior and vcenter (default 0) through parameters.
• The norm must internally store the centering state so that it can appropriately handle auto scaling.
• A standard way of usage is via the norm name e.g.plt.imshow(values, norm="symlog"). We cannot encode any additional parameters here. However, one could map a special string like "centeredsymlog" to the special constructor.
• Ranges can be predefined via the vmin, vmax kwargs:plt.imshow(values, norm="symlog", vmin=-1, vmax=1). This doesn't work for centered norms as we'd need other parameters vcenter, vrange. I'd be opposed opening this API for such alternative parametrizations. When using the norm name, this means we are limited to the defaults vcenter=0 and auto scaling. That may be good enough as it's the common case. If the user wants something else they'd need to pass an instance in - but that's no difference to a dedicated CenteredSymLog class.