matplotlib-devel Mailing List for matplotlib

On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hello,
>
> I'm working on the fancy annotation thing I mentioned the other day,
> and I want to have some feedback and advice.
>
> As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
> the annotation will be consist of a fancy box + fancy arrow. And my
> current plan is to put the fancy arrow things as an arrow patch class
> in the patches.py. The new class would be very similar to the
> FancyBboxPatch class. It will take three control points of quadratic
> bezier path as an input, and will draw an arrow around this path (an
> example is attached). For example
>
> mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
> arrowstyle="simple",
> ec="blue!50!white",
> fc="blue!20!white")
>
> But, patches.py already has three arrow classes.
>
> * Arrow(x, y, dx, dy)
> * FancyArrow(x, y, dx, dy)
> * YAArrow(figure, xytip, xybase)
>
> And I'm a bit hesitating in adding yet another arrow class. One way
> I'm considering is to merge my arrow class with the currently existing
> FancyArrow class (or other). But their interface is a bit different
> and I'm afraid that it may confuse users. So, how others think? Would
> it better to simply have a seperate arrow class or to have it merged
> into one of the existing arrow classes?
Well merging is obviously better. I wrote YAArrow to support
plain-vanilla annotations. AFAIK, they are used nowhere else, so as
long as we could come up with one arrow class that works with
plain-vanilla and fancy annotations, that would be good. But it may
be easier said than done. These annotation arrows are really helper
classes that are instantiated by higher level functions (eg users most
likely won't be creating them themselves) and since they all have the
basic patch interface, I don't think having a proliferation of them is
the worst thing in the world, though the ideal is to have as few
classes as possible that serve as many cases as possible.
> The other thing is, as I said, the annotation is consist of a fancy
> box and fancy arrow, which means we need to draw a union of two closed
> bezier path. I hoped that the agg package have those kind
> functionality but I couldn't find one (if there is, please let me
> know). So, I think there are two options.
I believe you are looking for the scanline boolean algebra -- search
the antigrain demo page
 http://www.antigrain.com/demo/index.html
for scanline_boolean.cpp. Of course, we would need to support the
other major backends too....
> * Forget the union operation and fake it by modifying the order of
> "stroke" and "fill", i.e, stroke the paths of the box and arrow first
> then fill each path later (with a same color). The above figure uses
> this approach. It would not work if your want a transparent fill
> color.
>
> * Or, use an external library.
> 2geom(http://lib2geom.sourceforge.net/) seems promising, and I
> currently have a simple wrapper based on it which does the job (2geom
> does provide a python interface but not all of its funtionality are
> wrapped yet. So I needed make a few changes).
This appears to be LGPL, so we will not be using it in the main distro.

Hello,
I'm working on the fancy annotation thing I mentioned the other day,
and I want to have some feedback and advice.
As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
the annotation will be consist of a fancy box + fancy arrow. And my
current plan is to put the fancy arrow things as an arrow patch class
in the patches.py. The new class would be very similar to the
FancyBboxPatch class. It will take three control points of quadratic
bezier path as an input, and will draw an arrow around this path (an
example is attached). For example
 mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
 arrowstyle="simple",
 ec="blue!50!white",
 fc="blue!20!white")
But, patches.py already has three arrow classes.
 * Arrow(x, y, dx, dy)
 * FancyArrow(x, y, dx, dy)
 * YAArrow(figure, xytip, xybase)
And I'm a bit hesitating in adding yet another arrow class. One way
I'm considering is to merge my arrow class with the currently existing
FancyArrow class (or other). But their interface is a bit different
and I'm afraid that it may confuse users. So, how others think? Would
it better to simply have a seperate arrow class or to have it merged
into one of the existing arrow classes?
The other thing is, as I said, the annotation is consist of a fancy
box and fancy arrow, which means we need to draw a union of two closed
bezier path. I hoped that the agg package have those kind
functionality but I couldn't find one (if there is, please let me
know). So, I think there are two options.
 * Forget the union operation and fake it by modifying the order of
"stroke" and "fill", i.e, stroke the paths of the box and arrow first
then fill each path later (with a same color). The above figure uses
this approach. It would not work if your want a transparent fill
color.
 * Or, use an external library.
