imshow with big-endian data types on OS X

[danielflanigan]

When using imshow with an array of type >f, >f2, >f4, or >f8, the pixel(s) with maximum value in the array appears in the color of the minimum value.

a = array([[1, 0], [0, -1]])
imshow(a.astype('>f'))

This issue appeared on two systems:
OS X 10.7.4
numpy 1.6.2
matplotlib 1.1.0 with backend MacOSX
and
OS X 10.6.8
numpy 1.6.1
matplotlib 1.1.1 with backend TkAgg

This issue did not appear on a linux x86_64 system running
numpy 1.6.1
matplotlib 1.0.1 with backend GTKAgg

[WeatherGod]

Could we get a MacOSX user to confirm the existence of this bug?

[jswhit]

Confirmed. Using '>f' the image is dark blue in the upper left and lower right corners, with '<f' for just 'f', the image has red in the upper left (using an up-to-date clone of matplotlib master with either the macosx or QtAgg backends).

[efiring]

It's not OSX-specific. I can reproduce it in a linux-64 virtual machine.
Also, it is not imshow-specific: pcolor does it.
np.version.version is '1.6.3.dev-903d9b7'

The surprising thing is that the norm is preserving the byte order; and then the conversion to an integer for the table lookup seems to be going haywire.

[efiring]

I have found the line where the error is coming in. I should be able to figure out how to fix it some time today or tomorrow.

[WeatherGod]

Strange that you can reproduce it on a linux vm. On linux native systems, I can't reproduce it. Of course, I am not an expert in virtual machines, so I don't know if this is to be expected or not.

[efiring]

The problem is there even when you can't see it with the visual test. I have found and fixed it locally, but I should add a test, so it may be a day or so before I send a pull request for it. It is basically a numpy bug that we have to work around.