Skip to content

Hatch pattern changes with dpi #4108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jowr opened this issue Feb 16, 2015 · 15 comments
Closed

Hatch pattern changes with dpi #4108

jowr opened this issue Feb 16, 2015 · 15 comments
Labels
backend: agg backend: pdf Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Milestone
v2.0.0

Comments

@jowr
Copy link
Contributor

jowr commented Feb 16, 2015

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:
dpi050
@tacaswell tacaswell added backend: agg backend: pdf status: needs clarification Issues that need more information to resolve. labels Feb 16, 2015
@tacaswell
Copy link
Member

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?

@tacaswell tacaswell added this to the 1.5.0 milestone Feb 16, 2015
@jowr
Copy link
Contributor Author

jowr commented 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 tacaswell removed the status: needs clarification Issues that need more information to resolve. label Feb 16, 2015
@tacaswell
Copy link
Member

That makes sense.

@jowr jowr mentioned this issue Feb 18, 2015
Closed
@tacaswell tacaswell modified the milestones: next point release, proposed next point release Jul 17, 2015
@knarrff
Copy link

knarrff commented 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
Copy link

knarrff commented 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
Copy link

knarrff commented 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.

@timodonnell
Copy link

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

@knarrff
Copy link

knarrff commented Jan 21, 2016

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
Copy link

@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
Copy link
Member

QuLogic commented Nov 7, 2016

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

@efiring
Copy link
Member

efiring commented Nov 7, 2016

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

@efiring
Copy link
Member

efiring commented 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
Copy link
Member

QuLogic commented 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.

@QuLogic QuLogic modified the milestones: 2.0 (style change major release), 2.1 (next point release) Nov 7, 2016
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Nov 7, 2016
@QuLogic
Generate rasterized hatching at correct DPI.
a04cc29 
Fixes matplotlib#4108.
@QuLogic
Copy link
Member

QuLogic commented Nov 7, 2016

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.

QuLogic added a commit to QuLogic/matplotlib that referenced this issue Nov 7, 2016
@QuLogic
Generate rasterized hatching at correct DPI.
85b42b5 
The hatch buffer was created at 72 pixels, with the assumption that that
is the "unit square" (1in*1in). However, with default DPI increased to
100, that buffer is actually too small, causing hatching to be denser
than it should be. On test images where the DPI was set really low, the
hatching was less dense than it should be.

Fixes matplotlib#4108.
@QuLogic QuLogic mentioned this issue Nov 7, 2016
Merged
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Nov 9, 2016
@QuLogic
Generate rasterized hatching at correct DPI.
d072fc2 
The hatch buffer was created at 72 pixels, with the assumption that that
is the "unit square" (1in*1in). However, with default DPI increased to
100, that buffer is actually too small, causing hatching to be denser
than it should be. On test images where the DPI was set really low, the
hatching was less dense than it should be.

Fixes matplotlib#4108.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Nov 9, 2016
@QuLogic
Make PDF and PS hatching origin the same as Agg's.
9821dc0 
Agg uses top-left as origin, while PDF/PS use bottom-left. A vertical
shift by the page height fixes that.

See example in matplotlib#4108.
@NelleV NelleV added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Nov 10, 2016
@NelleV
Copy link
Member

NelleV commented Nov 14, 2016

Closed in #7421

@NelleV NelleV closed this as completed Nov 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backend: agg backend: pdf Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Milestone
v2.0.0
Development

No branches or pull requests
8 participants
@efiring @NelleV @tacaswell @QuLogic @knarrff @timodonnell @jowr @eolivaresb