Repository navigation
LogNorm colorbar prints double tick labels after set_ticks() #13112
Description
Bug report
Bug summary
Some colorbar labels are printed twice when I use a colorbar with LogNorm and small ranges of numbers after setting the ticks manually with set_ticks().
See figure below: By setting the minor_thresholds to something low, the double ticklabel at 20000 disappears, so it could have something to do with the minor formatter in LogFormatterSciNotation?
I think it could be related to other issues that have been posted: #12488 #12503
Code for reproduction
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.colors as mcolors
import matplotlib.ticker as ticker
fig, ax = plt.subplots()
pcm = ax.imshow([[10000, 25000]], norm=mcolors.LogNorm())
cb = fig.colorbar(pcm)
# cb.formatter.minor_thresholds = [0,0] # deactivates minor ticks labels?
cb.formatter = ticker.EngFormatter()
cb.set_ticks([10000,20000,25000])Actual outcome
Expected outcome
There should be no double ticks.
Matplotlib version
- Operating system: OSX
- Matplotlib version: 3.0.2
- Matplotlib backend: Qt5Agg
- Python version: 3.7
- Jupyter version (if applicable): -
- Other libraries: -
I installed matplotlib via conda through the default channel.
Activity
jklymak commented on Jan 5, 2019
@timhoffm is this still a bug in master? I thought we changed some log tick handling for colorbar, but maybe this is a bug in that or the changes haven’t been merged yet
timhoffm commented on Jan 5, 2019
This is still a bug in master. There are more tick labels in master, but 10000 and 20000 are still duplicate:
jklymak commented on Jan 5, 2019
Yeah on phone but I think it’s because we automatically label minor ticks if the dynamic range is inadequate.
jklymak commented on Jan 6, 2019
Hmmm, OK, there are a few issues here.
First,
So, the basic logarithmic ticks have the same problem, plus or minus...
Secondly, we made it possible to toggle minor ticks, but not for log axes. That was my fault for not understanding that change well enough, and I think we should allow that toggle for all cases. That would at least allow a work around.
Colorbars don't have good support for minor ticks right now, but we can probably easily fix that.
As a work-around, you can get rid of the minor ticks: cb.ax.yaxis.set_ticks([], minor=True)
jklymak commented on Jan 6, 2019
I'm going to ping @efiring and @NelleV as the folks who worked on making the logarithmic minor ticks visible or not. That works fine, but seems to label the major tick twice and with an offset.
I think its somewhat unfortunate minor and major ticks are not all handled in the same routine. Certainly the minor labeller should know if the major labeller has labeled a tick or not. Or the minor locator should exclude major ticks.
efiring commented on Jan 7, 2019
I think the reason minor ticks cannot be toggled for log axes is that without them, if the view range is not large, it is impossible to include enough ticks to show what is going on. And even with at least one decade, the minor ticks With ordinary ticks, the tick interval is completely elastic, so it is always possible to ensure there are 2 or more major ticks within a view range. Not so with log axes.
Because we are in the unfortunate situation where major and minor ticks are not handled in the same routine, the log ticker is supposed to omit minor ticks (or at least the labels; I don't recall) at major locations. I think this used to work, so a bug seems to have crept in. Either that or we just never saw situations such as you illustrate above. We did work with some such, though, to try to make small, medium, and large log scale ranges all work.
jklymak commented on Jan 7, 2019
Thanks @efiring.
What I was missing in the formatter or locator was just something that said “hey I’m handling minor ticks and exclude the major ones.”
Anyhow I’ll try bisecting tonight and see if I can get back to something that worked and see what changed.
jklymak commented on Jan 7, 2019
The over-printing bisects to #12865, where we try and take care of really tiny limits. Looks like we are adding a tick we didn't used to... Of course the behaviour before #12865 was suboptimal as well, so I think nothing "broke" so much as it just needs more fixing