matplotlib-devel Mailing List for matplotlib (Page 2)

We are delighted to announce that the Python Software Foundation has
answered our call and is providing sponsoring to the SciPy08 conference.
We will use this money to sponsor the registration fees and travel for up
to 10 college or graduate students to attend the conference. The PSF did
not provide all the founds required for all 10 students and once again
Enthought Inc. (http://www.enthought.com) is stepping up to fill in.
To apply, please send a short description of what you are studying and
why you’d like to attend to in...@en.... Please include telephone
contact information.
Thanks a lot to Travis Vaught from Enthought for bringing this project to
a success.
Please don't hesitate to forward this announcement to anybody who might
be interested.
Gaël, on behalf of the Scipy08 organisation committee
SciPy coneference site: http://conference.scipy.org

On Thu, Jun 26, 2008 at 01:50:29PM -0500, John Hunter wrote:
> I noticed Michael just made a commit adding plot directive examples in
> the doc strings. I think this is a great idea, and very cool, since
> the html docs for a given function will not only link to a complete
> code example, but also have inline figures and links to various output
> high res or vector formats. See for example, at the bottom of the
> help for the hexbin function
> http://matplotlib.sourceforge.net/doc/html/api/axes_api.html#matplotlib.axes.Axes.hexbin
Wow, guys this is really cool. I do hope that you are going to talk about
this at the SciPy08 conference. This is solid gold, IMHO.
Gaël

On Thu, Jun 26, 2008 at 3:14 PM, Eric Firing <ef...@ha...> wrote:
> I think a special place for doc examples is a very good idea; I don't see
> any real disadvantage.
I'm not real keen on this if it means moving the example from the
existing location, since the examples directory should be organized to
help the users learn rather than as a convenience to the developer.
The "doc_example" is not to useful to the user, who should be thinking
in terms of "pylab" or "api" or "dates" or "events" or "images". I
think I prefer in-place references or copies over this.
JDH

Michael Droettboom wrote:
> I was just about to write an e-mail about this. I just put a few in to 
> see what would blow up on other people's machines... ;)
> 
> Like John, I also have mixed feelings about moving the examples to 
> pyplots. 
> 
> Maybe we need a new subdirectory under examples called "doc_examples" or 
> something, and examples that are part of the docs get *moved*, not 
> copied, into there. Not a great solution either, but I'd hate for 
> either the doc examples or regular examples to get neglected or 
> out-of-sync just because there's now two very similar things to update.
I think a special place for doc examples is a very good idea; I don't 
see any real disadvantage.
Eric
> 
> A related issue with using some of the existing examples directly is 
> that they are multi-figure, which the documentation infrastructure 
> doesn't easily support -- plus, I don't think we want 7 examples for a 
> single function inline in the docs anyway. But it might be nice, for 
> example, to include an example of common usage, and then a link to more 
> advanced features.
> 
> Cheers,
> Mike
> 
> John Hunter wrote:
>> I noticed Michael just made a commit adding plot directive examples in
>> the doc strings. I think this is a great idea, and very cool, since
>> the html docs for a given function will not only link to a complete
>> code example, but also have inline figures and links to various output
>> high res or vector formats. See for example, at the bottom of the
>> help for the hexbin function
>>
>> http://matplotlib.sourceforge.net/doc/html/api/axes_api.html#matplotlib.axes.Axes.hexbin
>>
>> or
>>
>> http://matplotlib.sourceforge.net/doc/html/api/pyplot_api.html#matplotlib.pyplot.hexbin
>>
>> but I'd like to encourage everyone to clean up the examples they link
>> to, preferably so that they use the recommended idioms
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>>
>> Having a bunch of 'from pylab import *' code in our examples is
>> probably not a good idea as we are trying to encourage new users to be
>> more explicit about namespaces.
>>
>> We may also want to consider explicitly putting examples we literal
>> include into pyplots rather than linking to them through the
>> mpl_examples dir so we have more control over them vis-a-vis making
>> sure they look good at the rendered sizes and helping prevent
>> developers not working on the docs from inadvertently making changes
>> to the example that foul up the docs. I have mixed feelings about
>> this last point because of the redundancy -- the alternative is just
>> to clean them in place and makes sure developers know not to much with
>> them w/o checking the effect on the docs.
>>
>> But these minor nits aside, a very good idea Michael.
>> 

I was just about to write an e-mail about this. I just put a few in to 
see what would blow up on other people's machines... ;)
Like John, I also have mixed feelings about moving the examples to 
pyplots. 
Maybe we need a new subdirectory under examples called "doc_examples" or 
something, and examples that are part of the docs get *moved*, not 
copied, into there. Not a great solution either, but I'd hate for 
either the doc examples or regular examples to get neglected or 
out-of-sync just because there's now two very similar things to update.
A related issue with using some of the existing examples directly is 
that they are multi-figure, which the documentation infrastructure 
doesn't easily support -- plus, I don't think we want 7 examples for a 
single function inline in the docs anyway. But it might be nice, for 
example, to include an example of common usage, and then a link to more 
advanced features.
Cheers,
Mike
John Hunter wrote:
> I noticed Michael just made a commit adding plot directive examples in
> the doc strings. I think this is a great idea, and very cool, since
> the html docs for a given function will not only link to a complete
> code example, but also have inline figures and links to various output
> high res or vector formats. See for example, at the bottom of the
> help for the hexbin function
>
> http://matplotlib.sourceforge.net/doc/html/api/axes_api.html#matplotlib.axes.Axes.hexbin
>
> or
>
> http://matplotlib.sourceforge.net/doc/html/api/pyplot_api.html#matplotlib.pyplot.hexbin
>
> but I'd like to encourage everyone to clean up the examples they link
> to, preferably so that they use the recommended idioms
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> Having a bunch of 'from pylab import *' code in our examples is
> probably not a good idea as we are trying to encourage new users to be
> more explicit about namespaces.
>
> We may also want to consider explicitly putting examples we literal
> include into pyplots rather than linking to them through the
> mpl_examples dir so we have more control over them vis-a-vis making
> sure they look good at the rendered sizes and helping prevent
> developers not working on the docs from inadvertently making changes
> to the example that foul up the docs. I have mixed feelings about
> this last point because of the redundancy -- the alternative is just
> to clean them in place and makes sure developers know not to much with
> them w/o checking the effect on the docs.
>
> But these minor nits aside, a very good idea Michael.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I noticed Michael just made a commit adding plot directive examples in
the doc strings. I think this is a great idea, and very cool, since
the html docs for a given function will not only link to a complete
code example, but also have inline figures and links to various output
high res or vector formats. See for example, at the bottom of the
help for the hexbin function
 http://matplotlib.sourceforge.net/doc/html/api/axes_api.html#matplotlib.axes.Axes.hexbin
or
 http://matplotlib.sourceforge.net/doc/html/api/pyplot_api.html#matplotlib.pyplot.hexbin
but I'd like to encourage everyone to clean up the examples they link
to, preferably so that they use the recommended idioms
 import numpy as np
 import matplotlib.pyplot as plt
Having a bunch of 'from pylab import *' code in our examples is
probably not a good idea as we are trying to encourage new users to be
more explicit about namespaces.
We may also want to consider explicitly putting examples we literal
include into pyplots rather than linking to them through the
mpl_examples dir so we have more control over them vis-a-vis making
sure they look good at the rendered sizes and helping prevent
developers not working on the docs from inadvertently making changes
to the example that foul up the docs. I have mixed feelings about
this last point because of the redundancy -- the alternative is just
to clean them in place and makes sure developers know not to much with
them w/o checking the effect on the docs.
But these minor nits aside, a very good idea Michael.
JDH

On Jun 25, 2008, at 8:38 PM, Michael Droettboom wrote:
> Ahh -- 0.91 avoided this by using non-antialiased rendering by 
> default for pcolor as well as pcolormesh. That's probably what Rob 
> is seeing when he went from 0.91 to 0.98.
Indeed. Now that I think about it in the light of the discussion 
here, it may be that I have seen this behavior before, but not by 
default. What surprised me is that I was getting this sort of result 
using the same function as previously.
A sample showing the different behavior might be something like:
x, y = meshgrid(arange(50), arange(100))
y *= 1 + sin(x/30.0)
y += 10.0*sqrt(x)
z = (x+y)**2
figure()
pcolor(x, y, z)
figure()
pcolor(x, y, z, antialiased=False)
# pcolormesh gives similar results to antialiased=False
# further tests with missing values in y
y = np.ma.masked_where(y< 100, y)
pcolor(x, y, z, antialiased=False)
# pcolormesh fails.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Michael Droettboom wrote:
> Ahh -- 0.91 avoided this by using non-antialiased rendering by default 
> for pcolor as well as pcolormesh. That's probably what Rob is seeing 
> when he went from 0.91 to 0.98.
I suspected that.
> 
> Of course, non-antialiased rendering has its own quality limitations, 
> and it only applies to the bitmap backends. The moire pattern still 
> appears in (for example) a pdf viewed with Acrobat Reader without the 
> edge workaround.
True. Still, it might be that turning off antialiasing is part of the 
best compromise for some backends. We weren't getting complaints with 
0.91, as far as I recall. There may be speed considerations here also.
> 
> Eric -- maybe we should experiment with different values for the edge 
> width to find a good compromise. Also, it might be good to add a 
Yes, this is worth some more experimentation. A problem is that the 
edge width is specified in points, and the effect of this will depend on 
backend and scaling. If it turns out that there is an optimal value for 
each backend then we could pass in a special value for this case, say 
-1, which would be intercepted by the backend and converted to whatever 
works for that backend.
As you note, the problem is made even more complex by the fact that 
different programs may render the vector graphics (pdf, ps, svg) 
differently.
Someone must have already sorted all this out for some software project, 
somewhere. Does cairo handle it better? I have not looked yet.
> regression test example where the edge workaround introduces noticeable 
> negative artifacts. quadmesh_demo.py (with its built-in smoothness) 
> doesn't really highlight the problems with that approach.
Yes, a really good set of test cases would help.
Eric
> 
> Cheers,
> Mike
> 
> Michael Droettboom wrote:
>> Ok -- sorry about that. It looked pretty good on the quadmesh_demo 
>> example, but I suppose that's just by accident due to the nature of 
>> the data. By this assessment, we should probably back out this hack 
>> in pcolormesh as well.
>>
>> Curiously, though, Rob says this is new behavior...
>>
>> Cheers,
>> Mike
>>
>> Eric Firing wrote:
>> 
>>> Michael Droettboom wrote:
>>> 
>>>> Rob Hetland wrote:
>>>> 
>>>>> When I do a pcolor, there are white lines between the patches that 
>>>>> cause strange moray patterns, even when saved to a png. The 
>>>>> attached sample shows what I mean. Notice the strange coffee-cup 
>>>>> ring, where the pattern goes away. This is new behavior. 
>>>>> Unfortunately, I haven't been paying enough attention to the devel 
>>>>> list to know what the changes that cause this might be.
>>>>> 
>>>> The quads need to be enlarged by about 1 pixel, and the easiest way 
>>>> to do this is to give them an edge of width 1 pixel. The pcolormesh 
>>>> code has had this fix for a while, but it was overlooked for 
>>>> pcolor. (Both of which were virtually rewritten for 0.98, which is 
>>>> why this is a regression from 0.91).
>>>>
>>>> I have fixed this in SVN.
>>>> 
>>> Mike,
>>>
>>> Not exactly. This is a very old problem and an old attempted 
>>> solution. I struggled with it a long time ago, and among the 
>>> various combinations of backends and antialiasing settings, I never 
>>> found a completely satisfactory solution. I don't know what the best 
>>> solution will be, but a linewidth of 1 point is definitely not it. 
>>> It is fundamentally wrong--expanding the patch dimensions by 1/144 
>>> inch, so that they overlap--and consequently creates its own 
>>> artifacts. If you run the attached script and look at the ps output, 
>>> you will see artifacts in the rectangle corners, and some of the tick 
>>> marks will be more misplaced than they used to be relative to the 
>>> rectangle boundaries.
>>>
>>> I'm sorry I don't have a good solution right now and can't look at it 
>>> in detail immediately, and I don't mean to dump more work on you. 
>>> Let's just consider the issue as open for discussion and 
>>> investigation. I can try to get back to it later.
>>>
>>> (It is conceivable that a thinner linewidth will be an adequate 
>>> compromise--still a hack, but maybe acceptable--although the last 
>>> time I worked on this problem, long before 0.98, I could not get it 
>>> to work well under all circumstances.)
>>>
>>> Eric
>>> 
>>
>> 
> 

Ahh -- 0.91 avoided this by using non-antialiased rendering by default 
for pcolor as well as pcolormesh. That's probably what Rob is seeing 
when he went from 0.91 to 0.98.
Of course, non-antialiased rendering has its own quality limitations, 
and it only applies to the bitmap backends. The moire pattern still 
appears in (for example) a pdf viewed with Acrobat Reader without the 
edge workaround.
Eric -- maybe we should experiment with different values for the edge 
width to find a good compromise. Also, it might be good to add a 
regression test example where the edge workaround introduces noticeable 
negative artifacts. quadmesh_demo.py (with its built-in smoothness) 
doesn't really highlight the problems with that approach.
Cheers,
Mike
Michael Droettboom wrote:
> Ok -- sorry about that. It looked pretty good on the quadmesh_demo 
> example, but I suppose that's just by accident due to the nature of the 
> data. By this assessment, we should probably back out this hack in 
> pcolormesh as well.
>
> Curiously, though, Rob says this is new behavior...
>
> Cheers,
> Mike
>
> Eric Firing wrote:
> 
>> Michael Droettboom wrote:
>> 
>>> Rob Hetland wrote:
>>> 
>>>> When I do a pcolor, there are white lines between the patches that 
>>>> cause strange moray patterns, even when saved to a png. The 
>>>> attached sample shows what I mean. Notice the strange coffee-cup 
>>>> ring, where the pattern goes away. This is new behavior. 
>>>> Unfortunately, I haven't been paying enough attention to the devel 
>>>> list to know what the changes that cause this might be.
>>>> 
>>> The quads need to be enlarged by about 1 pixel, and the easiest way 
>>> to do this is to give them an edge of width 1 pixel. The pcolormesh 
>>> code has had this fix for a while, but it was overlooked for pcolor. 
>>> (Both of which were virtually rewritten for 0.98, which is why this 
>>> is a regression from 0.91).
>>>
>>> I have fixed this in SVN.
>>> 
>> Mike,
>>
>> Not exactly. This is a very old problem and an old attempted 
>> solution. I struggled with it a long time ago, and among the various 
>> combinations of backends and antialiasing settings, I never found a 
>> completely satisfactory solution. I don't know what the best solution 
>> will be, but a linewidth of 1 point is definitely not it. It is 
>> fundamentally wrong--expanding the patch dimensions by 1/144 inch, so 
>> that they overlap--and consequently creates its own artifacts. If you 
>> run the attached script and look at the ps output, you will see 
>> artifacts in the rectangle corners, and some of the tick marks will be 
>> more misplaced than they used to be relative to the rectangle boundaries.
>>
>> I'm sorry I don't have a good solution right now and can't look at it 
>> in detail immediately, and I don't mean to dump more work on you. 
>> Let's just consider the issue as open for discussion and 
>> investigation. I can try to get back to it later.
>>
>> (It is conceivable that a thinner linewidth will be an adequate 
>> compromise--still a hack, but maybe acceptable--although the last time 
>> I worked on this problem, long before 0.98, I could not get it to work 
>> well under all circumstances.)
>>
>> Eric
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Ok -- sorry about that. It looked pretty good on the quadmesh_demo 
example, but I suppose that's just by accident due to the nature of the 
data. By this assessment, we should probably back out this hack in 
pcolormesh as well.
Curiously, though, Rob says this is new behavior...
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Rob Hetland wrote:
>>> When I do a pcolor, there are white lines between the patches that 
>>> cause strange moray patterns, even when saved to a png. The 
>>> attached sample shows what I mean. Notice the strange coffee-cup 
>>> ring, where the pattern goes away. This is new behavior. 
>>> Unfortunately, I haven't been paying enough attention to the devel 
>>> list to know what the changes that cause this might be.
>> The quads need to be enlarged by about 1 pixel, and the easiest way 
>> to do this is to give them an edge of width 1 pixel. The pcolormesh 
>> code has had this fix for a while, but it was overlooked for pcolor. 
>> (Both of which were virtually rewritten for 0.98, which is why this 
>> is a regression from 0.91).
>>
>> I have fixed this in SVN.
>
> Mike,
>
> Not exactly. This is a very old problem and an old attempted 
> solution. I struggled with it a long time ago, and among the various 
> combinations of backends and antialiasing settings, I never found a 
> completely satisfactory solution. I don't know what the best solution 
> will be, but a linewidth of 1 point is definitely not it. It is 
> fundamentally wrong--expanding the patch dimensions by 1/144 inch, so 
> that they overlap--and consequently creates its own artifacts. If you 
> run the attached script and look at the ps output, you will see 
> artifacts in the rectangle corners, and some of the tick marks will be 
> more misplaced than they used to be relative to the rectangle boundaries.
>
> I'm sorry I don't have a good solution right now and can't look at it 
> in detail immediately, and I don't mean to dump more work on you. 
> Let's just consider the issue as open for discussion and 
> investigation. I can try to get back to it later.
>
> (It is conceivable that a thinner linewidth will be an adequate 
> compromise--still a hack, but maybe acceptable--although the last time 
> I worked on this problem, long before 0.98, I could not get it to work 
> well under all circumstances.)
>
> Eric
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Rob Hetland wrote:
>> When I do a pcolor, there are white lines between the patches that 
>> cause strange moray patterns, even when saved to a png. The attached 
>> sample shows what I mean. Notice the strange coffee-cup ring, where 
>> the pattern goes away. This is new behavior. Unfortunately, I 
>> haven't been paying enough attention to the devel list to know what 
>> the changes that cause this might be.
> The quads need to be enlarged by about 1 pixel, and the easiest way to 
> do this is to give them an edge of width 1 pixel. The pcolormesh code 
> has had this fix for a while, but it was overlooked for pcolor. (Both 
> of which were virtually rewritten for 0.98, which is why this is a 
> regression from 0.91).
> 
> I have fixed this in SVN.
Mike,
Not exactly. This is a very old problem and an old attempted solution. 
 I struggled with it a long time ago, and among the various 
combinations of backends and antialiasing settings, I never found a 
completely satisfactory solution. I don't know what the best solution 
will be, but a linewidth of 1 point is definitely not it. It is 
fundamentally wrong--expanding the patch dimensions by 1/144 inch, so 
that they overlap--and consequently creates its own artifacts. If you 
run the attached script and look at the ps output, you will see 
artifacts in the rectangle corners, and some of the tick marks will be 
more misplaced than they used to be relative to the rectangle boundaries.
I'm sorry I don't have a good solution right now and can't look at it in 
detail immediately, and I don't mean to dump more work on you. Let's 
just consider the issue as open for discussion and investigation. I can 
try to get back to it later.
(It is conceivable that a thinner linewidth will be an adequate 
compromise--still a hack, but maybe acceptable--although the last time I 
worked on this problem, long before 0.98, I could not get it to work 
well under all circumstances.)
Eric

Michael Droettboom wrote:
>> get_frame and get_patch deprecated - just use "patch" and "frame",
>> formerly "axesPatch" and "axesFrame". We'll add a deprecation warning
>> to get_frame and keep axesPatch and axesFrame around as aliases.
>>
>> Michael -- IIRC you added the axesFrame. Was this to support to
>> separate drawing of the edge and face since our patches don't
>> (currently) have support for separate alpha channels for edge and
>> face. Or are there additional motivations for the projection
>> backends?
I did it two years ago, r2415.
> It was so that the zorder could be something like:
> 
> axesPatch
> ... data ...
> ... grids ...
> axesFrame
> 
This was the main motivation, but the secondary thought was that it 
would facilitate doing something that people ask for now and then, which 
is allow one to specify only some axes boundaries instead of the whole 
rectangle. A common plot style is to have axes lines on the left and 
bottom, for example; but sometimes people want only a line on the 
bottom, and I am sure that sooner or later someone will want top and 
right, or top and bottom, or whatever. Obviously, I never got around to 
putting that option in place.
> It prevents data from overlapping the axes frame. This was most crucial 
> in the PDF and Cairo backends where the clipping rectangle is 
> pixel-aligned but the axes frame and background are not necessarily. In 
> the Agg backend, where we have more fine control, it actually doesn't 
> really matter.
No, I think it matters on all backends, especially if the frame is 
thick. Whether the zorder above is what one wants may be a matter of 
taste, but on any backend it will make a difference in the way the plot 
looks.
Eric
> 
> Cheers,
> Mike
> 

John Hunter wrote:
> On Wed, Jun 25, 2008 at 9:23 AM, John Hunter <jd...@gm...> wrote:
> 
>> On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <md...@st...> wrote:
>> 
>>> "rectangle" might be a bad name for "axesPatch" since it can be a circle for
>>> polar plots, and ellipse for geo plots etc.
>>> 
>> Ahh yes, mind still mushy even after a good night's sleep. "patch" or
>> "background" I feel about the same. "patch" isn't terribly mnemonic
>> unless you are a matlab user, but at least it points you to the base
>> class and is most consistent with the current name, in which the
>> "figure" part of "figurePatch" is simply redundant.
>> 
>
> I was just confused by the method "get_axes_patch" which looks like an
> accessor method for the axesPatch, but instead is the method that
> generates a new rectangle (or circle or whatever). To add to the
> confusion, there is the method get_frame, which returns the axesPatch
> even though there is also an axesFrame (which was created by
> get_axes_patch). Is you head spinning like mine?
> 
Yes, I saw that when I added the transparent kwarg and was also 
confused, but thought best to leave it at the time... ;)
> How about:
>
> _generate_axes_patch to replace get_axes_patch - internal class use only
>
> get_frame and get_patch deprecated - just use "patch" and "frame",
> formerly "axesPatch" and "axesFrame". We'll add a deprecation warning
> to get_frame and keep axesPatch and axesFrame around as aliases.
>
> Michael -- IIRC you added the axesFrame. Was this to support to
> separate drawing of the edge and face since our patches don't
> (currently) have support for separate alpha channels for edge and
> face. Or are there additional motivations for the projection
> backends?
It was so that the zorder could be something like:
 axesPatch
 ... data ...
 ... grids ...
 axesFrame
It prevents data from overlapping the axes frame. This was most crucial 
in the PDF and Cairo backends where the clipping rectangle is 
pixel-aligned but the axes frame and background are not necessarily. In 
the Agg backend, where we have more fine control, it actually doesn't 
really matter.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Jun 25, 2008 at 9:23 AM, John Hunter <jd...@gm...> wrote:
> On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <md...@st...> wrote:
>> "rectangle" might be a bad name for "axesPatch" since it can be a circle for
>> polar plots, and ellipse for geo plots etc.
>
> Ahh yes, mind still mushy even after a good night's sleep. "patch" or
> "background" I feel about the same. "patch" isn't terribly mnemonic
> unless you are a matlab user, but at least it points you to the base
> class and is most consistent with the current name, in which the
> "figure" part of "figurePatch" is simply redundant.
I was just confused by the method "get_axes_patch" which looks like an
accessor method for the axesPatch, but instead is the method that
generates a new rectangle (or circle or whatever). To add to the
confusion, there is the method get_frame, which returns the axesPatch
even though there is also an axesFrame (which was created by
get_axes_patch). Is you head spinning like mine?
How about:
 _generate_axes_patch to replace get_axes_patch - internal class use only
 get_frame and get_patch deprecated - just use "patch" and "frame",
formerly "axesPatch" and "axesFrame". We'll add a deprecation warning
to get_frame and keep axesPatch and axesFrame around as aliases.
Michael -- IIRC you added the axesFrame. Was this to support to
separate drawing of the edge and face since our patches don't
(currently) have support for separate alpha channels for edge and
face. Or are there additional motivations for the projection
backends?
JDH

