Hi, I hope this is the proper place to send this message. I'm using matplotlib to make contourf plots with contour overlays. My problem is that I want to be able to use .25 pica lines for the overlaid contours, but since contourf demands a linethickness of 1. to avoid artifacts (due to the simply-connected domain contour algorhithm), the .25 contours don't actually fit the contourf right; there will be a thin line of color from the next contour around the contourf before the .25 pica line appears. This annoys me to no end. Currently I'm fixing it by plotting everything 4x larger than normal and then shrinking the eps files down in Illustrator, but this is not an ideal solution, since (for example) all the axis labels are in the wrong position at this size. My question is, how hard would it be to fix the contour code so that contourf's linethickness argument could be changed? Where in the codebase would I look to start hacking? In the contouring code? In the python code that accepts the contour algorithm output? I don't want to spend hours hunting through the code for the right place to start modifying things... Jordan
Jordan, Would you send a simple example script and sample plot, please? If I understand correctly what you are trying to do, it should work. Thanks. Eric Jordan Dawe wrote: > Hi, I hope this is the proper place to send this message. I'm using > matplotlib to make contourf plots with contour overlays. My problem is > that I want to be able to use .25 pica lines for the overlaid contours, > but since contourf demands a linethickness of 1. to avoid artifacts (due > to the simply-connected domain contour algorhithm), the .25 contours > don't actually fit the contourf right; there will be a thin line of > color from the next contour around the contourf before the .25 pica line > appears. This annoys me to no end. > > Currently I'm fixing it by plotting everything 4x larger than normal and > then shrinking the eps files down in Illustrator, but this is not an > ideal solution, since (for example) all the axis labels are in the wrong > position at this size. My question is, how hard would it be to fix the > contour code so that contourf's linethickness argument could be > changed? Where in the codebase would I look to start hacking? In the > contouring code? In the python code that accepts the contour algorithm > output? I don't want to spend hours hunting through the code for the > right place to start modifying things... > > Jordan > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Eric Firing wrote: > Jordan, > > Would you send a simple example script and sample plot, please? If I > understand correctly what you are trying to do, it should work. Ok, I stuck an example on my webserver. The script (heavily copied from contour_demo.py): http://freedryk.dyndns.org:8080/matplotlib/example.py The eps output: http://freedryk.dyndns.org:8080/matplotlib/example.eps And, in case it's easier for you, the eps output converted into pdf: http://freedryk.dyndns.org:8080/matplotlib/example.pdf The problem can be seen by zooming into one of the contour lines. There is about a .25 pica space between the contour lines and the filled contours. This doesn't occur if you use a 1 pica line, but I don't like thick lines... Jordan
Jordan, The correction--using a small linewidth for the patch boundary (which is the same color as the patch)--has been committed to CVS. Thanks for pointing out the problem. Eric Jordan Dawe wrote: > Eric Firing wrote: > >> Jordan, >> >> Would you send a simple example script and sample plot, please? If I >> understand correctly what you are trying to do, it should work. > > > Ok, I stuck an example on my webserver. The script (heavily copied from > contour_demo.py): > > http://freedryk.dyndns.org:8080/matplotlib/example.py > > The eps output: > > http://freedryk.dyndns.org:8080/matplotlib/example.eps > > And, in case it's easier for you, the eps output converted into pdf: > > http://freedryk.dyndns.org:8080/matplotlib/example.pdf > > The problem can be seen by zooming into one of the contour lines. There > is about a .25 pica space between the contour lines and the filled > contours. This doesn't occur if you use a 1 pica line, but I don't like > thick lines... > > Jordan >
Eric Firing wrote: > Jordan, > > Thanks, now I see the problem and where it is coming from. In > contour.py, near the bottom, in the contourf method, change the > linewidth from 1 to 0.01, so the line reads: > col = PolyCollection(nlist, linewidths=(0.01,)) > > I think this will be OK; based on the comment below the line, I think > I found that using a linewidth of zero was problematic, so I probably > simply used 1 thinking it was small enough not to matter. > > I will need to make a corresponding change in the CVS version so that > it will get into the next release. I'll do that this evening. > Sorry about this, but that patch doesn't seem to work. When I open the eps files generated with this change implimented, I get the artifact problem mentioned in the comment; fine lines at the boundaries of the contouring engine's subdomains. In fact, I get the artifacts at linewidths as large as 0.5. Jordan
Jordan, Strange, I did test the change and it worked fine with your example on my system. I will email you the result in a separate message so as not to clog the list. Then you can tell me if you see the problem in that file. Maybe I am misunderstanding something. Eric Jordan Dawe wrote: > Eric Firing wrote: > >> Jordan, >> >> Thanks, now I see the problem and where it is coming from. In >> contour.py, near the bottom, in the contourf method, change the >> linewidth from 1 to 0.01, so the line reads: >> col = PolyCollection(nlist, linewidths=(0.01,)) >> >> I think this will be OK; based on the comment below the line, I think >> I found that using a linewidth of zero was problematic, so I probably >> simply used 1 thinking it was small enough not to matter. >> >> I will need to make a corresponding change in the CVS version so that >> it will get into the next release. I'll do that this evening. >> > Sorry about this, but that patch doesn't seem to work. When I open the > eps files generated with this change implimented, I get the artifact > problem mentioned in the comment; fine lines at the boundaries of the > contouring engine's subdomains. In fact, I get the artifacts at > linewidths as large as 0.5. > > Jordan > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> Jordan, Strange, I did test the change and it worked fine Eric> with your example on my system. I will email you the result Eric> in a separate message so as not to clog the list. Then you Eric> can tell me if you see the problem in that file. Maybe I am Eric> misunderstanding something. Could be a CVS version problem -- make sure you are both working on the same CVS file(s) and the same test script. Historically, non-developer CVS tends to lag... JDH
Jordan, Evidently the reason we see different things is because the result with linewidth < 1 is renderer-dependent; ghostview (which I am using) and Illustrator handle the same file differently. To be sure we are agreeing on the phenomenon: Initially, with linewidth=1 in the contourf polygon generation, there was no problem with the subregion boundaries, but the polygons were a bit too large, so that thin line contours did not land exactly on the boundaries. Setting linewidth=0.01 fixes that problem, but introduces renderer-dependent artifacts at the subregion boundaries. The real solution, or part of it, may be in the backend (ps at least, maybe others): I think that we want to be able to specify a polygon with a zero-width boundary, such that it is filled but not stroked. Alternatively, it may be that the problem is one of rounding in the conversion of floating point vertices to integers in the renderer, in which case removing the boundary line entirely won't help at all. The division of the domain by cntr.c into subregions is controllable by a parameter; I can expose that parameter to the python level (this weekend, not this minute). Then setting it to a sufficiently large value will take care of the grid problem; and maybe it will have no bad side-effects. According to the comment in the contouring code, the reason for subdividing is that renderers bog down when filling polygons with too many vertices. It may be that this is no longer a problem; that comment may date from an earlier era. Eric Jordan Dawe wrote: > Yeah, I see artifacts in the eps file you sent me. I'm looking at it in > Illustrator CS, and the artifacts show up in Adobe Acrobat 6.0 as well. > They also show up when I take the eps and do a 'convert example.eps > example.png' on it. The resulting png is attached. > > The artifacts tend to change when I zoom in, so I'm guessing some of it > is related to the renderer in Illustrator, but I'm still worried they > will show up when they go to press. When the linewidth =1.0, the > artifacts don't show up at all, so I know it's possible to get rid of them. > > I'm willing to hunt through and try to fix this problem, but where would > it show up? In the PS render code? In the polygon handers? I know a > fair bit of python, but I don't know my way around matplotlib very well... > > Also, do you see any problems with me trying to make the cntr.c code > output one polygon per simply-connected region? Cause the current > "divide the fig up into 48 smaller areas" thing is annoying as hell when > you're working with eps. Matlab's renderer does this, why can't this one? > > Jordan > > ------------------------------------------------------------------------ >
Jordan, I have looked into various aspects of the problem you reported. It seems to be essentially a problem with antialiasing; all artifacts go away in the AGG backend with antialiasing turned off, regardless of the linewidth, right down to zero. With antialiasing on, however, it seems that a linewidth of about 0.5 with AGG (on my machine, with everything default) is needed to prevent the antialiasing from leaving light lines at polygon boundaries, regardless of whether they are the straight boundaries caused by chunking or the curved boundaries of the contours themselves. With Postscript, as rendered by ghostscript via gv, I see artifacts only with a much smaller linewidth, and only at some magnifications. Your ps viewers may be doing more antialiasing, and therefore showing artifacts over a larger range of linewidths. There is probably more going on, and more to be understood, but this got me far enough to manage the problem for now. It looks like there is no problem with simply turning off the chunking. I have made a bunch of changes in CVS, including turning off the chunking by default, and allowing one to specify chunking, antialiasing, and linewidth explicitly for contourf. So, I think you will find that if you use the CVS version, the problems you reported will go away. If you haven't done it before, you will find that downloading and installing from CVS is very quick and easy; instructions are given on the sourceforge download site. (As John notes, there may be a lag between developer CVS and the mirrors; make sure that what you download includes my changes, committed a few minutes ago.) Alternatively, if you simply want to turn off chunking in 0.84, you can do it by editing cntr.c, approximately line 1384, change long nchunk = 30; /* hardwired for now */ to long nchunk = 0; /* hardwired for now */ and recompile/reinstall. If you use the CVS version (or the next mpl release, whenever that comes out), note that the APIs for contour, contourf, and clabel have changed as described in API_CHANGES and as illustrated in examples/contour_demo.py and contourf_demo.py. Eric Jordan Dawe wrote: > Eric Firing wrote: > >> Jordan, >> >> Thanks, now I see the problem and where it is coming from. In >> contour.py, near the bottom, in the contourf method, change the >> linewidth from 1 to 0.01, so the line reads: >> col = PolyCollection(nlist, linewidths=(0.01,)) >> >> I think this will be OK; based on the comment below the line, I think >> I found that using a linewidth of zero was problematic, so I probably >> simply used 1 thinking it was small enough not to matter. >> >> I will need to make a corresponding change in the CVS version so that >> it will get into the next release. I'll do that this evening. >> > Sorry about this, but that patch doesn't seem to work. When I open the > eps files generated with this change implimented, I get the artifact > problem mentioned in the comment; fine lines at the boundaries of the > contouring engine's subdomains. In fact, I get the artifacts at > linewidths as large as 0.5. > > Jordan
> > It looks like there is no problem with simply turning off the > chunking. I have made a bunch of changes in CVS, including turning > off the chunking by default, and allowing one to specify chunking, > antialiasing, and linewidth explicitly for contourf. So, I think you > will find that if you use the CVS version, the problems you reported > will go away. If you haven't done it before, you will find that > downloading and installing from CVS is very quick and easy; > instructions are given on the sourceforge download site. Sweet, will do. I am using the CVS version currently; I just submitted a patch to the sourceforge page to make it easier for me to compile, since I am running under cygwin most of the time. I have a couple of other patches I intend to submit when I have a spare moment; is the sourceforge page the proper place to do that? Jordan
>>>>> "Jordan" == Jordan Dawe <fre...@oc...> writes: Jordan> Sweet, will do. I am using the CVS version currently; I Jordan> just submitted a patch to the sourceforge page to make it Jordan> easier for me to compile, since I am running under cygwin Jordan> most of the time. I have a couple of other patches I Jordan> intend to submit when I have a spare moment; is the Jordan> sourceforge page the proper place to do that? Yes -- just send a note here describing what is in them so we can be sure to include them. Bunch them together where possible to save work. Thanks, JDH