Skip to content

ImageComparisonFailure: Image sizes do not match expected size #14180

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.

Sign up for GitHub

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

Jump to bottom
Closed
pllim opened this issue May 9, 2019 · 8 comments
Closed

ImageComparisonFailure: Image sizes do not match expected size #14180

pllim opened this issue May 9, 2019 · 8 comments
Milestone
v3.2.0

Comments

@pllim
Copy link

pllim commented May 9, 2019 •
edited
Loading

Bug report

Bug summary

matplotlib.testing.compare.compare_images complains about image sizes do not match.

Code for reproduction

astropy 4.0.dev24570
matplotlib 3.0.2+2458.g959e9f3a9

import os

from matplotlib import pyplot as plt

from astropy.io import fits
from astropy.wcs import WCS

# https://github.com/astropy/astropy/blob/master/astropy/visualization/wcsaxes/tests/data/msx_header
data_dir = '/my/path/astropy/visualization/wcsaxes/tests/data'
msx_header = fits.Header.fromtextfile(os.path.join(data_dir, 'msx_header'))
wcs = WCS(msx_header)

fig = plt.figure(figsize=(3, 3))
ax = fig.add_axes([0.25, 0.25, 0.5, 0.5], projection=wcs, aspect='auto')
ax.coords[0].set_axislabel("Label 1")
ax.coords[1].set_axislabel("Label 2")
ax.coords[1].set_axislabel_visibility_rule('always')
ax.coords[1].ticklabels.set_visible(False)

plt.draw()
fig.savefig('ztemp.png')

This is supposed to produce something that looks like test_axislabels_regression.png.

Actual outcome

Downloading the "truth" file above and then doing this comparison locally on my machine, I get this:

>>> from matplotlib.testing.compare import compare_images
>>> compare_images('test_axislabels_regression.png', 'ztemp.png', tol=2)
...
ImageComparisonFailure: Image sizes do not match expected size:
(214, 208, 3) actual size (300, 300, 3)

On CircleCI, we get something like https://circleci.com/gh/astropy/astropy/30970

ImageComparisonFailure: Image sizes do not match expected size:
(214, 208, 3) actual size (170, 170, 3)

xref astropy/astropy#8678

Expected outcome

I am not sure what the expected outcome should be. Is there a way to ignore image size? It seems that image size depends on the machine you are running on.

Matplotlib version

  • Operating system: RHEL7 (locally) and Debian (CircleCI)
  • Matplotlib version: 3.0.2+2458.g959e9f3a9 (locally) and 3.0.2+2456.g28e32c6 (CircleCI)
  • Matplotlib backend (print(matplotlib.get_backend())): Qt5Agg (locally)
  • Python version: 3.7.1 (locally) and 3.6.7 (CircleCI)
  • Jupyter version (if applicable): N/A
  • Other libraries: astropy, numpy

I installed the dev version locally using pip install git+https://https://github.com/matplotlib/matplotlib command.
@pllim pllim mentioned this issue May 9, 2019
Closed
@pllim
Copy link
Author

pllim commented May 9, 2019

FWIW the failures started cropping up in astropy's CircleCI a few days ago.

@tacaswell
Copy link
Member

Do you see this with 3.1.0rc2 locally?

@pllim Would you be willing to bisect this back to offending commit? This looks like a regression on our side.

@jklymak
Copy link
Member

jklymak commented May 9, 2019

Is there anything in the rcParams? i.e. are you somehow calling tight_layout, constrained_layout, bbox_inches='tight' etc? How bounding boxes on axes are being computed has changed to include more artists, so perhaps those changes have caused a problem?

@pllim
Copy link
Author

pllim commented May 9, 2019 •
edited
Loading

Not sure about rcParams on CircleCI... @astrofrog?

@pllim
Copy link
Author

pllim commented May 11, 2019 •
edited
Loading

@jklymak , yes, looking at the test code, now I see a tight layout being set:

    @pytest.mark.remote_data(source='astropy')
    @pytest.mark.mpl_image_compare(baseline_dir=IMAGE_REFERENCE_DIR,
                                   savefig_kwargs={'bbox_inches': 'tight'},
                                   tolerance=0, style={})
    def test_axislabels_regression(self):
        # Regression test for a bug that meant that if tick labels were made
        # invisible with ``set_visible(False)``, they were still added to the
        # list of bounding boxes for tick labels, but with default values of 0
        # to 1, which caused issues.
        wcs = WCS(self.msx_header)
        fig = plt.figure(figsize=(3, 3))
        ax = fig.add_axes([0.25, 0.25, 0.5, 0.5], projection=wcs, aspect='auto')
        ax.coords[0].set_axislabel("Label 1")
        ax.coords[1].set_axislabel("Label 2")
        ax.coords[1].set_axislabel_visibility_rule('always')
        ax.coords[1].ticklabels.set_visible(False)
        return fig

So, is the only solution to update our "truth" image? Or is there something we can set to obtain the previous bounding box behavior?

@jklymak
Copy link
Member

jklymak commented May 11, 2019

You can exclude the offending artists from the bounding box by calling artist.in_layout. But I have no idea if the right bbox is being made. Possibly you have an invisible patch that was previously ignored but now is part of the calculation. Hard to tell without someone digging into the size of the bounding boxes etc

@pllim pllim mentioned this issue May 11, 2019
Merged
@astrofrog
Copy link
Contributor

Just for info, I've been investigating this issue and have found that our test failures in astropy are due to #14134 - see my comments in #14134 (comment), as I'm trying to figure out if this is a Matplotlib bug or something that needs updating in Astropy.

@tacaswell tacaswell added this to the v3.2.0 milestone May 11, 2019
@anntzer anntzer mentioned this issue May 14, 2019
Merged
6 tasks
@anntzer
Copy link
Contributor

anntzer commented Jul 4, 2019

Unless I am mistaken, this has been closed by #14216. Feel free to ping for reopen if not.

@anntzer anntzer closed this as completed Jul 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v3.2.0
Development

No branches or pull requests
5 participants
@tacaswell @astrofrog @anntzer @jklymak @pllim