On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <md...@st...> wrote:
> "rectangle" might be a bad name for "axesPatch" since it can be a circle for
> polar plots, and ellipse for geo plots etc.
Ahh yes, mind still mushy even after a good night's sleep. "patch" or
"background" I feel about the same. "patch" isn't terribly mnemonic
unless you are a matlab user, but at least it points you to the base
class and is most consistent with the current name, in which the
"figure" part of "figurePatch" is simply redundant.
patch, going once, going twice,...
JDH

"rectangle" might be a bad name for "axesPatch" since it can be a circle 
for polar plots, and ellipse for geo plots etc.
Cheers,
Mike
John Hunter wrote:
> On Wed, Jun 25, 2008 at 8:25 AM, Stéfan van der Walt <st...@su...> wrote:
> 
>> 2008年6月25日 Michael Droettboom <md...@st...>:
>> 
>>> Maybe this should be made an option on the "transparent" kwarg to savefig,
>>> something like:
>>>
>>> transparent = 'figure' | 'figure_and_axes'
>>>
>>> Or is that just making things too complicated?
>>> 
>> Those options would both be very handy.
>> 
>
> Stefan -- just for a little background. The figure has a
> matplotlib.patches.Rectangle instance called "figurePatch" and the
> axes has a Rectangle instance called axesPatch. You can set any
> property on them directly (facecolor, edgecolor, linewidth, linestyle,
> alpha). Eg,
>
> fig = plt.figure()
> fig.figurePatch.set_alpha(0.5)
> ax = fig.add_subplot(111)
> ax.axesPatch.set_alpha(0.5)
>
> Michael's transparent kwarg is just a helper function to do this
> automatically at save time w/o affecting the screen rendered figure.
> For stylistic reasons, I'd like a new name for figurePatch and
> rectanglePatch. "background", "rectangle" and "patch" would all be
> nicer. I'm inclined toward "rectangle" -- I think I'll just put an
> alias in Figure and Axes unless someone has a better idea.
>
> JDH
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Jun 25, 2008 at 8:25 AM, Stéfan van der Walt <st...@su...> wrote:
> 2008年6月25日 Michael Droettboom <md...@st...>:
>> Maybe this should be made an option on the "transparent" kwarg to savefig,
>> something like:
>>
>> transparent = 'figure' | 'figure_and_axes'
>>
>> Or is that just making things too complicated?
>
> Those options would both be very handy.
Stefan -- just for a little background. The figure has a
matplotlib.patches.Rectangle instance called "figurePatch" and the
axes has a Rectangle instance called axesPatch. You can set any
property on them directly (facecolor, edgecolor, linewidth, linestyle,
alpha). Eg,
 fig = plt.figure()
 fig.figurePatch.set_alpha(0.5)
 ax = fig.add_subplot(111)
 ax.axesPatch.set_alpha(0.5)
Michael's transparent kwarg is just a helper function to do this
automatically at save time w/o affecting the screen rendered figure.
For stylistic reasons, I'd like a new name for figurePatch and
rectanglePatch. "background", "rectangle" and "patch" would all be
nicer. I'm inclined toward "rectangle" -- I think I'll just put an
alias in Figure and Axes unless someone has a better idea.
JDH

2008年6月25日 Michael Droettboom <md...@st...>:
> Maybe this should be made an option on the "transparent" kwarg to savefig,
> something like:
>
> transparent = 'figure' | 'figure_and_axes'
>
> Or is that just making things too complicated?
Those options would both be very handy.
In the meantime, thanks for the workaround! My hack was to export to
SVG, then edit with Inkscape (first compiled Inkscape for OSX :), save
to PNG and finally convert the PNG to a PNG that Firefox can
understand, using GIMP (also compiled for OSX). Phew!
Regarding OSX: it seems that, for the first time in months, I can now
build matplotlib on OSX with gcc 4.1 without jumping through all sorts
of crazy loops. Thanks!
Regards
Stéfan

Rob Hetland wrote:
>
> When I do a pcolor, there are white lines between the patches that 
> cause strange moray patterns, even when saved to a png. The attached 
> sample shows what I mean. Notice the strange coffee-cup ring, where 
> the pattern goes away. This is new behavior. Unfortunately, I 
> haven't been paying enough attention to the devel list to know what 
> the changes that cause this might be.
The quads need to be enlarged by about 1 pixel, and the easiest way to 
do this is to give them an edge of width 1 pixel. The pcolormesh code 
has had this fix for a while, but it was overlooked for pcolor. (Both 
of which were virtually rewritten for 0.98, which is why this is a 
regression from 0.91).
I have fixed this in SVN.
>
> This moray pattern is very distracting, and means that publication 
> quality prints will be very difficult to produce, probably involving 
> printing at some insanely high resolution, then decimating with 
> imagemagick.
Yeah, let's try to avoid that... ;)
>
> I notice also that pcolormesh works with masked arrays (hurray!). 
> This could be a suitable substitution. However, pcolormesh does not 
> dither at the patch edges, so that there are jagged lines through the 
> image, especially at lower resolutions.
I assume by dithering you mean antialiasing. For speed, pcolormesh uses 
non-antialiased rendering by default. You can force it to be 
antialiased by passing "antialiased=True".
Cheers,
Mike
>
> Can pcolor be fixed?
>
> -Rob
>
>
>
> ------------------------------------------------------------------------
>
>
>
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Something similar was added to SVN yesterday. Pass "transparent=True" 
to savefig. This will set both the figure rectangle and the axes 
rectangles to transparent.
If you just want a transparent figure rectangle, you can do:
 fig().figurePatch.set_alpha(0.0)
