ignore singleton dimensions in ndarrays passed to imshow

[tacaswell]

instigated by this: http://stackoverflow.com/questions/15008045/showing-an-image-with-pylab-imshow/15008830#15008830

This just gets rid of singleton dimensions in ndarrays that are passed in.

[efiring]

First, this is not fixing a bug, so if it should go anywhere, it should be into master, not 1.2.x.

Second, I think this is a slippery slope, and it is not clear to me that we should start sliding down it. There is a balance between ease-of-use and trying to be too clever--assuming we know what the user wanted, instead of letting the user specify what is desired. I think this squeeze is going too far in the direction of "do what we think the user proabably wanted, not what the user specified". I don't see a good justification for it.

[tacaswell]

I seem to be consistently target the wrong branch.

As I was typing my defense of this not being too far down the slope, I convinced my self I am wrong.

This blows up the use case of a (M, 1, [3, 4]) array.

[mdboom]

Aside from the details of the implementation (which has a buglet as you point out) and the branch this should go on (I think master), I actually think the premise is a good one.

This makes greyscale (single plane) images behave in a similar way to RGB and RGBA images. Therefore the expected dimensions of the image are always (height, width, planes), rather than (height, width, planes if planes > 1) and the onus is removed from the user to determine which kind of the three they have before passing the image to matplotlib. Of course, we can't, for backward compatibility and issues of making obvious and simple things work, remove the ability to just pass in a 2D image. But I'd be in favor of adding something like:

if array.dims == 3 and array.shape[2] == 1:
   array = array.reshape(array.shape[:2])

[tacaswell]

@mdboom Do you want/need me to do anything else about this at this point?

[mdboom]

I think if there's consensus about moving forward with this idea, we can go ahead with an implementation that does something a little more specific than what squeeze does... but there may be more to discuss first...

[dmcdougall]

I think that judging by that Stack Overflow question, this is more of a documentation bug than a code bug. We should be more explicit in saying what matplotlib expects. In addition to @efiring's point, if matplotlib starts being a little more clever about assuming what the user wanted, we also have to document this behaviour on top of documenting explicitly what matplotlib expects.