matplotlib-devel Mailing List for matplotlib

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

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

>
> 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

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

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 <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
-- 
**********************************
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
**********************************

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
> 
> like,
> 
> class cm:
> def __init__(self, r, g, b):
> self.r = r
> self.g = g
> self.b = b
> def __rmul__(self, a):
> return cm(a * self.r, a * self.g, a * self.b)
> def __add__(self, a):
> return cm(a.r + self.r, a.g + self.g, a.b + self.b)
> 
-- 
Elephants can paint.
http://www.elephantart.com/catalog/thailand.php

In article 
<88e...@ma...>,
 "John Hunter" <jd...@gm...> wrote:
> On Thu, Sep 18, 2008 at 2:33 PM, Russell E. Owen <rowen@u.washington.edu> 
> wrote:
> > The versions of pytz and dateutil that are included with matplotlib
> > 0.98.3 are outdated....
> 
> Hey Russell, thanks for the head's up.
> 
> For our source installs, by default we install them only if they are
> not on the system, but you can configure this with setup.cfg to
> always, never or conditionally install them.
> 
> I have updated the mpl versions to the ones you point to above.
I just discovered that matplotlib 0.98.3 is not compatible with pytz 
2008c due to an unexpected change in pytz. The following fix works (I 
chucked it into __init__.py near the beginning).
# the following fix for compatibility with pytz 1.4.1 is from
# <http://www.mail-archive.com/pyt...@py.../msg07816.html>
import pytz
try:
 import pytz.zoneinfo
except ImportError:
 pytz.zoneinfo = pytz.tzinfo
 pytz.zoneinfo.UTC = pytz.UTC
-- Russell