Maybe this should be made an option on the "transparent" kwarg to 
savefig, something like:
 transparent = 'figure' | 'figure_and_axes'
Or is that just making things too complicated?
Cheers,
Mike
Stéfan van der Walt wrote:
> Hi all,
>
> I'm generating plots for a document with a non-white background, and I
> need the outer rectangle (the one is normally gray on the screen) to
> be transparent. Savefig doesn't seem to have such an option: is it
> possible to do it already, and if not, would there be any interest in
> a patch?
>
> Regards
> Stéfan
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

When I do a pcolor, there are white lines between the patches that 
cause strange moray patterns, even when saved to a png. The attached 
sample shows what I mean. Notice the strange coffee-cup ring, where 
the pattern goes away. This is new behavior. Unfortunately, I 
haven't been paying enough attention to the devel list to know what 
the changes that cause this might be.
This moray pattern is very distracting, and means that publication 
quality prints will be very difficult to produce, probably involving 
printing at some insanely high resolution, then decimating with 
imagemagick.
I notice also that pcolormesh works with masked arrays (hurray!). 
This could be a suitable substitution. However, pcolormesh does not 
dither at the patch edges, so that there are jagged lines through the 
image, especially at lower resolutions.
Can pcolor be fixed?
-Rob

Hi all,
I'm generating plots for a document with a non-white background, and I
need the outer rectangle (the one is normally gray on the screen) to
be transparent. Savefig doesn't seem to have such an option: is it
possible to do it already, and if not, would there be any interest in
a patch?
Regards
Stéfan

