Skip to content

Issue with minor tick spacing in colorbar with custom Normalize class #12808

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
astrofrog opened this issue Nov 14, 2018 · 4 comments
Closed

Comments

@astrofrog
Copy link
Contributor

Bug report

Bug summary

Minor ticks don't appear in the right place in colorbars when a custom Normalize class is used.

Code for reproduction

The following example requires astropy. If needed I can try and provide an example that doesn't use this.

import numpy as np
import matplotlib.pyplot as plt
from astropy.visualization import LogStretch, ImageNormalize, PercentileInterval

data = np.arange(256).reshape((16, 16))

norm = ImageNormalize(data, interval=PercentileInterval(99), stretch=LogStretch())

plt.rcParams['xtick.minor.visible'] = True

fig = plt.figure()
ax = fig.add_subplot(1, 1, 1)
im = ax.imshow(data, norm=norm)
cb = fig.colorbar(im)
fig.savefig('test.png')

Actual outcome

test

Expected outcome

The minor ticks should respect the spacing of the current stretch.

I noticed that using LogNorm, the ticks used to be spaced incorrectly in Matplotlib 2.2 but this was fixed in Matplotlib 3.0. However, the minor ticks are still broken for custom normalizations as shown above.

Matplotlib version

  • Operating system: MacOS X 10.13.6
  • Matplotlib version: 3.0.1
  • Matplotlib backend: Agg
  • Python version: 3.7.1
@astrofrog astrofrog changed the title Issue with minor tick spacing in colorbar with custom Normalize classes Issue with minor tick spacing in colorbar with custom Normalize classe Nov 14, 2018
@astrofrog astrofrog changed the title Issue with minor tick spacing in colorbar with custom Normalize classe Issue with minor tick spacing in colorbar with custom Normalize class Nov 14, 2018
@jklymak
Copy link
Member

jklymak commented Nov 14, 2018

Did this ever work? Making axes work for random normalizations is non-trivial, and probably requires some under-the-hood manipulation of scales....

@astrofrog
Copy link
Contributor Author

Just to be clear, it does work for major ticks, just not minor ticks.

It probably never worked for minor ticks, so it's not a regression, but it does seem like a bug compared to the expected behavior.

Just out of curiosity, since this does work for the major ticks, I'm curious why it would be difficult to extend this to minor ticks? (that is, the machinery is already in place for major ticks?).

If there is a reason this would be challenging, I wonder whether one solution would be to extend the code here:

https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colorbar.py#L490

to allow Normalize sub-classes to provide their own custom locators?

@astrofrog
Copy link
Contributor Author

It does seem like there is a minor tick auto-locator:

https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/colorbar.py#L1222

But for some reason this isn't working here (I tried calling minorticks_on)

@jklymak jklymak added this to the v3.1 milestone Nov 14, 2018
@jklymak
Copy link
Member

jklymak commented Nov 15, 2018

OK, so this is basically an issue with the fact that there are no arbitrary norms/scales allowed for axes at present. A few have been made to work (LogNorm, SymLogNorm, etc), but the general solution hasn't been done.

In this case I assume the best outcome would be a stretched axes, with the major tick marks appearing to be constant in space, and minor ticks between, like a Log norm is presently handled. Thats not possible and would require adding to the axis API.

I'm going to close this in lieu of #12665 which boils down to the same issue, but its an excellent use case of the same functionality discussed there. Feel free to carry on the conversation there if you have input. I think we can/should try and add this, as also discussed in #11859

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants