matplotlib-devel Mailing List for matplotlib

James Evans wrote:
> All,
> 
> 
> 
> I have a question regarding the default alpha value for an Artist. Why 
> is it 1.0 instead of None? The color conversion code takes into account 
> if alpha is None and having it default to something other than None 
> makes it impossible for any Patch to have a fill_color specified as an 
> RGBA value (and possibly other Artist sub-classes). Should this be 
> something else, or should the Patch.set_facecolor method pre-process the 
> incoming color value and set any specified alpha as appropriate (I hope 
> not since this would cause the color value to be processed several times)?
> 
James,
This is just an aspect of the general mess that is alpha-handling in 
mpl. Sometime, maybe a year ago, I thought it would be easy to fix at 
least some of the problems by changing the default Artist alpha to None. 
 It turned out to be not that simple, I ran out of time and patience, 
and dropped it. Perhaps some other changes in the interim have made it 
so that changing the Artist initial value now would be simpler, but I 
suspect it will still have to be done as part of a deeper overhaul, if 
not the full overhaul that would be most desirable.
Eric
> 
> 
> Thanks,
> 
> --James Evans
> 

Eric Bruning wrote:
> I'm seeing problems with reversed colormaps (attached code and image).
> The problem seems to be with colormaps that are specified functionally
> or that don't have equal numbers of red, green, and blue entries. For
> instance, 'flag', 'rainbow', and 'gist_earth'.
> 
> Furthermore, 'gist_rainbow_r' and 'terrain_r' don't plot at all with
> the attached code.
> 
> I presume this is a regression from earlier behavior, since quite a
> few colormaps are affected. svn shows some cleanup to the colormap
> code this summer. Can someone with more familiarity with that code
> point to the problem?
Fixed in svn 7902.
Eric
> 
> Thanks,
> Eric
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Bruning wrote:
> I'm seeing problems with reversed colormaps (attached code and image).
> The problem seems to be with colormaps that are specified functionally
> or that don't have equal numbers of red, green, and blue entries. For
> instance, 'flag', 'rainbow', and 'gist_earth'.
> 
> Furthermore, 'gist_rainbow_r' and 'terrain_r' don't plot at all with
> the attached code.
> 
> I presume this is a regression from earlier behavior, since quite a
> few colormaps are affected. svn shows some cleanup to the colormap
> code this summer. Can someone with more familiarity with that code
> point to the problem?
I'll take care of it. Thanks for the bug report.
Eric
> 
> Thanks,
> Eric