FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[Bug]: colorbar.remove() does not always work · Issue #22257 · matplotlib/matplotlib · GitHub

Repository navigation

[Bug]: colorbar.remove() does not always work #22257

Open

Description

Bug summary

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

import numpy as np
import matplotlib.colors
import matplotlib.pyplot as plt

delta = 0.025
x = 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) * 2

fig, 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() ok

plt.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):

Additional information

No response

Operating system

Windows

Matplotlib Version

3.5.1

Matplotlib Backend

Qt5Agg

Python version

3.8.9

Jupyter version

No response

Installation

pip

Activity

  1. jklymak commented on Jan 18, 2022

    Member

    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.

  2. sylvain-bougnoux commented on Jan 18, 2022

    Author

    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.

  3. jklymak commented on Jan 18, 2022

    Member

    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.

  4. sylvain-bougnoux commented on Jan 18, 2022

    Author

    In case of inconsistent API, the frontier between missing feature & bug is vague :-)

    FYI, a fast workaround is:

    cb.remove()
    ax.set_position([...])  # left,bottom,width,height
    ax.set_subplotspec(GridSpec(1,1)[0:1,0:1])
    
  5. anntzer commented on Nov 30, 2022

    Contributor

    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.

  6. 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!

  7. added
    keepItems to be ignored by the “Stale” Github Action
    on Jan 26, 2026
  8. timhoffm commented on Jan 26, 2026

    Member

    Required action: #22257 (comment) should be tried

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL