imsave-generated PNG files missing edges for certain resolutions

[aWinglessMonkey]

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).

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 imsave. For example:

>>> n = np.zeros((3241,3241))
>>> plt.imsave('test.png', n)
>>> plt.imread('test.png').shape
(3240, 3240, 4)

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.

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.

[Kojoley]

Duplicate of #6813?

[aWinglessMonkey]

Don't think so.

[Edit] To clarify: #6813 is about imshow, with an artist with axes and ticks and display bounds and so on, while this one is about imsave, which appears to save an RGBA array directly as a PNG file.

[tacaswell]

In the worst maintainer answer ever, I can not reproduce this on linux from the v2.x branch, but can reproduce this with v1.5.1

import numpy as np
import matplotlib.pyplot as plt
import tqdm
from io import BytesIO

for j in tqdm.tqdm(range(2, 5000)):
    buff = BytesIO()
    n = np.zeros((j, j))
    plt.imsave(buff, n)
    buff.seek(0)
    shp = plt.imread(buff).shape
    assert (j, j, 4) == shp, (j, shp)

The set of sizes which fail in 1.5.1 is much wider than what the OP list, at least up to j == 2352

In [15]: print(sorted(fail))
[29, 57, 58, 113, 114, 115, 116, 201, 203, 205, 207, 226, 228, 230, 232, 251, 253, 255, 402, 406, 410, 414, 427, 431, 435, 439, 452, 456, 460, 464, 477, 481, 485, 489, 502, 506, 510, 803, 804, 812, 820, 828, 829, 837, 845, 853, 854, 862, 870, 878, 879, 887, 895, 903, 904, 912, 920, 928, 929, 937, 945, 953, 954, 962, 970, 978, 979, 987, 995, 1003, 1004, 1012, 1020, 1606, 1608, 1615, 1624, 1631, 1633, 1640, 1649, 1656, 1658, 1665, 1674, 1681, 1683, 1690, 1699, 1706, 1708, 1715, 1724, 1731, 1733, 1740, 1749, 1756, 1758, 1765, 1774, 1781, 1783, 1790, 1799, 1806, 1808, 1815, 1824, 1831, 1833, 1840, 1849, 1856, 1858, 1865, 1874, 1881, 1883, 1890, 1899, 1906, 1908, 1915, 1924, 1931, 1933, 1940, 1949, 1956, 1958, 1965, 1974, 1981, 1983, 1990, 1999, 2006, 2008, 2015, 2024, 2031, 2033, 2040]

(and at that point I got tired of waiting for the code to run). The 2.x code is at over 3k at this point and has not failed yet.

@Salganos Thank you for reporting this, but I am going to close as already fixed. I suspect that @mdboom (accidentally?) fixed this with some recent work on the png interface.

[aWinglessMonkey]

All right. That's relieving, actually. Thanks.