2geom(http://lib2geom.sourceforge.net/) seems promising, and I
currently have a simple wrapper based on it which does the job (2geom
does provide a python interface but not all of its funtionality are
wrapped yet. So I needed make a few changes).
My inclination is to go with the first option. But since this seems a
bit hackish way to do it, I want to know how others think.
Any comment, suggestion, or advice would be appreciated.
-JJ

On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote:
> Attached is a diff against revision 6115 that contains a patch to
> improve the behavior of the legend function when showing legends for
Erik,
I haven't had a chance to get to this yet. Could you please also post
it on the sf patch tracker so it doesn't get dropped, and ping us with
a reminder in a few days if nothing has happened....
JDH

Hi.
I don't think my last message (sent a few days ago) made it to the
mailing list. I'm reposting it again.
On Fri, Sep 19, 2008 at 4:50 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I just uploaded a slightly modified patch with more doumentations.
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2119751&group_id=80706&atid=560722
>
> I added a documentation for the colors.py module and
> ColorConverter.to_rgb() method. Is there any other place I need to
> care?
> I'll see what I can do with the user's guide also.
>
> Jouni,
> Thanks for the suggestion. But I'm afraid that I'm not so keen about
> implementing your suggestions, although their implementation should be
> very straight forward. My intention was to support only a simple color
> mixing, so trivial that my brain can actually predict the result.
> While my current code understands strings like
> "orange!30!purple!50!white", I don't think I'll ever use it because it
> is hard to predict the resulting color (at least for me). Instead,
> I'll just to look up the color table and pick up the color I want. So,
> I'm sorry, but I may not implement those features you suggested unless
> you or someone else give me a good motivation. On the other hand, I
> added a "mix_rgb" method in the ColorConverter class, which partially
> support what you have suggested.
>
> Regards,
>
> -JJ
I also tried to take a look at the user's guide documentation, but I
couldn't find the relevant section about the color (under the
doc/users directory) while the pdf version linked in the homepage DO
have a section about the color. Is it that the new sphinx-based docs
does not have the color section yet? or am I looking at the wrong
directories?
Regards,
-JJ

On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <Dav...@ir...> wrote:
> Hi,
>
> I would just undo what I have done rather than putting a lot of moved
> messages all over the place. I personally find the mix of matlab and
> non-matlab stuff in mlab confusing, but I will go with the group
> consensus.
Since noone else had anything to add here, I moved all the
numerical_methods methods back into mlab until we have a more
comprehensive solution that is friendly to the existing codebase (one
of my apps was just bitten by it...)
JDH

Attached is a diff against revision 6115 that contains a patch to
improve the behavior of the legend function when showing legends for
Collections (e.g. pyplot.scatter plots). The implemented behavior
shows three sample scatter points, adapting the properties and showing
three different colors or sizes in the even that either vary across
the points.
However, this patch is not entirely correct - I've attached a testing
script and an example of the output - as you can see, with a number of
scatter plots, the alignment between the scatter symbols and the text
is off in the legend. I suspect this has to do with the
get_window_extent(self,render) function I had to add to the Collection
class... I'm really not entirely sure what that function is supposed
to do (or what coordinates it's supposed to be transformed into). Can
anyone provide some guidance as to what should be done to fix this
vertical offset problem?

Conrad B Ammon wrote:
> 
> I can't figure out sourceforge's interface to submit a ticket, so I'm 
> mailing this to the devel list. That'll give you a sense of my urgency 
> ;- )
> 
> Subject: Axes Ylims are reversed
> Version: 0.98.3
> 
> when calling get_xlims(), the values returned are in increasing order: 
> [xmin, xmax]. With get_ylims() however, it is reversed.
> # make axes in figure, named ax
> 
> ax.get_xlims()
> >> [-5, 639]
> ax.get_ylims()
> >> [479.5, -0.5]
> 
> ax.set_ylims(ymin, ymax) seems to work, until you use the Image artist. 
> The image flips upside down when you do this.
> 
> I first noticed it when I called ax.imshow(image) and an image was right 
> side up. When I called set_ylims(ymin, ymax), it flipped upside down. 
> It was rightside up if I called set_ylims(ymax, ymin)
> 
> Workaround: simply reverse the limits when using set_lims or get_lims
> 
> Affected:
> Images
> Axes
> Axes documentation (where get_ylims is described as get_ylims(ymin, ymax) )
> 
> Sorry for not sending this to the right place,
> -Conrad Ammon
Conrad,
It is just as well to start out with a mailing list in a case like this.
What you have found is a very confusing aspect of the variable naming 
and the documentation, not a bug in the code itself. It has always been 
part of the mpl design that set_ylim and set_xlim are really setting the 
 bottom and top values, and the left and right values, in that order, 
and not the min and max.
To compound the confusion, images are inverted by default; row number 
increases from top to bottom.
See also the methods invert_yaxis, set_ybound, etc.
Eric