Location of subplot.set_aspect(...) matters for imshow

[ppurka]

The location of the command subplot.set_aspect('auto') - whether it is before or after the command subplot.imshow(...) - determines whether the aspect ratio is properly set. The aspect ratio is properly set only if the set_aspect command follows the imshow command. The same holds true if other values are passed to set_aspect, such as set_aspect(0.05).

This discrepancy is most pronounced for plots with very disproportionate vertical and horizontal ranges. An example code is given below:

x = range(10)
y = [10**_ for _ in range(10)]
xmuly = [[i*j for j in y] for i in x]
# Uncomment this and comment the set_aspect below imshow to see the bug.
#subplot.set_aspect('auto', adjustable='box')
subplot.imshow(xmuly, origin='lower', cmap='jet', extent=[0,9,10**0,10**9], interpolation='catrom')
subplot.set_aspect('auto', adjustable='box')

This code can be tested live here.

This problem is not present when subplot.plot(...) is used. The aspect ratio is always correctly set irrespective of whether the set_aspect command comes before or after the plot command.

Corresponding Sage ticket: http://trac.sagemath.org/15315

[jasongrout]

Perhaps this live preview of the bug is more convenient. It uses the sage cell's ability to natively show matplotlib things, and it changes the syntax to python instead of Sage (in particular the ^ is changed to **)

[efiring]

"It's not a bug, it's a feature." At least, it has been part of the design of imshow for a long time--that's why there is an rcParams['image.aspect'] to set the default, and an imshow aspect kwarg to override that default.

To overcome all this, one could add a private flag attribute of the Axes object that would be set by any call to set_aspect, so that imshow could reset the aspect only if that flag was not set, or if it received an aspect kwarg other than None.

[tacaswell]

Closing as won't-fix as mucking with the aspect is one of the main features of imshow

I think this will be half-way addressed if the new rcparam #2637 goes through, as the rcparams will then get shoved directly into the kwargs which will eliminate this over-determination issue.