imshow's "nearest" and "none" interpolations produce smoothed images

[fjarri]

Tested on:
OSX 10.8.3, python 2.7.4, matplotlib 1.2.1
Ubuntu 12.04 x64, python 2.7.4, matplotlib 1.2.1

Consider the following script:

import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import numpy as np
from matplotlib import cm
from numpy.random import randn

fig = plt.figure()
ax = fig.add_subplot(111)

data = np.clip(randn(25, 25), -1, 1)
cax = ax.imshow(data, interpolation='none', cmap=cm.afmhot)

plt.savefig('test.pdf')
plt.savefig('test.eps')
plt.savefig('test.png')

I expect it to produce a checked image of the random array, with non-smoothed borders between cells. But it does so only for the png version; the other two are heavily smoothed (by looking inside the .eps file, it seems that it just contains the 25x25 bitmap verbatim). If I change the interpolation to nearest, the smoothing is not that heavy, but zooming shows that it still exists near the borders. Also, the produced .eps file is 1.4Mb since it seems to contain the same effectively 25x25 bitmap, but scaled to much bigger size.

[WeatherGod]

Isn't this more an issue with the viewer that you use rather than with mpl? Unless there is some sort of way for mpl to flag the intended interpolation scheme for the rasterized element in the vector files, it is entirely up to the viewer how to treat a 25x25 bitmap that is stretched out to the width of the page. When you choose "none", the raster data is just simply passed through, IIUC, while "nearest" will rescale the raster to the stated dpi of the document. The bluriness you see at the boundaries of the "nearest" image is the product of the viewer.

I am not an expert in eps or pdf, so I don't know if there is additional information that mpl can provide to these backends to provide hints to the renderer, but I would imagine that is all we could do, if at all.

[WeatherGod]

As an alternative, have you tried using pcolor() or pcolormesh()?

[fjarri]

I was expecting (perhaps mistakenly) that either one of none or nearest will output the image by drawing vector squares instead of the pixels. It is indeed what happens when I use pcolormesh(), but this method does not support extent and aspect keywords which I need (although this can probably be fixed by drawing axes manually).

[fjarri]

I thought about it and it seems that I was wrong and the current behavior (of exporting an actual image as a result of imshow) is logical. Closing the issue.