Hi all,
I noticed that, contrary to what the docstring says,
contourf(Z,10)
draws contour lines on the different levels.
The attached patch adds a draw_contours keyword that explicitly
controls this behaviour. I don't know why it works (I set linewidths
to 1 and the lines disappear?!), but it gives some idea of what I
needed.
Could someone update the docstring, or fix the broken behaviour?
Thanks
Stéfan
contourf.patch (2.74 KB)
St�fan van der Walt wrote:
Hi all,
I noticed that, contrary to what the docstring says,
contourf(Z,10)
draws contour lines on the different levels.
Stefan,
It doesn't on my machine with backend GtkAgg, and I have never seen this behavior. What backend are you using?
Eric
The attached patch adds a draw_contours keyword that explicitly
controls this behaviour. I don't know why it works (I set linewidths
to 1 and the lines disappear?!), but it gives some idea of what I
needed.Could someone update the docstring, or fix the broken behaviour?
Thanks
St�fan------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Hi Eric
It doesn't on my machine with backend GtkAgg, and I have never seen this
behavior. What backend are you using?
Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk
2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX
currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2).
I saw John posted a compiler error (resulting from this problem) on
some other list, so it's something to keep in mind.
Regards
Stéfan
On 18/04/2008, Eric Firing <efiring@...229...> wrote:
St�fan van der Walt wrote:
Hi Eric
It doesn't on my machine with backend GtkAgg, and I have never seen this
behavior. What backend are you using?Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk
Very odd. Would you try writing out postscript and pdf, please, and see whether they behave the same way?
2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX
currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2).
I saw John posted a compiler error (resulting from this problem) on
some other list, so it's something to keep in mind.
Yes, my colleague, Jules, and I ran into this yesterday. Very frustrating. We also ran into some sort of problem involving, apparently, a mixture of libraries and/or object modules with and without dual ppc/intel code, but from the error messages it was impossible for us to track down beyond that. It might have been obvious to an OSX wizard. Jules was trying to follow John's instructions carefully. Numpy went in flawlessly. Scipy went in OK, we think, but the test needed nosetest, and then when that was installed, it failed. We gave up on the matplotlib installation.
Eric
On 18/04/2008, Eric Firing <efiring@...229...> wrote:
Regards
St�fan
> Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk
>
Very odd. Would you try writing out postscript and pdf, please, and see
whether they behave the same way?
The contour lines are still visible:
http://mentat.za.net/refer/contours.ps
> 2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX
> currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2).
> I saw John posted a compiler error (resulting from this problem) on
> some other list, so it's something to keep in mind.
>
Yes, my colleague, Jules, and I ran into this yesterday. Very frustrating.
We also ran into some sort of problem involving, apparently, a mixture of
libraries and/or object modules with and without dual ppc/intel code, but
from the error messages it was impossible for us to track down beyond that.
It might have been obvious to an OSX wizard. Jules was trying to follow
John's instructions carefully. Numpy went in flawlessly. Scipy went in OK,
we think, but the test needed nosetest, and then when that was installed, it
failed. We gave up on the matplotlib installation.
I did the following:
a) Use macports to install gcc 4.2
b) Create /tmp/bin and link into it gcc-mp-4.2 and g++-mp-4.2. Set
this as my $PATH (otherwise, the system gcc is still picked up
sometimes, for some reason)
Now, matplotlib should build, but I still see many errors of the form
python(37779) malloc: *** error for object 0xa010c6d8: Non-aligned
pointer being freed
*** set a breakpoint in malloc_error_break to debug
whenever I generate a plot. Seems to work OK though.
Cheers
Stéfan
On 20/04/2008, Eric Firing <efiring@...229...> wrote:
St�fan van der Walt wrote:
Odd, I'm using matplotlib 0.98pre (svn) with GTKAgg (gtk 2.12.8, pygtk
Very odd. Would you try writing out postscript and pdf, please, and see
whether they behave the same way?The contour lines are still visible:
I don't see any contour lines; I see only the boundaries between patches. In other words, the plot looks the way I would expect it to. This is with evince or gv on a linux machine. (Both fail when trying to blow up the plot to 400%, but work at 200%.)
My sense is that there is an optical illusion effect making the boundaries look somewhat line-like, but it doesn't sound like this is what you are talking about, so I am baffled.
Do you see the problem if you run contourf_demo.py and use the gui to generate png, pdf, and ps files from figure 1? I still can't see any sign of it anywhere.
Would you send a png file generated with and without your workaround, please? That should get around any differences in postscript interpreters. Also helpful would be a ps file with and without your workaround, preferably of an extremely simple example so it will be easy to see the difference in the generated ps.
It sounds like you are seeing something fairly subtle that I am having a hard time seeing, and that is new with the transforms branch. Your patch must be pointing in the right direction, but I don't understand why, yet, and there should be no need for a kwarg; we don't want boundaries with contourf, period. The reason is that the contour algorithm we are using makes patches with slits, so rendering the boundary does not have the desired effect; one needs to call contour separately to get valid lines as boundaries. Then there is the problem that those lines don't *always* coincide with the corresponding patch boundaries, but this is generally not a problem unless the contours are ill-determined anyway. It is still bad, but there is no easy solution.
Eric
On 20/04/2008, Eric Firing <efiring@...229...> wrote:
I don't see any contour lines; I see only the boundaries between patches.
In other words, the plot looks the way I would expect it to. This is with
evince or gv on a linux machine. (Both fail when trying to blow up the plot
to 400%, but work at 200%.)
Attached is the script that generates the contour plot I'm interested
in. A PNG cropped from the PS onscreen is at
http://mentat.za.net/refer/contour_zoom.png
It's small, but the line should be clearly visible.
My sense is that there is an optical illusion effect making the boundaries
look somewhat line-like, but it doesn't sound like this is what you are
talking about, so I am baffled.
Could be -- maybe an interpolation effect? Odd thing is that the
lines are differently coloured. In fact, I can get *only* the lines
to render by commenting out certain lines in contour.py.
Do you see the problem if you run contourf_demo.py and use the gui to
generate png, pdf, and ps files from figure 1? I still can't see any sign
of it anywhere.
I see contour lines, as shown here:
http://mentat.za.net/refer/contour_demo.png
Would you send a png file generated with and without your workaround,
please? That should get around any differences in postscript interpreters.
They are here:
http://mentat.za.net/refer/contours_without_patch.png
http://mentat.za.net/refer/contours_with_patch.png
It sounds like you are seeing something fairly subtle that I am having a
hard time seeing, and that is new with the transforms branch.
I don't want to waste your time further with this problem, so if you
think the above png's look fine then I'll just use my workaround. It
might be a problem very specific to my setup.
Thanks for your time,
Stéfan
On 20/04/2008, Eric Firing <efiring@...229...> wrote:
St�fan,
OK, I see some differences now, and it looks like it is related to antialiasing and the rendering of patch boundaries. I have run into this sort of thing before, where depending on how patch edges are handled, and depending on the particular renderer and viewer combination, antialiasing can make the result better or worse. To make things even more confusing, a combination that looks good with alpha=1 can look bad with alpha<1.
Linewidth of 1 is a bit drastic, and can significantly shift the perceived boundaries. Maybe a smaller value would be adequate. I played with all this a long time ago before settling on linewidth of zero with antialiasing turned on, which seemed to be a good compromise. Either I was wrong, or the Agg rendering is different in Agg 2.4.
One of the strange things here is that even when I set the antialiased kwarg to False, I still seem to be getting antialiasing.
The lack of effect of the antialiasing kwarg on my system looks like a definite bug that requires investigation.
To be continued, but not right now.
Eric
St�fan van der Walt wrote:
On 20/04/2008, Eric Firing <efiring@...229...> wrote:
I don't see any contour lines; I see only the boundaries between patches.
In other words, the plot looks the way I would expect it to. This is with
evince or gv on a linux machine. (Both fail when trying to blow up the plot
to 400%, but work at 200%.)Attached is the script that generates the contour plot I'm interested
in. A PNG cropped from the PS onscreen is athttp://mentat.za.net/refer/contour_zoom.png
It's small, but the line should be clearly visible.
My sense is that there is an optical illusion effect making the boundaries
look somewhat line-like, but it doesn't sound like this is what you are
talking about, so I am baffled.Could be -- maybe an interpolation effect? Odd thing is that the
lines are differently coloured. In fact, I can get *only* the lines
to render by commenting out certain lines in contour.py.Do you see the problem if you run contourf_demo.py and use the gui to
generate png, pdf, and ps files from figure 1? I still can't see any sign
of it anywhere.I see contour lines, as shown here:
http://mentat.za.net/refer/contour_demo.png
Would you send a png file generated with and without your workaround,
please? That should get around any differences in postscript interpreters.They are here:
http://mentat.za.net/refer/contours_without_patch.png
http://mentat.za.net/refer/contours_with_patch.pngIt sounds like you are seeing something fairly subtle that I am having a
hard time seeing, and that is new with the transforms branch.I don't want to waste your time further with this problem, so if you
think the above png's look fine then I'll just use my workaround. It
might be a problem very specific to my setup.Thanks for your time,
St�fan
I was getting a similar bug, mac os x, enthought python distribution. They
weren't lines per se, but ugly seperations between filled contours. I tried
a number of things, to no avail.
Ultimately, the solution was just to replot the contourf multiple times. It
took care of all the ugliness.
Cheers!
-tf
--
View this message in context: http://www.nabble.com/Contourf-draws-contour-lines-tp16766750p23103326.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.
2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX
currently – a person needs to upgrade gcc first (from 4.0.1 to 4.2).
I saw John posted a compiler error (resulting from this problem) on
some other list, so it’s something to keep in mind.
Yes, my colleague, Jules, and I ran into this yesterday. Very
frustrating. We also ran into some sort of problem involving,
apparently, a mixture of libraries and/or object modules with and
without dual ppc/intel code, but from the error messages it was
impossible for us to track down beyond that. It might have been obvious
to an OSX wizard. Jules was trying to follow John’s instructions
carefully. Numpy went in flawlessly. Scipy went in OK, we think, but
the test needed nosetest, and then when that was installed, it failed.
We gave up on the matplotlib installation.
On a new machine without the proper depdendencies, you might want to try first the makefile in release/osx, which will wget the depenencies, build them with the right flag, and link them in statically. There is a README in that directory with instructions, but here is a crib sheet from the command history I just executed (which still works on my box)::
# build the dependencies
cd release/osx/
unset PKG_CONFIG_PATH
make fetch_deps
cd bdist_mpkg-0.4.3
sudo python setup.py install
cd ..
make dependencies
# build the mpl sdist
cd ../..
python setup.py sdist
mv dist/matplotlib-0.98.6svn.tar.gz release/osx/
# set the version number in the Makefile to 0.98.6svn and build the
# installers
cd release/osx/
make installers
On a machine that does have the dependencies properly buily and installed, I use
make build_osx105
with the Makefile that lives alongside setup.py. This still works for me with the native gcc 4.0.1 on my 10.5 machine and then you can do a normal python setup.py install.
On Sat, Apr 19, 2008 at 7:13 PM, Eric Firing <efiring@…552…229…> wrote: