matplotlib-devel Mailing List for matplotlib

On Fri, Aug 7, 2009 at 8:27 AM, Reinier Heeres<re...@he...> wrote:
> Hi,
>
> This looks great! I'd be happy to try and work on this for mplot3d as well.
>
> Ryan: as for your patch, I'll look at it over the weekend or next week
> and see if I can apply it to trunk.
Hey Reinier, while you are looking these over, I just wanted to make
sure you saw these two mplo3d bugs posted on the tracker
 https://sourceforge.net/tracker/?func=detail&aid=2830483&group_id=80706&atid=560720
 https://sourceforge.net/tracker/?func=detail&aid=2834105&group_id=80706&atid=560720
Normally, I can assign bugs on the tracker to a developer, but for
some reason even though you are permissioned in the
"Members" area for the tracker, your sf login isn't showing up in the
drop down of developers on the bugs page. If you are unable o manage
the bug, eg to change the resolution or status, let me know after you
have taken a look at these and I can close or update them as
necessary.
JDH

Eric Firing wrote:
> Michael Droettboom wrote:
>> I've tracked it down to this revision 7395
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=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
> 

Jae-Joon Lee wrote:
> My understanding is that MOVETO in the middle of the path serve as a
> CLOSEPOLY when the path is filled. So, I don't think it actually
> matters how holes are connected each other. And as you can see, the
> largest hole is actually composed of three different polygons that
> overlaps, and the funny pattern is due to this overlaps.
> 
> The attached is my attempt to solve this problem. "remove_cuts"
> removes the cuts in a way that a hole becomes a single closed polygon,
> although I'm not sure if the code is rigorous enough. It seems to work
> okay for your sample data. It assumes that cuts are always vertical
> lines but this assumption can be dropped if we do bookkepping of all
> the path segments.
> I hope the code turns out to be work okay in general.
> 
> Ideally, it would be better if something similar would be done inside
> the contouring routine.
An implementation of the path conversion is now in the reorder() 
function in cntr.c; as of svn r7422, it is used by contourf (and by 
contour, although for line contours it is merely copying data into the 
output arrays). In addition to the contourf_demo.py, I have tested it 
with basemap's simpletest.py and with random data, without detecting any 
obvious artifacts. More testing is welcome, of course.
Eric
> 
> -JJ
> 
> 
> 
> On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing<ef...@ha...> wrote:
>> Mike,
>>
>> When I eliminate the cuts from filled contour paths, I do find pathological
>> cases where the filling works correctly with the cuts in place, but not
>> without them. Attached are a data file and a script to plot it,
>> illustrating the problem. Is this due to a known limitation of filled
>> paths? In the example, the top two holes are connected to the lower hole,
>> instead of being connected directly to the outer boundary of the filled
>> region. Is this illegal? If so, I think we are stuck, because rearranging
>> the paths that cntr makes to eliminate this type of case would likely be
>> very difficult.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> ------------------------------------------------------------------------
>>