[matplotlib-devel] contourf linewidth=1 help request

[Jordan Dawe]

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

[Eric Firing]

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

Post by Jordan Dawe
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

...

[Jordan Dawe]

Post by Eric Firing
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]

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

Post by Jordan Dawe

Post by Eric Firing
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
http://freedryk.dyndns.org:8080/matplotlib/example.py
http://freedryk.dyndns.org:8080/matplotlib/example.eps
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 Dawe]

Post by Eric Firing
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
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

[Eric Firing]

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

Post by Jordan Dawe

Post by Eric Firing
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
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
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

...

[John Hunter]

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

[Eric Firing]

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

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
------------------------------------------------------------------------

...

[Eric Firing]

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

Post by Jordan Dawe

Post by Eric Firing
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
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 Dawe]

Post by Eric Firing
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

[John Hunter]

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