headers
Citi, Luca | 1 Sep 02:33
Picon
Favicon

generating colors for plots

Hi all,
I am a matplotlib user. I am new to this list. Please pardon me if it is not the right place to post it.
I was looking for an automated way to generate colors for the plots when the number of lines is high (15+).
I ended up writing these lines. If you think they can be useful to others, here they are.
Cheers,
Luca

import scipy as S

def gen_color():
    i = 1.
    while 1:
        c = S.frexp(i)[0] * 2
        c = .2 * (1 + S.sin(12 * S.pi * c)) + .3 * (1 + S.sin(2 * S.pi * (c + [0., 1./3, 2./3])))
        yield c
        i += 2

-------------------------------------------------------------------------
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=/
Permalink | Reply | 0 comments |
headers
Kevinsysu | 1 Sep 09:06
Favicon

plot performance for help


Hi all:

I'm using matplotlib for plotting in recent days. I love it especially the
usability and the plot quality.

My current work is to display a real time data set update into several 2D
graphs (5 or more, 400x400 graphs).
The environment I'm using is:
wxpython 2.8.8.1
matplotlib 0.98.3
python 2.5.1.1
Intel P IV 2.4G
Using the wxagg backend.

The issue I encoutered was that the graphs refresh took too much CPU time,
or in other word, the graph is not draw fast enough.
Sorry to raise this performance topic again, as I knew you've discussed a
lot on this topic, there're also some posts related to this, but I just
can't find a solution suite to me.

For single graph sized 400x400, my target is to reach 50 fps. Actually, it
can be easily achieved using the animation method: copy_from_bbox/
restore_region in the following link.
http://www.scipy.org/Cookbook/Matplotlib/Animations. (I reach 90+ fps with
this) The difficulty I got is that the above method is only updating the
bbox area, but I have to update the x/y axis as well. As John indicated in
another post, updating the x/y axis is the bottleneck of the draw process.
When I update the x/y axis at the same time, the performance drops to 20+
fps, which is lower than my requirement.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Firing | 2 Sep 01:32
Favicon
Gravatar

Re: irregularly spaced grids and imshowm: PATCH for bilinear interp

gl@... wrote:
> Hi Eric,
> 
> I think I understand the two approaches you mention, I have about the  
> same mental distinction although with a different spin, maybe because  
> I come from finite element/data visualisation instead of image  
> manipulation: I see basically two type of 2D data that can be  
> visualized as a colormapped image:
> 
>   a) point data, where you provide a collection of values with  
> associated coordinates. Algorithm is then fully responsible for  
> computing the "best" value to associate to other coordinates (not  
> provided by the user, but nonetheless needed to build a full image,  
> because there was a change of resolution or just some data lacking).  
> One can distinguish sub categories: are the points given on
>       - an regular rectangular grid, *
>       - a regular hexagonal/triangular grid,
>       - an irregular rectangular grid *
>       - another pattern? like mapped rectangular grid, ...
>       - at arbitrary locations, without pattern
>   for now in matplotlib only *-marked subcategories are supported, AFAIK
> b) cell data, where you provide a collection of cell (polygons), with  
> vertex coordinates and color-mapped data. Again we can distinguish su  
> categories:
>      - cell-wise data, no interpolation needed *
>      - or vertex-wise data, interpolation needed
>          -averaging on the cell
>          -proximity based interpolation
>          -(bi)linear interpolation
>          -higher order interpolation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kienzle | 2 Sep 17:40
Favicon

Re: plot performance for help

On Mon, Sep 01, 2008 at 12:06:45AM -0700, Kevinsysu wrote:
> 
> Hi all:
> 
> I'm using matplotlib for plotting in recent days. I love it especially the
> usability and the plot quality.
> 
> My current work is to display a real time data set update into several 2D
> graphs (5 or more, 400x400 graphs).
> The environment I'm using is:
> wxpython 2.8.8.1
> matplotlib 0.98.3
> python 2.5.1.1
> Intel P IV 2.4G
> Using the wxagg backend.
> 
> The issue I encoutered was that the graphs refresh took too much CPU time,
> or in other word, the graph is not draw fast enough.
> Sorry to raise this performance topic again, as I knew you've discussed a
> lot on this topic, there're also some posts related to this, but I just
> can't find a solution suite to me.
> 
> For single graph sized 400x400, my target is to reach 50 fps. Actually, it
> can be easily achieved using the animation method: copy_from_bbox/
> restore_region in the following link.
> http://www.scipy.org/Cookbook/Matplotlib/Animations. (I reach 90+ fps with
> this) The difficulty I got is that the above method is only updating the
> bbox area, but I have to update the x/y axis as well. As John indicated in
> another post, updating the x/y axis is the bottleneck of the draw process.
> When I update the x/y axis at the same time, the performance drops to 20+
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Hunter | 2 Sep 17:51
Picon
Gravatar

Re: plot performance for help

On Tue, Sep 2, 2008 at 10:40 AM, Paul Kienzle <pkienzle@...> wrote:

> Speed improvements in the matplotlib front end may be possible, for
> example by representing tics and grids as line collections rather than
> rendering each one with a separate path command.

I think the big win here would be for us to write a light-weight axis
support which doesn't have all the features of the default axis but is
fast.  Eg, it would not support all the various alignment and
rotations for ticklabels (eg, all xtick labels would be horizontally
aligned center and top aligned vertical) and would have homogeneous
font properties (don't create a bunch of Text instances, just call
draw_text repeatedly with the labels.  We could drop the locators and
formatters and mathtext and all that, and make the user responsible
for setting the locations and label strings.  We would not have
separate objects for each tick, but just draw all the markers in the
right places using a single plot command with linestyle TICK_LEFT,
etc.).  This would probably be fast enough for most quasi-realtime
plots.

