Repository navigation
Surprising behavior of hatches in fill_between #11418
Description
Bug report
Hatches are invisible in the output of ax.fill_between when color is specified. They are present when color is absent or when facecolor is used.
I found #9894 which might be related, but seems to be a much narrower
Code for reproduction
import matplotlib.pyplot as plt
f, ax = plt.subplots()
ax.fill_between([0, 1], [0, 1], hatch="//")
f.savefig("test1.png")
f, ax = plt.subplots()
ax.fill_between([0, 1], [0, 1], hatch="//", color="g")
f.savefig("test2.png")
f, ax = plt.subplots()
ax.fill_between([0, 1], [0, 1], hatch="//", facecolor="g")
f.savefig("test3.png")Actual outcome
test1.png:
test2.png:
test3.png:
Expected outcome
I expected test2.png to have black hatch marks. I think what's happening is that the color= kwarg is being picked up globally by the artist and so the hatches in test2.png are there, they just have the same green color as the background. Unfortunately I don't think any hatch metadata other than the string code gets added to the artist, so I can't check.
Having color= globally change both the face and edge color of the artist makes a certain amount of sense, and I think the hatches are mostly inheriting their attributes from the kwargs that set the edge aesthetics. So I think I understand what's happening, but it took me a long time to figure out why the hatch argument had, apparently, no effect. I'll also note that the hatch demo is using the color= kwarg, but with ax.bar.
Matplotlib version
- Operating system: MacOS
- Matplotlib version: 2.2.2
- Matplotlib backend (
print(matplotlib.get_backend())): MacOSX - Python version: 3.6
- Jupyter version (if applicable): NA
- Other libraries: NA
This is a fresh install from conda to test, but I also saw it on matplotlib 2.2.0.
Activity
mwaskom commentedon Jun 11, 2018
More surprising behavior: whether or not the hatches inherit the
alpha=from the main artist varies across output formats. This is consistent across the three examples above but does reveal that the hatches are indeed present but invisible when specifyingcolor:test2.png:test2.pdf:jklymak commentedon Jun 11, 2018
I think the work around is to call
fill_betweentwice, once for the hatch and once for thefacecolor.. I imagine an API proposal for how to make this controlable from the API would be welcome. Note thehatch.linewidthandhatch.colorrcParams. You could probably also change those on the fly, though that is kludgey as well.mwaskom commentedon Jun 11, 2018
To be clear, I can accomplish what I want perfectly fine by using
facecolor, but that wasn't obvious and usingcolorjust made it seem likehatchwas broken somehow.Short of adding a whole new set of kwargs that specifically pertain to hatches, I'm not exactly sure how to "solve" the first issue. But it's possible that a situation where the user specifies a
hatchandcolorbut notfacecolororedgecolorwould be a reasonable place to fire a warning, as (I think?) we can be reasonably certain that the user doesn't mean to be doing that.The second issue actually seems more like an actual bug?
jklymak commentedon Jun 11, 2018
Right, but sometimes folks want to color the hatch as well, vs using the default color. Calling twice is the workaround for that.
The second issue seems to definitely be a bug... Adding a pdf tag.
mwaskom commentedon Jun 11, 2018
You can also accomplish that with
edgecolor(but there's no way to get three distinct colors for the face, edges, and hatches;edgecoloroverrides thehatch.colorrcParam).jklymak commentedon Jun 11, 2018
Ah, OK, I see. Probably rare that someone wants the edge and the hatch to be different, so thats probaby a decent API.
Tracking the docs through the
colorkwarg got me to: https://matplotlib.org/api/collections_api.html#matplotlib.collections.Collection.set_color which is pretty explicit that it'll set the edge and face colors. Where else in the docs should this be specified? FWIW, I'd personally just get rid of thecolorkwarg, but they outcry would be great!mwaskom commentedon Jun 11, 2018
Please do not get rid of the
colorkwarg! It is essential for higher-level APIs likeseaborn.FacetGrid.mwaskom commentedon Jun 11, 2018
If you want to solve this with docs changes then I would suggest more clearly documenting how hatching works. AFAICT there's basically only the hatch demo, which demonstrates (without explication) a usage pattern that produces invisible hatches with
fill_between, and then a subsection of the 2.0 release notes that documents how hatches get (some) customization by using the specified edge attributes.ImportanceOfBeingErnest commentedon Jun 11, 2018
This is the situation and it gives a perfectly expected result.
This is not rare at all. You would e.g. want a black border and differently colored hatches/faces in a bar plot. Currently it's only solvable by creating the same plot twice.
In general hatching is very underdevelopped. At one point @tacaswell mentionned that creating a MEP for it would be good; but I guess I forgot about it.
mwaskom commentedon Jun 11, 2018
Technically this does involve the user specifying the facecolor because setting
fill=Falsechanges its alpha channel:It's also worth noting that it is possible to get a UserWarning in a similar context:
jklymak commentedon Jun 11, 2018
We have a pretty big API that covers some rare use-cases. i.e. you could imagine a class for hatches where the hatch was an object that you manipulated. But we always have to balance if that extra API is really necessary given the occasional inconvenince of having to do things manually.
tacaswell commentedon Jun 11, 2018
For some fields hatching is not a rare use case (given how quickly it was reported when we broke some things about hatching in 2.0) in some fields.
Correct, the work to thread the hatch color through the API to be on the same footing as edge color and face color needs to be done. This includes both the set side to thread it through the plotting methods and the Artists and the backend side so that all of the backends that we ship respect the hatch color correctly.
As @ImportanceOfBeingErnest mentioned I commented else where this should get a MEP / some planning before the works get started and my rough estimate is that his would take a few weeks of full time effort by someone who knows the MPL code base to implement.
4 remaining items
mwaskom commentedon Jun 13, 2018
Absolutely. But in the meantime, the current approach is basically a hack that requires some knowledge of the implementation details; doing the most obvious thing fails in a confusing way. First-class support for hatching would be great, but also seems like a lot of work and I haven't seen anyone commit to it. So in the meantime, it might be helpful to give users some more guide rails. With that said I think that being conservative about issuing warnings is usually the right policy so I'm not going to push for it.
I think I can find time to make some small additions to the hatch demo and solve (1).
mwaskom commentedon Jun 13, 2018
Here's another fun one: it doesn't seem possible to set
hatch.linewidthon the fly using awithstatement, buthatch.colorworks fine.jklymak commentedon Jun 21, 2018
I think I agree that it’d be nice if we had a big API for hatching/stippling. Not going to happen in next 1.5 weeks, and is a bit of an API argument about how to handle. However, I expect we need a FillStyle object similar to a Color object and allow folks to specify that instead of the string shortcuts (which would of course generate a set of default FillStyle objects).
Not sure if facecolor should be part of the FillStyle. naively, that seems the most complete way to do things.
github-actions commentedon Jul 22, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!