Repository navigation
Hatch pattern changes with dpi #4108
Description
Hi, I currently use matplotlib a lot - thanks for your nice work! I noticed that the hatch patterns change with the dpi settings. This is not a big problem as long as you raster the whole plot. However, if you only raster parts of it, you will find that the legend not longer matches the pattern in the bars and that there is a gap at the bottom of the bars.
import matplotlib.pyplot as plt
fig = plt.gcf()
ax = fig.add_subplot(111)
ax.bar(0.7, 5, 0.3, label="raster /", hatch="////", rasterized=True)
ax.bar(1.0, 7, 0.3, label="vector /", hatch="////", rasterized=False)
ax.bar(1.7, 5, 0.3, label="raster .", hatch="....", rasterized=True)
ax.bar(2.0, 7, 0.3, label="vector .", hatch="....", rasterized=False)
ax.bar(2.7, 5, 0.3, label="raster x", hatch="xxxx", rasterized=True)
ax.bar(3.0, 7, 0.3, label="vector x", hatch="xxxx", rasterized=False)
ax.set_ylim([0,10])
plt.tight_layout()
ax.legend(loc=0,ncol=3)
fig.savefig("dpi050.png", dpi=50)
fig.savefig("dpi300.png", dpi=300)
fig.savefig("dpi050.pdf", dpi=50)
fig.savefig("dpi300.pdf", dpi=300)
And this is how dpi050.pdf looks:
Activity
tacaswell commentedon Feb 16, 2015
Is this something that can even be ensured? The rasterized hatch is going to be fixed, where as the vector hatch is controlled by the viewer?
jowr commentedon Feb 16, 2015
It might be possible to force the rasterisation of the legend patch as well. Not a solution, but at least legend and graph would match.
tacaswell commentedon Feb 16, 2015
That makes sense.
knarrff commentedon Sep 16, 2015
Stumbled over this myself just now. We'll have to rasterize (to preserve the look of the plot for a publication, not making it viewer-dependent), but when rasterizing, the dpi influcence the hatch size/spacing. This, in the end, prevents users from having a high-res but widely spaced '/' hatch for instance. Currently, the higher your dpi is, the more '/' lines you get (closer together).
knarrff commentedon Sep 16, 2015
I have been looking at the source code, but from that it is not apparent to me what the intent is in the first place. hatches have a 'density', which is 'the number of lines in a unit square' (hatch.py). I didn't find any definition for 'unit square' though - and the question is: does it's size depend on the resolution?
Also, this does not only affect the AGG or pdf backend. I see the same for, e.g., the eps backend. Also there, the look of the actual hatch pattern depends on the chosen dpi. This is not what I would expect, or want.
knarrff commentedon Sep 16, 2015
Sorry for spamming so much. I couldn't let go of the source code, and it looks to me now as a "unit square" is meant to be a 1inx1in square (from #4122). Given this, the current behavior would indeed be a bug. Looking at both the pdf and ps backends, I see a fixed 'resolution' of 72 when handling hatches, given as the length of the sides of the 'unit square' (e.g. line 1164ff in backends/backend_pdf.py). Could it be that the actual used dpi should be used here? On the other hand, that file also contains a comment: # TODO: We could make this dpi-dependent, but that would be an API change.
I'll now drop this and try to get a workaround working, but it would be nice to have this working in the future obviously.
2 remaining items
eolivaresb commentedon Oct 28, 2016
@knarrff Can you please tell me how did you change the density.
I'm having the same problem. I don't want to much density of hatching but a high dpi.
QuLogic commentedon Nov 7, 2016
This appears rather straightforward to fix; @tacaswell I wonder if we should target 2.0 for this?
efiring commentedon Nov 7, 2016
@QuLogic, give it a shot. It's worth trying to get it in.
efiring commentedon Nov 7, 2016
In other words, if it's ready in time, that's a bonus; otherwise it will go in the next release.
QuLogic commentedon Nov 7, 2016
I think all our tests were rendered at the wrong DPI (probably okay before it was changed), so it's probably best to get a change like this in with 2.0.
Generate rasterized hatching at correct DPI.
QuLogic commentedon Nov 7, 2016
To answer this question, I don't believe so. The 72 is from the definition of PDF files, and not related to the dpi of the figure. The dpi only applies to raster images, such as the ones with
rasterized=True, hence it's actually a problem of the Agg backend.Generate rasterized hatching at correct DPI.
Generate rasterized hatching at correct DPI.
Make PDF and PS hatching origin the same as Agg's.
NelleV commentedon Nov 14, 2016
Closed in #7421