I think one could use Michael's projection registry to support this
kind of thing, even though it is not a projection the infrastructure
could be used to support pluggable axis support.  This is on my TODO
list, but I probably cannot get to it right away.

JDH

-------------------------------------------------------------------------
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jae-Joon Lee | 2 Sep 19:41
Picon
Gravatar

Re: a patch to have a correct baseline when usetex=True

Here is a patch which uses a preview package. It uses a "showbox"
option in the preview package, with a slight tweak (this only patches
the texmanager.py. You still need to apply the agg backend patch in my
previous post). It would be good if this patch will be accepted, but
the extra requirement of the preview package may need some dicussion.
Although it seems that the preview package is commonly found with a
TeX installation, I guess it is not part of the major TeX distribution
(e.g. tetex, tex-live) yet. One way would be to make it as an optional
feature.

Regards,

-JJ

On Fri, Aug 29, 2008 at 12:04 PM, Jae-Joon Lee <lee.j.joon@...> wrote:
> Thanks,
>
> I quickly went through the code of the pngmath.py, and it seems that
> the depth(descent) of the dvi file is reported by "dvipng" (but the
> preview package must be used in the tex file for this to work
> correctly). Therefore, with this method, we need to run dvipng even if
> we use ps of pdf backend. Although this seems fine to me, I'll see if
> I can extract the depth of the text without running the dvipng.
>
> Regards,
>
> -JJ
>
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Walker | 2 Sep 20:06
Picon

Re: a patch to have a correct baseline when usetex=True

"Jae-Joon Lee" <lee.j.joon@...> writes:

> Here is a patch which uses a preview package. It uses a "showbox"
> option in the preview package, with a slight tweak (this only patches
> the texmanager.py. You still need to apply the agg backend patch in my
> previous post). It would be good if this patch will be accepted, but
> the extra requirement of the preview package may need some dicussion.
> Although it seems that the preview package is commonly found with a
> TeX installation, I guess it is not part of the major TeX distribution
> (e.g. tetex, tex-live) yet. One way would be to make it as an optional
> feature.

FWIW, Debian provides preview.sty in the binary package
preview-latex-style (generated from the source package auctex).

Chris

> 
> 
> 
> On Fri, Aug 29, 2008 at 12:04 PM, Jae-Joon Lee <lee.j.joon@...> wrote:
> > Thanks,
> >
> > I quickly went through the code of the pngmath.py, and it seems that
> > the depth(descent) of the dvi file is reported by "dvipng" (but the
> > preview package must be used in the tex file for this to work
> > correctly). Therefore, with this method, we need to run dvipng even if
> > we use ps of pdf backend. Although this seems fine to me, I'll see if
> > I can extract the depth of the text without running the dvipng.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Metz | 3 Sep 10:51
Picon
Favicon

xticklabels

Hi,
   I think there is bug in get_xticklabels(). According to the doc it 
should return a list of Text instances, instead it returns a list of 
TextWithDash instances. This also makes the following impossible (which 
should work of course):

xtl = ax.get_xticklabels()
ax.set_xticklabels(xtl)

Manuel

-------------------------------------------------------------------------
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=/
Permalink | Reply | 1 comment |
headers
Grégory Lielens | 3 Sep 12:39
Picon

Re: irregularly spaced grids and imshowm: PATCH for bilinear interp


> Greg,
> 
> Thank you for your very clear and complete explanation.
> 
> I have committed your patch with only a few modifications:
> 
> 0) I fixed a bug with non-agg backends by setting im.is_grayscale.
> 
> 1) I changed the handling of the interpolation kwarg.  The default is 
> still 'nearest'.
> 
> 2) I took Mike's suggestion to allocate acols and arows only if needed.
> 
> 3) I renamed pcolor_nonuniform to image_nonuniform, modified it to show 
> both types of interpolation, and added it to the set run by 
> backend_driver.py.  This is the most minimal test; one could write a 
> whole test suite to exercise various inputs and options.

Thanks for this!
> 
> Among the questions that occur to me:
> 
> 1) Should the functionality be exposed as an Axes method, and from there 
> as a pyplot function?  This could be done by integrating it into imshow, 
> either via the argument signature or via kwargs for X and Y, or it could 
> be a separate method.
it would be nice, at first I tried to find kwargs in imshow to do
exactly that (specify X and Y grid positions), and 
I did find NonUniformImage after quite a lot of documentation digging
(Continue reading)

Permalink | Reply | 0 comments |
headers
David M. Kaplan | 3 Sep 12:47
Picon
Favicon

Re: problems with labeling contour lines in 0.98.3

Hi,

Back from vacation.  The problem with not being able to end point
selection is easy to fix - allow keyboard clicks to also select points
and enter to also exit (this is the solution matlab uses).  This is easy
to add and I will try to work on it sometime over the next couple of
weeks.

I will try your example sometime soon and see what happens.  It sounds
like the problem has something to do with what happens when the label
covers the entire contour - currently the contour gets deleted entirely,
but this seems to be doing something strange in your case.

Cheers,
David

On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote:
> David -
> 
> Enjoy your vacation.
> 
> I tried the contour_label_demo and it works fine, but my problem
> remains.
> 
> I suggest you try the example I provided below, and notice the
> difference between labeling with inline=True and inline=False. When
> inline=True the contours in the middle part (which don't get labeled,
> presumably because there isn't enough room) get erased.
> 
> I figured out the manual input problem. The trick is that you require
(Continue reading)

Permalink | Reply | 2 comments |

Gmane