Michael Droettboom wrote:
> I don't understand why anyone would want the one on the left, 
> but if you can provide a use case for it, it should be implementable.
I know I can't. I think john may be right that it's just not that hard 
to do by hand.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

2008年6月24日 John Hunter <jd...@gm...>:
> Committed to svn r5654 -- here is the test script::
>
> import numpy as np
> import matplotlib.pyplot as plt
> plt.plot(np.random.rand(10), 'x-', label='first line')
> plt.plot(np.random.rand(10), 'o-.', label='second line')
> plt.legend(numpoints=1)
> plt.show()
Thank you very much, that looks great!
Regards
Stéfan

On 2008年6月24日 14:03:33 -0500
 "John Hunter" <jd...@gm...> wrote:
> On Tue, Jun 24, 2008 at 1:27 PM, Nils Wagner
> <nw...@ia...> wrote:
> 
>> Actually, I would like to display an image (png format)
>> 'under' several lines.
>> Assuming that a watermark function will be supported by
>> mpl, it would be nice to have an example in
>>
>> matplotlib/examples/pylab_examples
> 
> johnh@flag:examples> svn commit -m 'added simple 
>watermark examples'
> Adding examples/api/watermark_image.py
> Adding examples/api/watermark_text.py
> Adding (bin) examples/data/logo2.png
> Transmitting file data ...
> Committed revision 5669.
 
Great ! Thank you very much !!
Nils