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]])
This issue appeared on two systems:
OS X 10.7.4
matplotlib 1.1.0 with backend MacOSX
OS X 10.6.8
matplotlib 1.1.1 with backend TkAgg
This issue did not appear on a linux x86_64 system running
matplotlib 1.0.1 with backend GTKAgg
Could we get a MacOSX user to confirm the existence of this bug?
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).
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.
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.
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.
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.
Colormap: ensure native byteorder to avoid obscure putmask bug, #1005
add tests/test_colors.py with test for issue #1005