You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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()
(mpl 2.0b3, Qt5Agg)
Funnily enough this does not happen with matplotlib's own seaborn-ticks style (note the thin white strip visible in the first line):
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.
I guess this may be due to the fact that axes are drawn centered 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 inner edge matches the theoretical position.
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 imshow() 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.
The text was updated successfully, but these errors were encountered:
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)
(mpl 2.0b3, Qt5Agg)
Funnily enough this does not happen with matplotlib's own
seaborn-ticks
style (note the thin white strip visible in the first line):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.
I guess this may be due to the fact that axes are drawn centered 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 inner edge matches the theoretical position.
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
imshow()
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.The text was updated successfully, but these errors were encountered: