I've tracked it down to this revision 7395
was was in response to bug *2832575*
http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720
I think this is reaching my limit of understanding of the color mapping code, so I'm hoping someone else has a solution that will fix one bug without creating another 
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Michael Droettboom wrote:
I've tracked it down to this revision 7395
That was John's. I knew there was a reason why I had written it the way it was before his change, but I didn't remember what that reason was, and didn't spend any time thinking about it.
was was in response to bug *2832575*
http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720
I think this is reaching my limit of understanding of the color mapping code, so I'm hoping someone else has a solution that will fix one bug without creating another
Yes, this will require some thought. It is just another aspect of the alpha mess in mpl in general.
I think there may be at least a crude fix for both the old bug and the new one. I will look at it later.
Eric
Cheers,
Mike------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Eric Firing wrote:
Michael Droettboom wrote:
I've tracked it down to this revision 7395
That was John's. I knew there was a reason why I had written it the way it was before his change, but I didn't remember what that reason was, and didn't spend any time thinking about it.
was was in response to bug *2832575*
http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720
I think this is reaching my limit of understanding of the color mapping code, so I'm hoping someone else has a solution that will fix one bug without creating another
Yes, this will require some thought. It is just another aspect of the alpha mess in mpl in general.
I think there may be at least a crude fix for both the old bug and the new one. I will look at it later.
OK, I applied the crude fix. I think it is good enough, and makes sense within the present framework. The basic idea is that the default for colormapping missing data was, and now again is, to use alpha=0 so as not to show it at all. It can be overridden by using the set_bad() method of the colormap. The problem was that the over- and under-range colors were being excluded from global alpha-setting, along with the bad color. Now over- and under- are treated like the rest of the colormap, but alpha for the bad values defaults to zero and must be set explicitly to another value if desired.
The svnmerge afterwards (r7425) makes me a little nervous, because it pulled in a lot of things that I did not change and that I know nothing about. Upon a quick scan the changes look plausible.
Eric
Eric
