Re: [matplotlib-devel] fix to clabel issues plus more
Hi, Sounds fine, though I would note that about half of the code that was in numerical_methods originally came from cbook, not mlab. This code fits equally well in mlab, so I don't have anything against putting it there. Thanks for taking care of this - I have been busy with other things. Cheers, David On Tue, 2008-09-23 at 13:24 -0500, John Hunter wrote: > On Tue, Sep 16, 2008 at 3:26 AM, David M. Kaplan <[EMAIL PROTECTED]> 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 -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] color mix
On Sep 23, 2008, at 8:29 PM, Tom Holroyd wrote:
> Repost; the list bounced my last attempt.
>
> On Fri, 2008-09-19 at 18:42 -0400, Tom Holroyd wrote:
>> On Thu, 2008-09-18 at 20:40 +0200, Jouni K. Seppänen wrote:
>>> I would prefer something like the following options:
>>>
>>> fc={'orange': 20, 'white': None}
>>> fc=[[20, 'orange'], [None, 'white']]
>>> fc=ColorMixture('orange', 20, 'white') # where ColorMixture
>>> is a fairly
>>># trivial class
>>
>> +1
>>
>> simpler, easier to read & write, less ad-hoc
>>
>> I'd go ahead and make ColorMixture a fancy class with __rmul__ and
>> __add__ methods to allow things like
>> orange = ColorMixture(255, 165, 0)
>> blue = ColorMixture(0, 0, 255)
>> mycolor = .7 * orange + .2 * blue
hsv mixing is much more useful. Take a known color and you can imagine
what a darker/lighter or paler/deeper version would look like, such as
dark green or pale blue. These are just value and saturation. Even hue
can be imagined to some degree (bluish, greenish, etc.) to move one hue
toward another, but that is harder to imagine across the circle
(e.g, greenish purple or bluish yellow).
Rather than averaging it would be easier to move some percentage toward
the other color, such as blue, but hue 20% toward green.
This can probably be expressed in operations on a color mixture class
as above.
Also a linear perceptual scale would work better than HSV but I don't
know of one off hand.
- Paul
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] yet another fancy arrow, etc
> > 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. > > Thanks. Yes, merging seems better to me too. And it seems that I can slightly tweak the current interface of my class so that it get along well with pre-existing classes. I'll work on the merge and post the patch sometime soon. > > 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 > I'm not sure if scanline_boolean does what I want (but I have to admit that I haven't looked at its code carefully yet). Do you know if it is possible to stroke along the union of the two paths (this is what I want)? My impression is that scanline thing is for filling the path. Anyhow, I'll take a more look. > > This appears to be LGPL, so we will not be using it in the main distro. > Yes, it's LGPL. And I didn't mean to include it in mpl. Anyhow, I think I'll go with the first method for the moment. Thanks, -JJ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] yet another fancy arrow, etc
Jae-Joon Lee wrote: >> 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 >> >> > > I'm not sure if scanline_boolean does what I want (but I have to admit > that I haven't looked at its code carefully yet). Do you know if it is > possible to stroke along the union of the two paths (this is what I > want)? My impression is that scanline thing is for filling the path. > Anyhow, I'll take a more look. > You should probably be able to take the union of two stroked paths -- which is not a geometry package like lib2geom would do, but it should be good enough/fast enough. Of course, any solution will have to work with all backends, not just Agg. > >> This appears to be LGPL, so we will not be using it in the main distro. >> >> > > Yes, it's LGPL. > And I didn't mean to include it in mpl. > Anyhow, I think I'll go with the first method for the moment. > It sounds like this method should also be the most portable between backends. I doubt efficiency is a concern, because there's a real upper limit on the number of these annotations before things become illegible. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] color mix
Paul Kienzle wrote: > Also a linear perceptual scale would work better than HSV but I don't > know of one off hand. L*u*v* or its cylindrical-coordinate cousin L*t*theta* (or LCH_uv). "Choosing Color Palettes for Statistical Graphics" is a nice paper talking about an implementation in R (although they do seem to misname L*t*theta* as HCL, which officially is different): http://eeyore.ucdavis.edu/stat250/epub-wu-01_abd.pdf For the "real" HCL, which also might be useful: http://mmis.doc.ic.ac.uk/mmir2005/CameraReadyMissaoui.pdf The main problem with perceptual colorspaces is that they do not map neatly to the color gamut of the RGB or CMYK colorspaces of typical rendering devices. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
