Current coverage is 62.10% (diff: 100%)

Merging #7800 into master will decrease coverage by 0.01%

@@             master      #7800   diff @@
==========================================
  Files           174        174          
  Lines         56028      56051    +23   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          34803      34810     +7   
- Misses        21225      21241    +16   
  Partials          0          0          

Powered by Codecov. Last update c676432...68230b2

Cleaned up based on comments from @afvincent and squashed/force-pushed

Actually, this should probably go into the same subheader as http://matplotlib.org/devdocs/users/whats_new.html#improved-image-support.

@anntzer great point

I'm concerned about this because I think that using imshow for anything other than linear scales is a terrible idea, confusing in the extreme. At this stage we should strongly discourage it in the documentation, and a real improvement would be to block it in later releases after the usual warning period.

Try changing the example to:

ax1.imshow(data, origin='bottom', aspect="auto", extent=(5, 0, 1e5, 1e0), interpolation='nearest')

and see if you think people will be happy with it, and will understand what it is doing without a long bout of head-scratching.
imshow simply doesn't have the right interface for anything other than normal, simple images. Even the existing extent kwarg is a pain--it gives no clue as to which of the many possible sets and permutations of 4 numbers it needs.

Specific advice for the present PR: state that the behavior of imshow with other than linear axes has changed, but it remains undefined and should not be used. And I would omit the plots.

@efiring I disagree about not using imshow on non-linear axes. If you have evenly spaced bins it is a more efficient way than using pcolormesh to get the same effect.

Agree extent could be clearer.

@tacaswell, are you volunteering to explain to puzzled users why the result of the example change that I gave above looks the way it does? And why this is an acceptable API? We can do this right, but imshow doesn't do so, by design. What do we lose by my suggestion of acknowledging that imshow was never designed for log scales, and now, by accident, happens to do what one might want, sometimes, with the right combination of obscure arguments? I think this acknowledgement would be doing users a favor.

The issue with flipping extent around like that seems to be more about bottom and non-increasing values in extent being confusing as it is just as puzzilng in linear scale as with log.

import numpy as np
import matplotlib.pyplot as plt

data = np.arange(30).reshape(5, 6)
x = np.linspace(0, 6, 7)
y = 10**np.linspace(0, 5, 6)
X, Y = np.meshgrid(x, y)

fig, (ax1, ax2) = plt.subplots(ncols=2, figsize=(8, 4))

ax1.imshow(data, origin='bottom', aspect="auto", extent=(6, 0, 1e5, 1e0),
           interpolation='nearest')



ax2.imshow(data, origin='bottom', aspect="auto", extent=(6, 0, 1e5, 1e0),
           interpolation='nearest')
ax2.set_yscale('log')

plt.show()

The log scale adds another dimension to the confusion, as illustrated by the fact that this discussion started when a user had been relying on the old behavior and considered that to be correct.

And the gap on the right is dependent on figure size...

In my personal use I have used imshow almost exclusively for data extracted from imaging detectors where the pixel value is a measure of how many photons hit that pixel (ie, a 2D histogram). The pixel edges moving with the scale seems very natural to me.

For example

import numpy as np
import matplotlib.pyplot as plt

data = np.arange(30).reshape(5, 6)
x = np.linspace(0, 6, 7)
y = 10**np.linspace(0, 5, 6)
X, Y = np.meshgrid(x, y)

fig, (ax1, ax2) = plt.subplots(ncols=2, figsize=(8, 4))
ax1.hist(np.random.rand(5000)*50000, bins=10, edgecolor='k')
ax2.hist(np.random.rand(5000)*50000, bins=10, edgecolor='k')
ax2.set_xscale('log')

plt.show()

which although it seems to expose yet another bug in log handling, seems very natural. As does

import numpy as np
import matplotlib.pyplot as plt

data = np.arange(30).reshape(5, 6)
x = np.linspace(0, 6, 7)
y = 10**np.linspace(0, 5, 6)
X, Y = np.meshgrid(x, y)

fig, (ax1, ax2) = plt.subplots(ncols=2, figsize=(8, 4))
ax1.hist(np.random.rand(5000)*100000, bins=np.logspace(0, 5, 10), edgecolor='k')
ax2.hist(np.random.rand(5000)*100000, bins=np.logspace(0, 5, 10), edgecolor='k')
ax2.set_xscale('log')

plt.show()

@efiring you mind if I do the backport of this? I have it ready to push, but don't want mess you up if you are doing it.

backported to v2.x as cfafd3d