matplotlib-devel Mailing List for matplotlib (Page 2)

Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
>> Eric Firing <ef...@ha...> writes:
>> 
>>> John Hunter wrote:
>>> 
>>>> One possibility would be to have a facecolor/edgecolor property on
>>>> the gc itself, which would be rgba tuples. Since the gc is almost
>>>> entirely internal, we can revamp it w/o affecting userland code,
>>>> though it would be nice to support legacy methods (eg gc.set_alpha
>>>> could warn and then proceed to set the edge and face alpha channel).
>>>> Then we would drop the rgbFace argument entirely. Obviously this
>>>> would require hacking through a bunch of backend code to fix, but the
>>>> changes would be fairly straightforward and of the busy-work variety.
>>>> 
>> 
> One open question is whether set_alpha (even if deprecated) should set 
> or multiply the alpha of the fill and edge color. But I think I'm in 
> favor of creating "one way to do it", which would be to have alpha as 
> the fourth component of any color -- that option also scales well to 
> individual colors in a collection, in a way that any of the more global 
> options don't.
I agree. To the extent that we retain alpha= kwargs and set_alpha, it 
seems to me they should have the obvious meaning: "set_x" means *set*, 
not multiply; if you want to multiply, use "scale_alpha", or "fade", or 
something like that. These sorts of operations could be done naturally 
as ColorSpec methods.
> 
> It strikes me that if none of us find the time for this, this task would 
> be a good initial GSoC task... it's not enough work for an entire 
> summer by any means, but it's "busy work" that touches a lot of parts of 
> the code, and therefore a good introduction to the code base. The other 
> related task is to create a gc-like object for collections so that the 
> arguments to draw_collection don't have to change in every backend every 
> time a new feature is added.
> 
>> This sounds like a good idea. In the pdf backend, GraphicsContextPdf
>> already defines a _fillcolor attribute, and for example draw_path does
>>
>> def draw_path(self, gc, path, transform, rgbFace=None):
>> self.check_gc(gc, rgbFace)
>> # ...
>>
>> where check_gc just temporarily sets gc._fillcolor to the value of
>> rgbFace and issues the pdf commands to change the graphics state to
>> reflect gc. If rgbFace is absorbed into gc, at least the pdf backend
>> should be easy to change accordingly, and should become less complex in
>> the process. Currently the same alpha value (gc._alpha) is used for both
>> strokes and painting operations, but this too should be easy to change
>> if we decide to drop the _alpha attribute from GraphicsContext and use
>> the fourth component of the stroke and fill colors for alpha.
>>
>> By the way, the PDF imaging model has much richer support for
>> transparency than just specifying an alpha value for each operation; the
>> Transparency chapter takes up 64 pages in the PDF spec1. One thing that
>> I imagine somebody just might want to have support for in matplotlib are
>> transparency groups2, i.e., blending some objects together and then
>> blending the group with the background. But I wonder if that's possible
>> in Agg - I guess we will want to stay pretty close to the greatest
>> common denominator of Agg, SVG and PDF, and let people with special
>> needs use other software such as Illustrator to postprocess the files.
>>
>> 1 http://www.adobe.com/devnet/pdf/pdf_reference_archive.html
>> 2 http://itext.ugent.be/library/com/lowagie/examples/directcontent/colors/transparency.pdf
>>
>> 
>>> Maybe we need an MplColorSpec class. At present, functions and methods 
>>> typically accept colors and/or color arrays in a wide variety of forms. 
>>> This is good. My thought is that these should then be converted by 
>>> the accepting function or method to instances of the new class, and that 
>>> instances of the new class should be accepted as color inputs along with 
>>> all the old forms.
>>> 
>> replacing the current hack, neat
>> as it is, where a string representation of a decimal number means a
>> grayscale color, a string beginning with # means a hexadecimal color,
>> etc. The pyplot API should of course continue to work as it does now.
>>
>> 
> I really like Eric's suggestion here, as it fits in well with my desire 
> to verify arguments early and consistently. But I don't think we need 
> to throw out the convenient string forms of colors to achieve it. Those 
> are really handy, and fairly well known from HTML/CSS/SVG etc., and I 
> worry forcing the user to provide an instance of a particular class to 
> do something as common as setting a color would be annoying verbosity. 
> Of course, they should be free to do so if there's other maintenance 
> advantages as you suggested.
The way I envision backwards compatibility, above some level in the API, 
a color-like kwarg would be handled something like this:
def color_using_method(self, ..., carg=None,...)
 if carg is None:
 cspec = self.default_carg_cspec
 else:
 cspec = as_color_spec(carg)
 ...
def as_color_spec(arg):
 "like asarray..."
 if isinstance(arg, ColorSpec):
 #No duck-typing here, please.
 return arg
 else:
 return ColorSpec(arg)
The ColorSpec.__init__() would then have all our present magic for 
figuring out the various types of arguments, as well as explicit 
specifications based on kwargs as suggested by Jouni.
An API level (e.g. backends) could be specified below which only a 
ColorSpec is accepted.
Eric
> 
> Mike
> 
> 

Jouni K. Seppänen wrote:
> Eric Firing <ef...@ha...> writes:
> 
>> John Hunter wrote:
>> 
>>> One possibility would be to have a facecolor/edgecolor property on
>>> the gc itself, which would be rgba tuples. Since the gc is almost
>>> entirely internal, we can revamp it w/o affecting userland code,
>>> though it would be nice to support legacy methods (eg gc.set_alpha
>>> could warn and then proceed to set the edge and face alpha channel).
>>> Then we would drop the rgbFace argument entirely. Obviously this
>>> would require hacking through a bunch of backend code to fix, but the
>>> changes would be fairly straightforward and of the busy-work variety.
>>> 
>
> 
One open question is whether set_alpha (even if deprecated) should set 
or multiply the alpha of the fill and edge color. But I think I'm in 
favor of creating "one way to do it", which would be to have alpha as 
the fourth component of any color -- that option also scales well to 
individual colors in a collection, in a way that any of the more global 
options don't.
It strikes me that if none of us find the time for this, this task would 
be a good initial GSoC task... it's not enough work for an entire 
summer by any means, but it's "busy work" that touches a lot of parts of 
the code, and therefore a good introduction to the code base. The other 
related task is to create a gc-like object for collections so that the 
arguments to draw_collection don't have to change in every backend every 
time a new feature is added.
> This sounds like a good idea. In the pdf backend, GraphicsContextPdf
> already defines a _fillcolor attribute, and for example draw_path does
>
> def draw_path(self, gc, path, transform, rgbFace=None):
> self.check_gc(gc, rgbFace)
> # ...
>
> where check_gc just temporarily sets gc._fillcolor to the value of
> rgbFace and issues the pdf commands to change the graphics state to
> reflect gc. If rgbFace is absorbed into gc, at least the pdf backend
> should be easy to change accordingly, and should become less complex in
> the process. Currently the same alpha value (gc._alpha) is used for both
> strokes and painting operations, but this too should be easy to change
> if we decide to drop the _alpha attribute from GraphicsContext and use
> the fourth component of the stroke and fill colors for alpha.
>
> By the way, the PDF imaging model has much richer support for
> transparency than just specifying an alpha value for each operation; the
> Transparency chapter takes up 64 pages in the PDF spec1. One thing that
> I imagine somebody just might want to have support for in matplotlib are
> transparency groups2, i.e., blending some objects together and then
> blending the group with the background. But I wonder if that's possible
> in Agg - I guess we will want to stay pretty close to the greatest
> common denominator of Agg, SVG and PDF, and let people with special
> needs use other software such as Illustrator to postprocess the files.
>
> 1 http://www.adobe.com/devnet/pdf/pdf_reference_archive.html
> 2 http://itext.ugent.be/library/com/lowagie/examples/directcontent/colors/transparency.pdf
>
> 
>> Maybe we need an MplColorSpec class. At present, functions and methods 
>> typically accept colors and/or color arrays in a wide variety of forms. 
>> This is good. My thought is that these should then be converted by 
>> the accepting function or method to instances of the new class, and that 
>> instances of the new class should be accepted as color inputs along with 
>> all the old forms.
>> 
>
> replacing the current hack, neat
> as it is, where a string representation of a decimal number means a
> grayscale color, a string beginning with # means a hexadecimal color,
> etc. The pyplot API should of course continue to work as it does now.
>
> 
I really like Eric's suggestion here, as it fits in well with my desire 
to verify arguments early and consistently. But I don't think we need 
to throw out the convenient string forms of colors to achieve it. Those 
are really handy, and fairly well known from HTML/CSS/SVG etc., and I 
worry forcing the user to provide an instance of a particular class to 
do something as common as setting a color would be annoying verbosity. 
Of course, they should be free to do so if there's other maintenance 
advantages as you suggested.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing <ef...@ha...> writes:
> John Hunter wrote:
>> One possibility would be to have a facecolor/edgecolor property on
>> the gc itself, which would be rgba tuples. Since the gc is almost
>> entirely internal, we can revamp it w/o affecting userland code,
>> though it would be nice to support legacy methods (eg gc.set_alpha
>> could warn and then proceed to set the edge and face alpha channel).
>> Then we would drop the rgbFace argument entirely. Obviously this
>> would require hacking through a bunch of backend code to fix, but the
>> changes would be fairly straightforward and of the busy-work variety.
This sounds like a good idea. In the pdf backend, GraphicsContextPdf
already defines a _fillcolor attribute, and for example draw_path does
 def draw_path(self, gc, path, transform, rgbFace=None):
 self.check_gc(gc, rgbFace)
 # ...
where check_gc just temporarily sets gc._fillcolor to the value of
rgbFace and issues the pdf commands to change the graphics state to
reflect gc. If rgbFace is absorbed into gc, at least the pdf backend
should be easy to change accordingly, and should become less complex in
the process. Currently the same alpha value (gc._alpha) is used for both
strokes and painting operations, but this too should be easy to change
if we decide to drop the _alpha attribute from GraphicsContext and use
the fourth component of the stroke and fill colors for alpha.
By the way, the PDF imaging model has much richer support for
transparency than just specifying an alpha value for each operation; the
Transparency chapter takes up 64 pages in the PDF spec1. One thing that
I imagine somebody just might want to have support for in matplotlib are
transparency groups2, i.e., blending some objects together and then
blending the group with the background. But I wonder if that's possible
in Agg - I guess we will want to stay pretty close to the greatest
common denominator of Agg, SVG and PDF, and let people with special
needs use other software such as Illustrator to postprocess the files.
1 http://www.adobe.com/devnet/pdf/pdf_reference_archive.html
2 http://itext.ugent.be/library/com/lowagie/examples/directcontent/colors/transparency.pdf
> Maybe we need an MplColorSpec class. At present, functions and methods 
> typically accept colors and/or color arrays in a wide variety of forms. 
> This is good. My thought is that these should then be converted by 
> the accepting function or method to instances of the new class, and that 
> instances of the new class should be accepted as color inputs along with 
> all the old forms.
I haven't thought about this carefully, but I think it could help
improve the cohesion of the code.
Perhaps a more "object-oriented" way to deal with color specifications
would be to let ColorSpec objects be constructed by the user, and
require these objects to be used in the OO api: instead of
ax.bar(x, y, color='0.5', edgecolor='r')
require
ax.bar(x, y, color=ColorSpec('0.5'), edgecolor=ColorSpec('r'))
or perhaps even something like
ax.bar(x, y,
 color=ColorSpec(grayscale=0.5),
 edgecolor=ColorSpec(named='r'))
to avoid parsing strings in the API - replacing the current hack, neat
as it is, where a string representation of a decimal number means a
grayscale color, a string beginning with # means a hexadecimal color,
etc. The pyplot API should of course continue to work as it does now.
IMHO this would be more Pythonic (in the vein of "Explicit is better
than implicit" and "In the face of ambiguity, refuse the temptation to
guess"), although a departure from how matplotlib currently works. It
would encourage the users of the OO API to select their colors once and
put them in variables, so the example above would really read
facecolor = ColorSpec(grayscale=0.5)
edgecolor = ColorSpec(named='red')
# ...
ax.bar(x, y, color=facecolor, edgecolor=edgecolor)
which - as a part of a longer program - would likely be easier to
maintain than the first version of the example.
> I suspect that this refactoring might, without loss 
> of backwards compatibility, make it possible to considerably simplify, 
> clarify, and generalize the handling of colors (again, both single 
> values and arrays), and provide a less-confusing framework for setting 
> and overriding defaults. I think that as things are now, color spec 
> checking and/or conversion are often done repeatedly in a single 
> pipeline. With the class, all this would happen only the first time a 
> color spec is encountered.
>
> The class might include mapping, or the present color mapping might 
> yield an instance of the class; I have not thought about this aspect.
>
> Eric
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

>
> This was causing havoc in contourf; I don't see the logic of multiplying a
> previous alpha by a new one.
Consider a following example that you want to have different alpha for
edgecolor and face color (of course this does not work as of now),
Circle((1, 1), 0.5, ec=(1, 1, 1, 0.2), fc=(1, 0, 0, 1), alpha=1)
If alpha always overrides, it will override both alpha values of the
edge color and facecolor, and we can't have different alphas for edge
and face.
And, in this case, I think the alphas should be multiplied.
Similarly,
Circle((1, 1), 0.5, ec=(1, 1, 1, 0.2), fc=(1, 0, 0, 1), alpha=0.5)
I think it is natural to expect that the resulting alpha of ec to be 0.2*0.5.
For the case of contourf, the problem in my point of view is not that
the alpha is not overridden, but that contourf applies the same alpha
twice.
Whether set_alpha() method override or not would be an implementation
detail, but I guess the above cases at least make some sense.
-JJ

John Hunter wrote:
> 
> 
> On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee <lee...@gm... 
> <mailto:lee...@gm...>> wrote:
> 
> The example (e) in my previous script have a code and a text label
> mismatched.
> I'm attaching the corrected one.
> 
> I took a more look on how a patch is drawn.
> the draw() method of a patch calls draw_path method of the renderer,
> which seems to be responsible for both "fill", and "stroke". But there
> is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
> and does not have a alpha value.
> 
> renderer.draw_path(gc, tpath, affine, rgbFace)
> 
> Thus, it seems that is is not possible to have different alpha for
> "fill" and "stroke".
> One of the easiest solution would be call the draw_path twice, each
> for fill and stroke.
> 
> 
> I think we would pay a significant performance hit in some cases to make 
> the call twice. Perhaps this is a good time to rethink the draw_path 
> and gc signature, since as Eric notes these have evolved over time from 
> the early days when mpl didn't have alpha at all. One possibility would 
> be to have a facecolor/edgecolor property on the gc itself, which would 
> be rgba tuples. Since the gc is almost entirely internal, we can revamp 
> it w/o affecting userland code, though it would be nice to support 
> legacy methods (eg gc.set_alpha could warn and then proceed to set the 
> edge and face alpha channel). Then we would drop the rgbFace argument 
> entirely. Obviously this would require hacking through a bunch of 
> backend code to fix, but the changes would be fairly straightforward and 
> of the busy-work variety.
> 
> JDH
It may be nearly orthogonal to the lower-level changes you are 
suggesting, John, but before I completely forget about it I would like 
to toss out a very vague idea about reform at a higher level, with 
apologies that I have not thought it through:
Maybe we need an MplColorSpec class. At present, functions and methods 
typically accept colors and/or color arrays in a wide variety of forms. 
 This is good. My thought is that these should then be converted by 
the accepting function or method to instances of the new class, and that 
instances of the new class should be accepted as color inputs along with 
all the old forms. I suspect that this refactoring might, without loss 
of backwards compatibility, make it possible to considerably simplify, 
clarify, and generalize the handling of colors (again, both single 
values and arrays), and provide a less-confusing framework for setting 
and overriding defaults. I think that as things are now, color spec 
checking and/or conversion are often done repeatedly in a single 
pipeline. With the class, all this would happen only the first time a 
color spec is encountered.
The class might include mapping, or the present color mapping might 
yield an instance of the class; I have not thought about this aspect.
Eric

On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee <lee...@gm...> wrote:
> The example (e) in my previous script have a code and a text label
> mismatched.
> I'm attaching the corrected one.
>
> I took a more look on how a patch is drawn.
> the draw() method of a patch calls draw_path method of the renderer,
> which seems to be responsible for both "fill", and "stroke". But there
> is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
> and does not have a alpha value.
>
> renderer.draw_path(gc, tpath, affine, rgbFace)
>
> Thus, it seems that is is not possible to have different alpha for
> "fill" and "stroke".
> One of the easiest solution would be call the draw_path twice, each
> for fill and stroke.
I think we would pay a significant performance hit in some cases to make the
call twice. Perhaps this is a good time to rethink the draw_path and gc
signature, since as Eric notes these have evolved over time from the early
days when mpl didn't have alpha at all. One possibility would be to have a
facecolor/edgecolor property on the gc itself, which would be rgba tuples.
Since the gc is almost entirely internal, we can revamp it w/o affecting
userland code, though it would be nice to support legacy methods (eg
gc.set_alpha could warn and then proceed to set the edge and face alpha
channel). Then we would drop the rgbFace argument entirely. Obviously this
would require hacking through a bunch of backend code to fix, but the
changes would be fairly straightforward and of the busy-work variety.
JDH

Jae-Joon Lee wrote:
> 
> Thanks for the explanation.
> I personally think that the default behavior for setting alpha is
> better to be multiplying with the previous one, instead of overriding.
This was causing havoc in contourf; I don't see the logic of multiplying 
a previous alpha by a new one.
> We may introduce override keyword in set_alpha method to to force the
> override. I think it should be considered a bug If there are more than
> one alpha defaults involved. Just a thought.
Yes, it is a bug, but I don't think another kwarg in set_alpha will 
necessarily solve it.
Eric
> And, yes, dealing with the dpi is always confusing!
> 
> -JJ
> 
> 
> ------------------------------------------------------------------------
> 

The example (e) in my previous script have a code and a text label mismatched.
I'm attaching the corrected one.
I took a more look on how a patch is drawn.
the draw() method of a patch calls draw_path method of the renderer,
which seems to be responsible for both "fill", and "stroke". But there
is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b
and does not have a alpha value.
 renderer.draw_path(gc, tpath, affine, rgbFace)
Thus, it seems that is is not possible to have different alpha for
"fill" and "stroke".
One of the easiest solution would be call the draw_path twice, each
for fill and stroke.
>
> I can't look at this specifically now, but I suspect it is a side effect of
> the way that alpha support has evolved, resulting in a confusing mess. Some
> things are RGB, others are RGBA; alpha defaults get set in various places,
> and there is no clear way of keeping track of what is just a default and
> should be overridden, versus what has been set deliberately and should *not*
> be overridden. I dimly remember looking into it a few months ago, thinking
> that it could be cleaned up with some simple changes, but failing. I really
> wish we could make some sweeps through the mpl code base and systematically
> clean up some of these messes. I don't know how many there are, but
> certainly more than one. Dpi is another area of perennial confusion, for
> example.
>
> Eric
>
>
Thanks for the explanation.
I personally think that the default behavior for setting alpha is
better to be multiplying with the previous one, instead of overriding.
We may introduce override keyword in set_alpha method to to force the
override. I think it should be considered a bug If there are more than
one alpha defaults involved. Just a thought.
And, yes, dealing with the dpi is always confusing!
-JJ

Jae-Joon Lee wrote:
> Hi,
> 
> When drawing a patch, the alpha value of its edgeolor is ignored. The
> following command draw a circle whose edgecolor has alpha=1, instead
> of 0.1.
> 
> 
> gca().add_patch(Circle((0.5, 0.5), 0.3,
> ec=(1,0,0,0.1), fc="none"))
> 
> 
> Attached is a little test script and its output.
> It seems that the edgecolor always has an alpha value of the face color.
> I'm not sure if this behavior is intended, but I personally think this
> is a bug.
Jae-Joon,
I can't look at this specifically now, but I suspect it is a side effect 
of the way that alpha support has evolved, resulting in a confusing 
mess. Some things are RGB, others are RGBA; alpha defaults get set in 
various places, and there is no clear way of keeping track of what is 
just a default and should be overridden, versus what has been set 
deliberately and should *not* be overridden. I dimly remember looking 
into it a few months ago, thinking that it could be cleaned up with some 
simple changes, but failing. I really wish we could make some sweeps 
through the mpl code base and systematically clean up some of these 
messes. I don't know how many there are, but certainly more than one. 
Dpi is another area of perennial confusion, for example.
Eric

I'm definitely not smarter than you, but I had looked at backend_cairo 
more recently :) I've done the merge.
Cheers,
Mike
Ryan May wrote:
> Checked in on the branch. I'm seeing some merge conflicts on
> backend_cairo.py at the moment, so I'll let someone smarter than me merge to
> trunk. :)
>
> Good find.
>
> Ryan
>
> On Mon, Mar 23, 2009 at 1:01 PM, Sandro Tosi <mo...@de...> wrote:
>
> 
>> Hi all,
>> I found a really nice typo:
>>
>> 
>> $ svn diff
>> Index: doc/users/screenshots.rst
>> ===================================================================
>> --- doc/users/screenshots.rst (revision 7000)
>> +++ doc/users/screenshots.rst (working copy)
>> @@ -82,7 +82,7 @@
>> ==========
>>
>> The :func:`~matplotlib.pyplot.pie` command
>> -uses a matlab(TM) compatible syntax to produce py charts. Optional
>> +uses a matlab(TM) compatible syntax to produce pie charts. Optional
>> features include auto-labeling the percentage of area, exploding one
>> or more wedges out from the center of the pie, and a shadow effect.
>> Take a close look at the attached code that produced this figure; nine
>> <<<
>>
>> Indeed pronunciation is the same, but the result is quite funny :)
>>
>> Cheers,
>> --
>> Sandro Tosi (aka morph, morpheus, matrixhasu)
>> My website: http://matrixhasu.altervista.org/
>> Me at Debian: http://wiki.debian.org/SandroTosi
>>
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> 
>
>
>
> 
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Hi,
When drawing a patch, the alpha value of its edgeolor is ignored. The
following command draw a circle whose edgecolor has alpha=1, instead
of 0.1.
gca().add_patch(Circle((0.5, 0.5), 0.3,
 ec=(1,0,0,0.1), fc="none"))
Attached is a little test script and its output.
It seems that the edgecolor always has an alpha value of the face color.
I'm not sure if this behavior is intended, but I personally think this
is a bug.
Regards,
-JJ

Checked in on the branch. I'm seeing some merge conflicts on
backend_cairo.py at the moment, so I'll let someone smarter than me merge to
trunk. :)
Good find.
Ryan
On Mon, Mar 23, 2009 at 1:01 PM, Sandro Tosi <mo...@de...> wrote:
> Hi all,
> I found a really nice typo:
>
> >>>
> $ svn diff
> Index: doc/users/screenshots.rst
> ===================================================================
> --- doc/users/screenshots.rst (revision 7000)
> +++ doc/users/screenshots.rst (working copy)
> @@ -82,7 +82,7 @@
> ==========
>
> The :func:`~matplotlib.pyplot.pie` command
> -uses a matlab(TM) compatible syntax to produce py charts. Optional
> +uses a matlab(TM) compatible syntax to produce pie charts. Optional
> features include auto-labeling the percentage of area, exploding one
> or more wedges out from the center of the pie, and a shadow effect.
> Take a close look at the attached code that produced this figure; nine
> <<<
>
> Indeed pronunciation is the same, but the result is quite funny :)
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

Hi all,
I found a really nice typo:
>>>
$ svn diff
Index: doc/users/screenshots.rst
===================================================================
--- doc/users/screenshots.rst	(revision 7000)
+++ doc/users/screenshots.rst	(working copy)
@@ -82,7 +82,7 @@
 ==========
 The :func:`~matplotlib.pyplot.pie` command
-uses a matlab(TM) compatible syntax to produce py charts. Optional
+uses a matlab(TM) compatible syntax to produce pie charts. Optional
 features include auto-labeling the percentage of area, exploding one
 or more wedges out from the center of the pie, and a shadow effect.
 Take a close look at the attached code that produced this figure; nine
<<<
Indeed pronunciation is the same, but the result is quite funny :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Jae-Joon,
On Sun, Mar 22, 2009 at 8:55 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi Eric,
>
> Have you find a solution for your problem?
> I recently encountered a similar problem.
> In my case, the images (I'm rasterizing the pcolormesh) are in wrong
> size if the output dpi is other than 72.
> And I guess this is related with the changes Jouni made in revision 6730.
>
> So, can you see if you have a correct output with dpi=72?
> If that's the case, can you try the attached patch and see if it
> solves your problem (should work with dpi other than 72).
I hadn't found a solution (other than rendering to svg), so thanks for
waking up this thread. I can confirm that I get the correct output
when I set dpi=72.
> I don't quite like my solution but it seems to work.
> It passes over the figure instance when initializing the
> MixedRenderer, and let the renderer change the dpi of the figure when
> changing the backend.
> I hope some other developer who better understands the dpi thing take
> a look and come up with a better solution.
I'll try to take a look at this later this afternoon. I agree that
someone with more knowledge should take a look. The SVG backend seems
to just ignore the dpi setting and forces 72 dpi across the board,
which is why I was able to use it as a workaround.
Thanks,
Eric
>
> Regards,
>
> -JJ
>
>
> On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eri...@gm...> wrote:
>> I just updated to the latest svn, and unveiled a bug that's evident
>> when using mixed-mode rendering in the PDF backend. I'm suspect I'm
>> the only one running my patch that enables set_rasterized on a
>> per-artist basis, so I'm the only one that's seeing it. :) Artists
>> that are left in vector mode are plotted correctly, while artists that
>> are rasterized are squished down toward the lower left corner of the
>> axes.
>>
>> Looking at the svn log, I suspect it's the changes to the path
>> simplification code (r6847) doing something funky at the transforms
>> level. Is that the right place to start looking? Any tips on how to
>> track this down?
>>
>> Thanks,
>> Eric
>>
>>
>> Sample code to reproduce the problem:
>>
>> import numpy
>> from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
>> basecolors = get_cmap('gist_yarg')
>> colormap, normer = basecolors, None #LogNorm()
>> x = y = c = numpy.arange(10) +1
>> dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
>> cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
>> dummy.set_rasterized(True)
>> dummy.figure.savefig('raster_test.pdf')
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a 600ドル discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

Perhaps a merge failed on lib/matplotlib/mathtext.py? If you know you 
don't have any local changes to that file that you need, you can just 
remove it and "svn up" again. I can't see a reason why this is a 
repository-side problem... no properties have changed on that file for a 
long time.
Mike
Nils Wagner wrote:
> Hi all,
>
> I cannot install matplotlib from recent svn.
>
> python setup.py install --prefix=$HOME/local
> ============================================================================
> BUILDING MATPLOTLIB
> matplotlib: 0.98.6svn
> python: 2.5.1 (r251:54863, Dec 21 2007, 
> 09:21:07) [GCC
> 3.4.6 20060404 (Red Hat 3.4.6-3)]
> platform: linux2
>
> REQUIRED DEPENDENCIES
> numpy: 1.4.0.dev6708
> freetype2: 9.7.3
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: 1.2.7
> Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
> wxPython: 2.8.9.1
> * WxAgg extension not required 
> for wxPython >= 2.8
> Gtk+: no
> * Building for Gtk+ requires 
> pygtk; you must be able
> * to "import gtk" in your 
> build/install environment
> Mac OS X native: no
> Qt: no
> Qt4: no
> Cairo: no
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
> datetime: present, version unknown
> dateutil: matplotlib will provide
> pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
> dvipng: no
> ghostscript: 7.07
> latex: 3.14159
> pdftops: 3.00
>
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> pymods ['pylab']
> packages ['matplotlib', 'matplotlib.backends', 
> 'matplotlib.projections', 'mpl_toolkits', 
> 'matplotlib.sphinxext', 'matplotlib.numerix', 
> 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 
> 'matplotlib.numerix.linear_algebra', 
> 'matplotlib.numerix.random_array', 
> 'matplotlib.numerix.fft', 'matplotlib.delaunay', 
> 'dateutil', 'dateutil/zoneinfo']
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-x86_64-2.5
> copying lib/pylab.py -> build/lib.linux-x86_64-2.5
> creating build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/hatch.py -> 
> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/widgets.py -> 
> build/lib.linux-x86_64-2.5/matplotlib
> error: can't copy 'lib/matplotlib/mathtext.py': doesn't 
> exist or not a regular file
> 
> Nils
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> 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

Hi all,
I cannot install matplotlib from recent svn.
python setup.py install --prefix=$HOME/local
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.6svn
 python: 2.5.1 (r251:54863, Dec 21 2007, 
09:21:07) [GCC
 3.4.6 20060404 (Red Hat 3.4.6-3)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.4.0.dev6708
 freetype2: 9.7.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.7
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.9.1
 * WxAgg extension not required 
for wxPython >= 2.8
 Gtk+: no
 * Building for Gtk+ requires 
pygtk; you must be able
 * to "import gtk" in your 
build/install environment
 Mac OS X native: no
 Qt: no
 Qt4: no
 Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: matplotlib will provide
 pytz: 2008c
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: 7.07
 latex: 3.14159
 pdftops: 3.00
[Edit setup.cfg to suppress the above messages]
============================================================================
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends', 
'matplotlib.projections', 'mpl_toolkits', 
'matplotlib.sphinxext', 'matplotlib.numerix', 
'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 
'matplotlib.numerix.linear_algebra', 
'matplotlib.numerix.random_array', 
'matplotlib.numerix.fft', 'matplotlib.delaunay', 
'dateutil', 'dateutil/zoneinfo']
running install
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.5
copying lib/pylab.py -> build/lib.linux-x86_64-2.5
creating build/lib.linux-x86_64-2.5/matplotlib
copying lib/matplotlib/hatch.py -> 
build/lib.linux-x86_64-2.5/matplotlib
copying lib/matplotlib/widgets.py -> 
build/lib.linux-x86_64-2.5/matplotlib
error: can't copy 'lib/matplotlib/mathtext.py': doesn't 
exist or not a regular file
 
Nils

Hi Eric,
Have you find a solution for your problem?
I recently encountered a similar problem.
In my case, the images (I'm rasterizing the pcolormesh) are in wrong
size if the output dpi is other than 72.
And I guess this is related with the changes Jouni made in revision 6730.
So, can you see if you have a correct output with dpi=72?
If that's the case, can you try the attached patch and see if it
solves your problem (should work with dpi other than 72).
I don't quite like my solution but it seems to work.
It passes over the figure instance when initializing the
MixedRenderer, and let the renderer change the dpi of the figure when
changing the backend.
I hope some other developer who better understands the dpi thing take
a look and come up with a better solution.
Regards,
-JJ
On Thu, Feb 19, 2009 at 4:01 PM, Eric Bruning <eri...@gm...> wrote:
> I just updated to the latest svn, and unveiled a bug that's evident
> when using mixed-mode rendering in the PDF backend. I'm suspect I'm
> the only one running my patch that enables set_rasterized on a
> per-artist basis, so I'm the only one that's seeing it. :) Artists
> that are left in vector mode are plotted correctly, while artists that
> are rasterized are squished down toward the lower left corner of the
> axes.
>
> Looking at the svn log, I suspect it's the changes to the path
> simplification code (r6847) doing something funky at the transforms
> level. Is that the right place to start looking? Any tips on how to
> track this down?
>
> Thanks,
> Eric
>
>
> Sample code to reproduce the problem:
>
> import numpy
> from matplotlib.pyplot import subplot, get_cmap, scatter, colorbar, show
> basecolors = get_cmap('gist_yarg')
> colormap, normer = basecolors, None #LogNorm()
> x = y = c = numpy.arange(10) +1
> dummy = scatter(x,y,c=c,cmap=colormap)#, norm=normer)
> cbar = colorbar(dummy)#, spacing='proportional',ticks=isolevels.levels)
> dummy.set_rasterized(True)
> dummy.figure.savefig('raster_test.pdf')
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Sherif Ahmed wrote:
> Hi Eric,
> 
> Thanks agaon. Now it works after updating to matplotlib 98.5.
> 
> Well I also attach the code. I find it good if we can publish it to other
> interested users. May be some one needs it or likes to upgrade it. I made
> already the basic work. How does this work? Should I distribute it via the
> list here or somewhere else?
> 
> I am not expert in this stuff :)
> 
> Nice wishes,
> Sherif
Thank you.
Let's see if someone wants to adapt it for direct inclusion in mpl, or 
as an example. I'm not going to volunteer, since it is far from my area 
of expertise, and I am short of time anyway.
Eric

Hi Eric,
Thanks agaon. Now it works after updating to matplotlib 98.5.
Well I also attach the code. I find it good if we can publish it to other
interested users. May be some one needs it or likes to upgrade it. I made
already the basic work. How does this work? Should I distribute it via the
list here or somewhere else?
I am not expert in this stuff :)
Nice wishes,
Sherif
-----Original Message-----
From: Eric Firing [mailto:ef...@ha...] 
Sent: Saturday, March 21, 2009 7:13 PM
To: Sherif Ahmed
Cc: 'Michael Droettboom'; mat...@li...
Subject: Re: [matplotlib-devel] Polar Plot
Sherif Ahmed wrote:
> Hello Eric,
> 
> I am afraid this does not work. I get error saying that :
> AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
It looks like support for the resolution kwarg was added late in 
January, so you need either a more recent version, or an older version. 
 Unfortunately, it also looks like the latest release was before this 
change.
Maybe it is time for another release, either 0.98.5 maintenance or 
trunk. Or both. Releases are not my area, though.
Eric
> 
> The full error text is:
> -----------------------------------------
> Traceback (most recent call last):
> File "D:\EmGine
>
Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 287, in <module>
> PlotSmith.plot_dummy()
> File "D:\EmGine
>
Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 241, in plot_dummy
> self.plot_data(data1.real, data1.imag,freq1,'my first data')
> File "D:\EmGine
>
Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 144, in plot_data
> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8],
projection='polar',
> resolution = 1, aspect='equal')
> File
>
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\figure.py", line 615, in add_axes
> a = projection_factory(projection, self, rect, **kwargs)
> File
>
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\projections\__init__.py", line 44, in projection_factory
> return get_projection_class(projection)(figure, rect, **kwargs)
> File
>
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\projections\polar.py", line 171, in __init__
> Axes.__init__(self, *args, **kwargs)
> File
>
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\axes.py", line 537, in __init__
> if len(kwargs): martist.setp(self, **kwargs)
> File
>
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\artist.py", line 894, in setp
> func = getattr(o,funcName)
> AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
> 
> 
> -----------------------------------------
> 
> Do you know what is the reason behind this?
> 
> Thanks,
> Sherif
> 
> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...] 
> Sent: Thursday, March 19, 2009 11:39 PM
> To: Sherif Ahmed
> Cc: 'Michael Droettboom'; mat...@li...
> Subject: Re: [matplotlib-devel] Polar Plot
> 
> Sherif Ahmed wrote:
>> Hello Mike,
>>
>> Thanks for your advice. I think this is exactly what I need. I am not
sure
>> how to use this option, might you help me?
>>
>> I use simply the following lines in my code:
>>
>> self.figure.clf()
>> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
> resolution=1,
>> aspect='equal')
>>
>> and later:
>> self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
>>
>> Where should I change the resolution feature? With each plot or with
> figure
>> object?
> 
> Put the resolution kwarg in the call to the add_axes method. The way 
> the line is drawn between points--whether as a straight line on the plot 
> or by interpolating in the data coordinates--is controlled on a per-axes 
> basis by this kwarg when the axes are created.
> 
> Eric
> 

Sherif Ahmed wrote:
> Hello Eric,
> 
> I am afraid this does not work. I get error saying that :
> AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
It looks like support for the resolution kwarg was added late in 
January, so you need either a more recent version, or an older version. 
 Unfortunately, it also looks like the latest release was before this 
change.
Maybe it is time for another release, either 0.98.5 maintenance or 
trunk. Or both. Releases are not my area, though.
Eric
> 
> The full error text is:
> -----------------------------------------
> Traceback (most recent call last):
> File "D:\EmGine
> Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 287, in <module>
> PlotSmith.plot_dummy()
> File "D:\EmGine
> Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 241, in plot_dummy
> self.plot_data(data1.real, data1.imag,freq1,'my first data')
> File "D:\EmGine
> Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
> line 144, in plot_data
> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
> resolution = 1, aspect='equal')
> File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\figure.py", line 615, in add_axes
> a = projection_factory(projection, self, rect, **kwargs)
> File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\projections\__init__.py", line 44, in projection_factory
> return get_projection_class(projection)(figure, rect, **kwargs)
> File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\projections\polar.py", line 171, in __init__
> Axes.__init__(self, *args, **kwargs)
> File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\axes.py", line 537, in __init__
> if len(kwargs): martist.setp(self, **kwargs)
> File
> "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
> tlib\artist.py", line 894, in setp
> func = getattr(o,funcName)
> AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
> 
> 
> -----------------------------------------
> 
> Do you know what is the reason behind this?
> 
> Thanks,
> Sherif
> 
> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...] 
> Sent: Thursday, March 19, 2009 11:39 PM
> To: Sherif Ahmed
> Cc: 'Michael Droettboom'; mat...@li...
> Subject: Re: [matplotlib-devel] Polar Plot
> 
> Sherif Ahmed wrote:
>> Hello Mike,
>>
>> Thanks for your advice. I think this is exactly what I need. I am not sure
>> how to use this option, might you help me?
>>
>> I use simply the following lines in my code:
>>
>> self.figure.clf()
>> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
> resolution=1,
>> aspect='equal')
>>
>> and later:
>> self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
>>
>> Where should I change the resolution feature? With each plot or with
> figure
>> object?
> 
> Put the resolution kwarg in the call to the add_axes method. The way 
> the line is drawn between points--whether as a straight line on the plot 
> or by interpolating in the data coordinates--is controlled on a per-axes 
> basis by this kwarg when the axes are created.
> 
> Eric
> 

Hello Eric,
I am afraid this does not work. I get error saying that :
AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
The full error text is:
-----------------------------------------
Traceback (most recent call last):
 File "D:\EmGine
Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
line 287, in <module>
 PlotSmith.plot_dummy()
 File "D:\EmGine
Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
line 241, in plot_dummy
 self.plot_data(data1.real, data1.imag,freq1,'my first data')
 File "D:\EmGine
Project\emGine_GUI_0_7_5__11022009\emGine_GUI_0_7_5\emGineGUI\PlotSmith.py",
line 144, in plot_data
 self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
resolution = 1, aspect='equal')
 File
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
tlib\figure.py", line 615, in add_axes
 a = projection_factory(projection, self, rect, **kwargs)
 File
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
tlib\projections\__init__.py", line 44, in projection_factory
 return get_projection_class(projection)(figure, rect, **kwargs)
 File
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
tlib\projections\polar.py", line 171, in __init__
 Axes.__init__(self, *args, **kwargs)
 File
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
tlib\axes.py", line 537, in __init__
 if len(kwargs): martist.setp(self, **kwargs)
 File
"c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo
tlib\artist.py", line 894, in setp
 func = getattr(o,funcName)
AttributeError: 'PolarAxes' object has no attribute 'set_resolution'
-----------------------------------------
Do you know what is the reason behind this?
Thanks,
Sherif
-----Original Message-----
From: Eric Firing [mailto:ef...@ha...] 
Sent: Thursday, March 19, 2009 11:39 PM
To: Sherif Ahmed
Cc: 'Michael Droettboom'; mat...@li...
Subject: Re: [matplotlib-devel] Polar Plot
Sherif Ahmed wrote:
> Hello Mike,
>
> Thanks for your advice. I think this is exactly what I need. I am not sure
> how to use this option, might you help me?
> 
> I use simply the following lines in my code:
> 
> self.figure.clf()
> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
 resolution=1,
> aspect='equal')
> 
> and later:
> self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
> 
> Where should I change the resolution feature? With each plot or with
figure
> object?
Put the resolution kwarg in the call to the add_axes method. The way 
the line is drawn between points--whether as a straight line on the plot 
or by interpolating in the data coordinates--is controlled on a per-axes 
basis by this kwarg when the axes are created.
Eric

Sherif Ahmed wrote:
> Hello Mike,
> 
> Thanks for your advice. I think this is exactly what I need. I am not sure
> how to use this option, might you help me?
> 
> I use simply the following lines in my code:
> 
> self.figure.clf()
> self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
 resolution=1,
> aspect='equal')
> 
> and later:
> self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
> 
> Where should I change the resolution feature? With each plot or with figure
> object?
Put the resolution kwarg in the call to the add_axes method. The way 
the line is drawn between points--whether as a straight line on the plot 
or by interpolating in the data coordinates--is controlled on a per-axes 
basis by this kwarg when the axes are created.
Eric

Hello Mike,
Thanks for your advice. I think this is exactly what I need. I am not sure
how to use this option, might you help me?
I use simply the following lines in my code:
self.figure.clf()
self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='polar',
aspect='equal')
and later:
self.axes.plot(angle(data),abs(data),label=title,linewidth = 2,zorder=10)
Where should I change the resolution feature? With each plot or with figure
object?
The code is currently open source and available via emGine software
(http://www.petr-lorenz.com/emgine/index.php?option=com_content&view=article
&id=46&Itemid=56)
I am also willing to split smithchart plot as part of matplotlib, this would
be great I think.
Best regards,
Sherif
-----Original Message-----
From: Michael Droettboom [mailto:md...@st...] 
Sent: Thursday, March 19, 2009 1:01 PM
To: Sherif Ahmed
Cc: mat...@li...
Subject: Re: [matplotlib-devel] Polar Plot
Sherif Ahmed wrote:
>
> Hello all,
>
> I am using matplotlib in order to generate a scientific drawing called 
> “Smith Chart”. It consists of many shifted circles drawn in polar 
> plot. This chart is widely used in electrical engineering field.
>
> I am facing a problem now with the new version of matplotlib. After 
> trying around I figured out that the plot function does not connect 
> the given points in straight lines however by a circle or a circle 
> sector. This causes a very wrong drawing and producing parasitic, 
> false, circles when the points are to cross the theta=180° line.
>
You can turn off this feature by passing "resolution=1" to the polar() 
method. This is the default in SVN versions of matplotlib, and will be 
in the next releases.
You've clearly done a lot of work on the Smith chart plotting already... 
It would be great to package that code into something for general use 
and include in the matplotlib core.
Mike
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>
----------------------------------------------------------------------------
--
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

I don't know the prehistory of GraphicsContext in matplotlib, but IMHO, 
the issue here is that the matplotlib GraphicsContext class is just 
badly named. All it is is a class to store a bunch of graphics 
properties to be passed along to draw_path etc. to describe what is to 
be drawn. It doesn't infer any persistent state or stack-like activity, 
which is why the name "Context" is probably inappropriate.
The problem in the Cairo backend is that the setting of the Cairo 
clipping region was happening in the matplotlib 
GraphicsContext.set_clip_rectangle method -- when all it should have 
done was to store it there and use it later within draw_path. This is 
what all other backends do, even though many of them (PS, PDF for 
instance), have the same save/restore semantics as Cairo and OS-X.
While it may be easy to add stack semantics to backends that don't 
support them, it is nontrivial to rewrite large parts of the Artists 
layer to use stack semantics, which implies being more careful about 
nesting, and particularly about popping contexts away, which it 
currently doesn't do. At present, a new "GraphicsContext" is 
constructed from scratch for each element that is drawn, and they don't 
imply any sort of heirarchy. On some level, that might be considered 
sloppy, but on another level it's an example of "flat is better than 
nested" (see the Zen of Python). It may sometime seems cleaner/more 
efficient to have the heirarchy of objects reflected in a heirarchy of 
graphics contexts. This is often true of transformations, but the 
advantages break down when you consider non-linear transformations 
(since none of the backends support non-linear transformations). And I 
don't see any significant advantage to inheriting things like stroke and 
fill from the parent given the current architecture of matplotlib. So 
it would be a lot of work in the Artist layer for little gain there.
It's unfortunate that this clash of terminology lead to a 
misunderstanding about how to write a backend. That should definitely 
be documented, and perhaps the "GraphicsContextBase" class name should 
be changed. But I don't know that rewriting the Artists to use stack 
semantics is the best way out, or even desirable given infinite 
resources. I think the solution is to instead fix the backends to not 
rely on stack semantics and set the backend's context around each 
drawing operation, as the Agg, Ps, and Pdf backends do.
Michiel de Hoon wrote:
> Recently I realized that there is a potential problem in both the Cairo and the Mac OS X backend related to how graphics contexts are handled. I tried your example and found that the Mac OS X backend shows the same incorrect result as the Cairo backend, which makes me suspect that this bug is related to the graphics context problem.
>
> The problem is that matplotlib backends have a new_gc method, which is supposed to return a new graphics context. Unfortunately, Cairo and Quartz (used in the Mac OS X backend) do not have the capability to create a graphics context on the fly. Instead, Cairo and Quartz can save and restore graphics states on a stack. Both backends use a mock new_gc method by saving the graphics context on the stack, and trying to find that graphics context back in the stack when needed. This works most of the time, but it is fragile.
>
> To give you another example where this breaks, 
>
> text(0, 0, 'my text', bbox=dict(facecolor='grey'),color='red')
>
> shows the text in red with the tkagg backend, but in black with the Cairo and Mac OS X backends. The error occurs in the draw method in text.py:
>
> gc = renderer.new_gc()
> gc.set_foreground(self._color)
> gc.set_alpha(self._alpha)
> gc.set_url(self._url)
> if self.get_clip_on():
> gc.set_clip_rectangle(self.clipbox)
>
> if self._bbox:
> bbox_artist(self, renderer, self._bbox)
>
> Inside bbox_artist, new_gc() is called again, which is OK on backends with a "true" new_gc, but will lose the information stored in the existing graphics context in backends with a mock new_gc.
> 
This specific bug could perhaps be addressed by moving the bbox_artist 
call above the renderer.new_gc() call here -- but caring about this sort 
of order dependence worries me.
> My guess is that in the bug you're seeing, the clipping path in one graphics context is overwritten by the clipping path in another graphics context. Maybe I'm wrong, but I hope that this gives you some idea of where to look.
> 
It was actually that the clipping path was never cleared, and so we were 
getting the intersection of two clipping paths. This is the result of 
the artist layer not doing anything to pop (restore) contexts.
> If this is indeed the problem, maybe it's a good idea for matplotlib to save and restore graphics contexts instead of using new_gc? It's easy to implement a save/restore mechanism in backends with a new_gc capability; the reverse is inherently fragile.
> 
I agree. But that means changing the semantics of the entire program to 
fix a couple of differently-written backend interfaces. I'd rather just 
fix the backends.
All this is just me 2 cents. I certainly welcome contrary feedback if 
there's a real advantage to relying on stack-based semantics everywhere 
to justify the work required.
Cheers,
Mike
> --Michiel
>
>
> --- On Thu, 3/19/09, Nathaniel Smith <nj...@po...> wrote:
>
> 
>> From: Nathaniel Smith <nj...@po...>
>> Subject: [matplotlib-devel] Rendering (clipping?) bug with Cairo backend
>> To: mat...@li...
>> Date: Thursday, March 19, 2009, 7:13 AM
>> I ran into a very curious bug tonight, where if I
>> -- had multiple axes in a figure
>> -- and they had axison=False
>> -- and there was a patch or line in each axes
>> -- and there was an image in each axes
>> Then the image is not rendered (or, after some fiddling
>> with how the
>> subplots overlap, is sometimes partially rendered).
>>
>> It took a few hours to isolate :-(.
>>
>> I tried the GTKCairo and GTKAgg backends; the Cairo backend
>> shows the
>> bug, while the Agg backend renders it correctly.
>>
>> This is with matplotlib 0.98.5.2, running on Linux x86-64.
>>
>> Minimal code to reproduce the bug is:
>> --------
>> from matplotlib import patches, pyplot
>> def bug():
>> f = pyplot.figure()
>> a1 = f.add_axes([0, 0, 0.4, 0.9])
>> a2 = f.add_axes([0.5, 0, 0.4, 0.9])
>> a3 = f.add_axes([0.2, 0.2, 0.4, 0.9])
>> for a in [a1, a2, a3]:
>> # This shows up in axis 1, but not axis 2, and only
>> partially in axis 3:
>> a.imshow(np.arange(100).reshape(10, 10),
>> extent=(-1, 1, 1, -1))
>> # If you comment out either of these lines, then it
>> works properly:
>> a.axison = False
>> a.plot([0, 0], [1, 1])
>> pyplot.draw()
>> -------
>>
>> Renders with agg and cairo are attached for comparison.
>> Note that in
>> the cairo rendering, axes 1 is drawn correctly, axes 2 is
>> not drawn at
>> all, and the only part of axes 3 that is drawn is that part
>> that
>> overlaps axes 2.
>>
>> -- Nathaniel
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex
>> Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform
>> capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the
>> Eclipse(TM)based development
>> software that enables intelligent coding and step-through
>> debugging.
>> Download the free 60 day trial.
>> http://p.sf.net/sfu/www-adobe-com_______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>
> 
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> 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

Recently I realized that there is a potential problem in both the Cairo and the Mac OS X backend related to how graphics contexts are handled. I tried your example and found that the Mac OS X backend shows the same incorrect result as the Cairo backend, which makes me suspect that this bug is related to the graphics context problem.
The problem is that matplotlib backends have a new_gc method, which is supposed to return a new graphics context. Unfortunately, Cairo and Quartz (used in the Mac OS X backend) do not have the capability to create a graphics context on the fly. Instead, Cairo and Quartz can save and restore graphics states on a stack. Both backends use a mock new_gc method by saving the graphics context on the stack, and trying to find that graphics context back in the stack when needed. This works most of the time, but it is fragile.
To give you another example where this breaks, 
text(0, 0, 'my text', bbox=dict(facecolor='grey'),color='red')
shows the text in red with the tkagg backend, but in black with the Cairo and Mac OS X backends. The error occurs in the draw method in text.py:
 gc = renderer.new_gc()
 gc.set_foreground(self._color)
 gc.set_alpha(self._alpha)
 gc.set_url(self._url)
 if self.get_clip_on():
 gc.set_clip_rectangle(self.clipbox)
 if self._bbox:
 bbox_artist(self, renderer, self._bbox)
Inside bbox_artist, new_gc() is called again, which is OK on backends with a "true" new_gc, but will lose the information stored in the existing graphics context in backends with a mock new_gc.
My guess is that in the bug you're seeing, the clipping path in one graphics context is overwritten by the clipping path in another graphics context. Maybe I'm wrong, but I hope that this gives you some idea of where to look.
If this is indeed the problem, maybe it's a good idea for matplotlib to save and restore graphics contexts instead of using new_gc? It's easy to implement a save/restore mechanism in backends with a new_gc capability; the reverse is inherently fragile.
--Michiel
--- On Thu, 3/19/09, Nathaniel Smith <nj...@po...> wrote:
> From: Nathaniel Smith <nj...@po...>
> Subject: [matplotlib-devel] Rendering (clipping?) bug with Cairo backend
> To: mat...@li...
> Date: Thursday, March 19, 2009, 7:13 AM
> I ran into a very curious bug tonight, where if I
> -- had multiple axes in a figure
> -- and they had axison=False
> -- and there was a patch or line in each axes
> -- and there was an image in each axes
> Then the image is not rendered (or, after some fiddling
> with how the
> subplots overlap, is sometimes partially rendered).
> 
> It took a few hours to isolate :-(.
> 
> I tried the GTKCairo and GTKAgg backends; the Cairo backend
> shows the
> bug, while the Agg backend renders it correctly.
> 
> This is with matplotlib 0.98.5.2, running on Linux x86-64.
> 
> Minimal code to reproduce the bug is:
> --------
> from matplotlib import patches, pyplot
> def bug():
> f = pyplot.figure()
> a1 = f.add_axes([0, 0, 0.4, 0.9])
> a2 = f.add_axes([0.5, 0, 0.4, 0.9])
> a3 = f.add_axes([0.2, 0.2, 0.4, 0.9])
> for a in [a1, a2, a3]:
> # This shows up in axis 1, but not axis 2, and only
> partially in axis 3:
> a.imshow(np.arange(100).reshape(10, 10),
> extent=(-1, 1, 1, -1))
> # If you comment out either of these lines, then it
> works properly:
> a.axison = False
> a.plot([0, 0], [1, 1])
> pyplot.draw()
> -------
> 
> Renders with agg and cairo are attached for comparison.
> Note that in
> the cairo rendering, axes 1 is drawn correctly, axes 2 is
> not drawn at
> all, and the only part of axes 3 that is drawn is that part
> that
> overlaps axes 2.
> 
> -- Nathaniel
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex
> Builder(TM) are
> powering Web 2.0 with engaging, cross-platform
> capabilities. Quickly and
> easily build your RIAs with Flex Builder, the
> Eclipse(TM)based development
> software that enables intelligent coding and step-through
> debugging.
> Download the free 60 day trial.
> http://p.sf.net/sfu/www-adobe-com_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel