Matshow/imshow changes layout in matplotlib >= 3.3

[matthias-k]

Description

I set up a subplots layout the way I need it for my figure and the subplots look good. But as soon as I start filling the axes with image-data using matshow or imshow, the layout is completely changed. It appears, the axes change their aspect ratio to one, resulting in large margins in the final plot.

Steps to reproduce

import proplot as plot
import numpy as np

f, axes = plot.subplots(nrows=2, ncols=5, aspect=4/3, wspace='3mm', hspace='3mm')
axes[0].matshow(np.random.randn(3,4))

Expected behavior: I expect to see a nicely aligned grid of axes with the given aspect ratio, the first axes should be completely filled with the random data, roughly like this (except for the missing data):

Actual behavior: The matshow command changes the layout:

Equivalent steps in matplotlib

Not sure whether this applies here, but with the matplotlib subplots, the layout is not changed after the first matshow.

import matplotlib.pyplot as plt
import numpy as np

f, axes = plt.subplots(2, 5, figsize=(4*5, 3*2))
axes[0, 0].matshow(np.random.randn(3,4))
f.subplots_adjust(hspace=0.1, wspace=0.1, left=0.02, right=0.98, top=0.98, bottom=0.02)

Proplot version

0.6.4

[matthias-k]

I noticed that the issues seems to be related to the reference axes. Everything is fine if I apply imshow to the second instead of the first axes:

[matthias-k]

It appears this is a regression, since the same issue happens to examples from the documentation,e.g. the example from https://proplot.readthedocs.io/en/latest/subplots.html.

According to the documentation, it should look like

[matthias-k]

I ran a git bisect binary search and found that the bug was apparently introduced in e7f76fa. That commit seems to change how different aspect settings for axes are handled but I don't know the code well enough to spot the actual problem. @lukelbd maybe you have an idea?

[pratiman-91]

@matthias-k
I think what you are looking for is the change in the aspect ratio. If you want to set the aspect ration to be same as matplotlib then you have to set it to axes.set_aspect('auto'). For example,

import proplot as plot
import numpy as np

f, axes = plot.subplots(nrows=2, ncols=5, aspect=4/3, wspace='3mm', hspace='3mm')
axes[0].matshow(np.random.randn(3,4))
axes.set_aspect('auto')

will yield

[lukelbd]

Thanks for the report and your investigation. After some playing around it seems like e7f76fa did not introduce this bug -- everything works fine on master in matplotlib 3.2.2. This is another matplotlib 3.3+ bug, possibly related to #210

[lukelbd]

Eating my words -- it was e7f76fa (I have no idea what git bisect is but evidently I should learn). In matplotlib 3.3+ they translate aspect='equal' to aspect=1 (these are synonyms since here "1" is in data units) but I confused matplotlib's convention of data-units "aspect" with proplot's convention of physical-units "aspect". So this otherwise innocuous change caused the whole algorithm to fail.

Now fixed by: 124ea3f

[matthias-k]

@lukelbd Thanks for fixing this! For the sake of completeness, git bisect is a git feature for efficiently finding the commit that introduced a certain bug. It can save a lot of time :). See https://git-scm.com/docs/git-bisect for a nice introduction