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.
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
patch facecolor does not respect alpha value #1030
Comments
This is an unfortunate side effect of the drawing model in mpl; a patch is drawn with a renderer Graphics Context, which has a single apha value that it uses for both the edge and the face. If the edge alpha is not zero, then it is used; else, the face alpha is used. If we keep this model, then the way to handle different edge and face alpha would be to split the draw up into two sequential operations, each with its own GC. The alternative would seem to be to modify the drawing model such that rgba would always be handled directly inside the backend, without using the GC to override any existing alpha in an rgba value. |
That sounds like a difficult change. I don't really have any input on whether it should be done, since I don't know enough about the mpl internals. Right now, my workaround is to duplicate the patch and make the facecolor of the second patch 'none' in order to get the edge fully opaque. However, this has a negative side-effect as well: in the legend, the patch does not match the figure. I think there's a way to work around that as well, but it would involve editing one of the patches within the legend directly. |
"Rationalizing color and alpha handling" would make for a great MEP :) If there isn't a volunteer to write this up, I just might take a crack at it. |
@keflavich Is this still true? There was recently (~6-10 months) an bunch of work (by I think @cimarronm) on this sort of thing. |
This appears to work in current master. Please reopen if I miss-understood the OP request. |
OK, glad to hear it, thanks @tacaswell - sorry I didn't get to check this. If I come across it again, I will reopen. |
I still have this issue with python3 and matplotlib 1.5 when following this example and changing the alpha: |
Can you provide a minimal example? It is hard to tell exactly what you are doing from your comment and the link. |
Of course. I should have done that from the beginning.
|
Does reproducing this depend on basemap? |
I've run afoul of this issue when trying to set the facecolor alpha of boxplot patches. As a workaround, one can set |
@AndrewDDavis does reproducing this depend on basemap? Could you post a minimal example on the bug? |
The issue arose for me when setting the patch colors in boxplots created by pandas import numpy as np
import matplotlib.pyplot as plt
import pandas as pd
x = [np.random.randn(10) for _ in range(2)]
# matplotlib
fig, ax = plt.subplots()
bp = ax.boxplot(x, patch_artist=True)
box = bp['boxes'][0]
box.get_alpha() # no result
box.set_facecolor([1., 0, 0, 0.5])
box.get_facecolor() # (1.0, 0.0, 0.0, 0.5) <- as expected
box.set_alpha(1)
box.get_facecolor() # (1.0, 0.0, 0.0, 1)
# pandas
df = pd.DataFrame(data=x).transpose()
fig2, ax2 = plt.subplots()
bp2 = df.plot.box(ax=ax2, patch_artist=True, return_type='dict')
box2 = bp2['boxes'][0]
box2.get_alpha() # 1
box2.set_facecolor([1., 0, 0, 0.5])
box2.get_facecolor() # (1.0, 0.0, 0.0, 1) <- suprising!
box2.set_alpha(None)
box2.get_facecolor() # (1.0, 0.0, 0.0, 0.5) If you know that the patch's alpha value is set, and that it will supersede the facecolor value, this behavior is consistent. If you don't realize this, it's surprising when you set a facecolor and the alpha isn't respected. |
If you set the facecolor of a patch with an alpha value, e.g.
the alpha value is ignored; only the patch's
_alpha
property is used. This makes it impossible to have a patch with an opaque edge and a (partially) transparent fill.I've only tested this on the TkAgg backend.
The text was updated successfully, but these errors were encountered: