<p dir="auto">This is a bit of an odd problem, but has been reproducible for me in both Matplotlib 1.5.2 on Python 3.5.2 from Macports on Mac OS X 10.9.6 and Matplotlib 1.5.1 on Python 3.5.1 from Anaconda on Windows 10, both running on 64-bit 4-core Intel i7 processors (of significantly differing ages).</p>
<p dir="auto">Any array with a dimension of 3421*2^n, for a non-negative integer n, will be missing one line along that dimension when saved as a PNG file through <code class="notranslate">imsave</code>.  For example:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="&gt;&gt;&gt; n = np.zeros((3241,3241))
&gt;&gt;&gt; plt.imsave('test.png', n)
&gt;&gt;&gt; plt.imread('test.png').shape
(3240, 3240, 4)"><pre class="notranslate"><code class="notranslate">&gt;&gt;&gt; n = np.zeros((3241,3241))
&gt;&gt;&gt; plt.imsave('test.png', n)
&gt;&gt;&gt; plt.imread('test.png').shape
(3240, 3240, 4)
</code></pre></div>
<p dir="auto">Inspection of the file through the OS will also show the shortened resolution, and saving a more detailed image will show the missing lines are taken from the top and the right.  Saving an RGB or RGBA array has the same result.</p>
<p dir="auto">Considering the nature of the pattern, this would seem to be some sort of floating-point rounding error, though I have not been able to find a location it might occur.  I also cannot currently confirm if it happens for more recent versions, such as is currently in this repository.</p>
<p dir="auto">Make an image that's random noise in [0, 0.5] except the left half of the first line that's =1 (i.e, should be a white strip)</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="from matplotlib import pyplot as plt
import numpy as np
import seaborn as sns; sns.set(style=&quot;ticks&quot;)

t = np.random.random((128, 128)) * .5
t[0, :64] = 1
plt.imshow(t, interpolation=&quot;none&quot;, cmap=&quot;gray&quot;)
plt.show()"><pre class="notranslate"><code class="notranslate">from matplotlib import pyplot as plt
import numpy as np
import seaborn as sns; sns.set(style="ticks")

t = np.random.random((128, 128)) * .5
t[0, :64] = 1
plt.imshow(t, interpolation="none", cmap="gray")
plt.show()
</code></pre></div>
<p dir="auto">(mpl 2.0b3, Qt5Agg)</p>
<p dir="auto"><a target="_blank" rel="noopener noreferrer nofollow" href="https://cloud.githubusercontent.com/assets/1322974/17067434/8b5503c0-5000-11e6-835c-3c9fd1652bc5.png"><img src="https://cloud.githubusercontent.com/assets/1322974/17067434/8b5503c0-5000-11e6-835c-3c9fd1652bc5.png" alt="seaborn" style="max-width: 100%;"></a></p>
<p dir="auto">Funnily enough this does not happen with matplotlib's own <code class="notranslate">seaborn-ticks</code> style (note the thin white strip visible in the first line):<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://cloud.githubusercontent.com/assets/1322974/17067460/a7443c9a-5000-11e6-9752-386ceb93b713.png"><img src="https://cloud.githubusercontent.com/assets/1322974/17067460/a7443c9a-5000-11e6-9752-386ceb93b713.png" alt="mpl-seaborn" style="max-width: 100%;"></a></p>
<p dir="auto">While obviously, at some point there are just not enough pixels to display your data, I think this is somewhat misleading because individual pixels are clearly visible in the image, so you don't really expect some of them to be missing on the edge.</p>
<p dir="auto">I guess this may be due to the fact that axes are drawn <em>centered</em> on their "theoretical" position?  I wonder if this can be fixed by changing the zorder of the axes to go below the image, or (less likely to be widely applicable) shifting the axes out so that their <em>inner edge</em> matches the theoretical position.</p>
<p dir="auto">Edit: the problem of the first solution is that there's a loop... we expect images to be on top of axes, but lines to be on top of images and axes to be on top of lines (I think it would look weird if lines went on top of axes).  Still, it would help if at least the axes box did obey zorder, which it doesn't right now, AFAICT.  Then <code class="notranslate">imshow()</code> could by default change the zorder of the axes to a smaller value (yeah, magic, I know) but everything would still be fixable manually at least.</p>