Repository navigation
ImageComparisonFailure: Image sizes do not match expected size #14180
Description
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.
Activity
pllim commentedon May 9, 2019
FWIW the failures started cropping up in astropy's CircleCI a few days ago.
tacaswell commentedon May 9, 2019
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 commentedon 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 commentedon May 9, 2019
Not sure aboutrcParamson CircleCI... @astrofrog?pllim commentedon May 11, 2019
@jklymak , yes, looking at the test code, now I see a tight layout being set:
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 commentedon 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
astrofrog commentedon May 11, 2019
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.
anntzer commentedon Jul 4, 2019
Unless I am mistaken, this has been closed by #14216. Feel free to ping for reopen if not.