pylab image_masked is broken

[efiring]

It looks like the input values are getting clipped instead of registering as over and under.

With v2.x:

It should look like this, from v1.5:

[efiring]

attn: @mdboom
For the first plot, the problem is that support for over and under values has been lost when image interpolation is anything other than 'none' or 'nearest'.

cmap = get_cmap('viridis')
cmap.set_over('c')
cmap.set_under('r')
fig, axs = subplots(ncols=3)
axs[0].imshow(randn(20,20), vmin=-0.5, vmax=0.5, cmap=cmap, interpolation='bilinear')
axs[1].imshow(randn(20,20), vmin=-0.5, vmax=0.5, cmap=cmap, interpolation='none')
axs[2].imshow(randn(20,20), vmin=-0.5, vmax=0.5, cmap=cmap, interpolation='nearest')

[efiring]

For the second plot, BoundaryNorm is not broken, so it looks like the problem is that imshow is no longer recognizing the integer indexing into the colormap LUT.

from matplotlib.colors import BoundaryNorm
bn = BoundaryNorm([-1, -0.5, -0.2, 0, 0.2, 0.5, 1], ncolors=256, clip=False)
xx = np.linspace(-2, 2, 100).reshape(10, 10)
fig, (ax0, ax1) = subplots(ncols=2)
ax0.pcolormesh(xx, norm=bn, cmap=cmap)
ax1.imshow(xx, norm=bn, cmap=cmap)

[tacaswell]

It seems that _image.resample is clipping everything to [0, 1], independent of input type (which is why we moved the normalization first to begin with). This causes 2 problems. The first is that the BoundaryNorm mappings all end up being 1 or 0 and second is it cuts off the over/under. I have made some progress on the second issue.

which is generated off of the commit in #6581

[mdboom]

I think @tacaswell's solution in #6581 is actually pretty elegant and doesn't add much runtime overhead.

[tacaswell]

It still completely fails on BoundaryNorm and NoNorm use cases though.

[mdboom]

Did you see my comment in #6581 about a fix for BoundaryNorm?

[efiring]

@mdboom, does image handling always go through _ImageBase._make_image()? If so, I think the integer indexing case can be handled by doing the colormapping immediately when the norm returns integers, and then proceeding as if an RGBA array had been supplied from the start. This seems to me to be in the spirit of the integer indexing.
I can try implementing this later today, unless someone else would like to do so, or a flaw in the strategy becomes clear.

[mdboom]

If so, I think the integer indexing case can be handled by doing the colormapping immediately when the norm returns integers, and then proceeding as if an RGBA array had been supplied from the start. This seems to me to be in the spirit of the integer indexing.

Doesn't that leaves us right back where we started? Interpolating in RGBA space and all of the incorrect results that that causes?

[efiring]

@mdboom, only in the case of integer colormap indexing, where interpolation other than none or nearest is not really appropriate anyway--so I don't see any real problem. It would be the same as the present case with RGBA input, right?

[mdboom]

I see your point. I'm sure there are some users that pass in integers representing continuous data anyway.

Seems like a reasonable compromise -- if ints passed in, map to rgba first. If floats, interpolate then color map.

[efiring]

To be sure it is clear: what we are talking about is the dtype after application of the norm, so the integer case is encountered only when BoundaryNorm is used (on a floating point or integer array), or NoNorm on an integer array. In other words, this is the case where the user is saying "use exactly these colors that I specify by indexing into the LUT". One could even go so far as to warn when the requested interpolation is not "none" or "nearest" in such a case, but I think that would be overkill.

[QuLogic]

I believe this was fixed by #6581.