Hatch pattern changes with dpi

[jowr]

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:

[tacaswell]

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]

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]

That makes sense.

[knarrff]

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]

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]

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.

[timodonnell]

@knarrff Were you able to find a workaround for this?

[knarrff]

For that one publication we just adapted the density by hand. I didn't bother finding a more general work-around. It would still be nice to have it fixed. It would be nice to get a comment from one of the knowledgeable developers as to which direction they would like to see for a fix - then it might make sense to look into it again.

[eolivaresb]

@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]

This appears rather straightforward to fix; @tacaswell I wonder if we should target 2.0 for this?

[efiring]

@QuLogic, give it a shot. It's worth trying to get it in.

[efiring]

In other words, if it's ready in time, that's a bonus; otherwise it will go in the next release.

[QuLogic]

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.

[QuLogic]

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?

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.

[NelleV]

Closed in #7421