matplotlib-devel Mailing List for matplotlib

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 <ef...@ha...> 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

And the attachment...
On 20/04/2008, Eric Firing <ef...@ha...> wrote:

On 20/04/2008, Eric Firing <ef...@ha...> 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

Stéfan van der Walt wrote:
> On 20/04/2008, Eric Firing <ef...@ha...> 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:
> 
> http://mentat.za.net/refer/contours.ps
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 <ef...@ha...> 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:
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 Mon, Apr 7, 2008 at 8:38 AM, Manuel Metz <mm...@as...> wrote:
> The problem is that "release_zoom" in backend_bases.py is called twice in
> the above case if zoomed to a twinx'ed plot. One way to fix this behavior is
> to set a "twin" attribute to the axes instance. Attached is a patch against
> the 0.91 trunk.
>
> John: is this okay or is there a better way to fix the problem?
Hey Manuel, thanks for fixng this. I don't think it is critical that
this be fixed on the maintenance branch since it is a relatively small
bug (only applies in twinned axes) but I have a minor suggestion for
you in the fix for the trunk. It is not a good idea for a class
outside the axes to access a "protected" "_twinx" attribute. Probably
better is to either make the attribute public by naming it "istwinx"
or something like that, or make a method.
JDH

Hi,
 I have fixed the double-zoom Bug in the trunk (revision 5053), but 
not in the 0_91maint branch. In 0.91 it's not so easy to find out 
whether an axes is shared with another (cbook:Group is nice ;-) ) For 
0.91: is it always guaranteed that the release_zoom event for the master 
is called before that of the shared axes ? (I don't think so.) Then it 
would be more easy to test for the shared axes ...
 So there is still the old solution (see previous post) to introduce 
an argument twinx,twiny #%$(/"/'+*#*# I don't like that.
Manuel

Stephane Raynaud wrote:
> Hi,
> 
> I think that "collection._alpha = self.alpha" (or something better)
> are missing in ContoutSet.__init__, because _alpha from collections
> (Line or Poly) overrides the alpha value the color of
> "collection.set_color(color)" found in method "changed" of ContourSet.
> Therefore, alpha doesn't work for contours (filled or not).
> 
> Nota: If "collection.set_alpha" is used, it fails with line contouring
> because self._edgecolors is an empty list.
> 
> I hope it can help.
> 
Stephane,
It did help, thank you. I have fixed this in svn, rev 5051.
Eric

Stéfan van der Walt wrote:
> Hi Eric
> 
> On 18/04/2008, Eric Firing <ef...@ha...> wrote:
>> 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
> 
> Regards
> Stéfan