I am trying to use a filled colorbar (as issued in ). But then cb.remove() does not work as it used to do, ie the space used by the colorbar is not recovered.
Using cb.remove() does work as expected when the colobar is constructed with the output of plt.contour as in the initial demo.
Code for reproduction
importnumpyasnpimportmatplotlib.colorsimportmatplotlib.pyplotaspltdelta=0.025x=np.arange(-3.0, 3.0, delta)
y=np.arange(-2.0, 2.0, delta)
X, Y=np.meshgrid(x, x)
Z1=np.exp(-X**2-Y**2)
Z2=np.exp(-(X-1)**2- (Y-1)**2)
Z= (Z1-Z2) *2fig, ax=plt.subplots()
cs=plt.contour(X, Y, Z, cmap="viridis")
norm=matplotlib.colors.Normalize(vmin=cs.cvalues.min(), vmax=cs.cvalues.max())
sm=plt.cm.ScalarMappable(norm=norm, cmap=cs.cmap)
cb=fig.colorbar(sm, ticks=cs.levels) # bugged, cb.remove() incomplete#cb=fig.colorbar(cs, ticks=cs.levels) # ok, cb.remove() okplt.show()
##### USE cb.remove() after in an interactive environment####
Actual outcome
Initial
After calling cb.remove() the space used by the colorbar is not recovered
Expected outcome
Expected output (obtained using cs instead of sm):
I can confirm this is incorrect. Do you know if this ever worked? We changed a fair bit around the colorbar in 3.5, but I don't know offhand why this would have broken.
I don't think this ever worked. We get the info about the axes to resize from the mappable. I suppose its possible we could get that info another way, but thats the way it works now, so adding this would be a feature request.
but actually we know the actual axes from which space was stolen: it's the axes in cb.ax._colorbar_info["parents"]. I suspect the fix is to simply unsteal from each of these axes instead.
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
Activity
jklymak commented on Jan 18, 2022
I can confirm this is incorrect. Do you know if this ever worked? We changed a fair bit around the colorbar in 3.5, but I don't know offhand why this would have broken.
sylvain-bougnoux commented on Jan 18, 2022
Thanks for your prompt answer. Actually I don't know.
If you have a fast workaround, for some reasons resetting the axes position hardly work either.
jklymak commented on Jan 18, 2022
I don't think this ever worked. We get the info about the axes to resize from the mappable. I suppose its possible we could get that info another way, but thats the way it works now, so adding this would be a feature request.
sylvain-bougnoux commented on Jan 18, 2022
In case of inconsistent API, the frontier between missing feature & bug is vague :-)
FYI, a fast workaround is:
anntzer commented on Nov 30, 2022
From a quick check this seems reasonably easy to fix: currently Colorbar.remove tries to unsteal space from the mappable axes
try: ax = self.mappable.axes except AttributeError: return try: gs = ax.get_subplotspec().get_gridspec() subplotspec = gs.get_topmost_subplotspec() except AttributeError: # use_gridspec was False pos = ax.get_position(original=True) ax._set_position(pos) else: # use_gridspec was True ax.set_subplotspec(subplotspec)but actually we know the actual axes from which space was stolen: it's the axes in cb.ax._colorbar_info["parents"]. I suspect the fix is to simply unsteal from each of these axes instead.
github-actions commented on Jan 26, 2026
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
timhoffm commented on Jan 26, 2026
Required action: #22257 (comment) should be tried