matplotlib-devel Mailing List for matplotlib (Page 5)

>
> I am getting errors any time I try to plot with markers for the points
> (using the GTKAgg backend).  My SVN repo copy has a lot of my own
> changes in it, but I don't think these errors are associated with those
> changes.  Can someone confirm this is a bug?  Example below.

I also don't see that error.
Is your matplotlib code up to date?
There has been a bug which might be related with yours (at least the
raised Exception is same), but this has been fixed in the current SVN.

http://sourceforge.net/mailarchive/forum.php?thread_name=6e8d907b0808181233g4657bd05ybbc2fe8caf8fe68e%40mail.gmail.com&forum_name=matplotlib-devel

-JJ







>
> Thanks,
> David
>
> In [16]: clf(),plot([1,2],[1,2],'--')
> Out[16]: (None, [<matplotlib.lines.Line2D object at 0x9522d4c>])
>
> In [17]: clf(),plot([1,2],[1,2],'--o')
> ------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
> line 333, in expose_event
>    self._render_figure(self._pixmap, w, h)
>  File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", line 75, in _render_figure
>    FigureCanvasAgg.draw(self)
>  File
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
> line 261, in draw
>    self.figure.draw(self.renderer)
>  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
> 759, in draw
>    for a in self.axes: a.draw(renderer)
>  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1525,
> in draw
>    a.draw(renderer)
>  File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 439,
> in draw
>    markerFunc(renderer, gc, tpath, affine.frozen())
>  File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 752,
> in _draw_circle
>    rgbFace)
> <type 'exceptions.ValueError'>: Codes array is wrong length
>
> Out[17]: (None, [<matplotlib.lines.Line2D object at 0x95b1dcc>])
>
> --
> **********************************
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Mon, Sep 8, 2008 at 8:23 AM, David M. Kaplan <Dav...@ir...> wrote:
> Hi,
>
> I am getting errors any time I try to plot with markers for the points
> (using the GTKAgg backend).  My SVN repo copy has a lot of my own
> changes in it, but I don't think these errors are associated with those
> changes.  Can someone confirm this is a bug?  Example below.

I'm not seeing it on gtkagg using svn HEAD

JDH

Hi,

I am getting errors any time I try to plot with markers for the points
(using the GTKAgg backend).  My SVN repo copy has a lot of my own
changes in it, but I don't think these errors are associated with those
changes.  Can someone confirm this is a bug?  Example below.

Thanks,
David

In [16]: clf(),plot([1,2],[1,2],'--')
Out[16]: (None, [<matplotlib.lines.Line2D object at 0x9522d4c>])

In [17]: clf(),plot([1,2],[1,2],'--o')
------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
line 333, in expose_event
    self._render_figure(self._pixmap, w, h)
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", line 75, in _render_figure
    FigureCanvasAgg.draw(self)
  File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 261, in draw
    self.figure.draw(self.renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
759, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1525,
in draw
    a.draw(renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 439,
in draw
    markerFunc(renderer, gc, tpath, affine.frozen())
  File "/usr/lib/python2.5/site-packages/matplotlib/lines.py", line 752,
in _draw_circle
    rgbFace)
<type 'exceptions.ValueError'>: Codes array is wrong length

Out[17]: (None, [<matplotlib.lines.Line2D object at 0x95b1dcc>])

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

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

> I'm attaching a patch (for pdf and ps backends) which I believe
> correctly handle this.
> I hope this patch is reviewed and applied. Note that the function
> _quad2cubic is duplicated in both backends. This function might be
> moved to some common place.

Looks good. I applied this, with the quad2cubic function moved to
cbook.py and your test case included in the examples directory. Thanks!

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hello,

It seems that the pdf and ps backends draw the quadratic bezier line
incorrectly.
Here is a little test script.


# -- begin test script --
import matplotlib.pyplot as plt
import matplotlib
from matplotlib.path import Path
from matplotlib.patches import PathPatch

plt.clf()
ax = plt.gca()
ax.set_aspect(1.)
pp1 = PathPatch(Path([(0, 0), (1, 0), (1, 1), (0, 0)], [1, 3, 3, 5]), fc="none",
                transform=ax.transData)

ax.add_patch(pp1)
ax.plot([0.75], [0.25], "ro")

plt.draw()
plt.savefig("test_quad_bezier_%s" % (matplotlib.get_backend()))

# -- end --


I'm attaching the result for the pdf backend. The lower-right
(quadratic bezier) path is supposed to path through the red dot.
The agg backends are fine, and so is the svg backend. I haven't tested
with others.
I tracked down this to an incorrect conversion of quadratic bezier
curve to cubic one.
Given (q0, q1, q2) as control points of quadratic one, these backends
simply produce a cubic one with (q0, q1, q1, q2) as its control
points, which is not correct (see
http://fontforge.sourceforge.net/bezier.html for example).

I'm attaching a patch (for pdf and ps backends) which I believe
correctly handle this.
I hope this patch is reviewed and applied. Note that the function
_quad2cubic is duplicated in both backends. This function might be
moved to some common place.

Regards,

-JJ

I am not able to run the following example (link to the website
http://www.scipy.org/Cookbook/Matplotlib/Animations)

python anim.py -dWX

But, i am able to run it with out specifying a background engine, any
engine i manually selected does not work


Also another problem i am observing is that if i run the following command
python anim.py

And move the figure or click on it figure i get the following error
$ /cygdrive/c/Python25/python anim.py
FPS: 27.0635999477
Fatal Python error: PyEval_RestoreThread: NULL tstate

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


Also one last question, the figure is not very stable and will enter a
state of "no-response", if figure is moved, click on it. Also i am not
able to maximize/minimize the figure

Cheers
thanks in advance

Ray Salem

On Thu, Sep 4, 2008 at 3:30 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> In the process of documenting "linestyles" for contour, I noticed that
> in a lot of places, linestyle can be this dash tuple, which is described
> in Collection as:
>
>                The dash tuple is::
>
>                 (offset, onoffseq),
>
>             where *onoffseq* is an even length tuple of on and off ink
>             in points.
>
> But for the life of me, I cannot make this work.  Can anyone give me a
> better explanation, or better yet, a working small example (that we
> could hopefully add to the example directory)?

examples/pylab_examples/dash_control.py uses custom on/off ink, but
not the offset.  In fact, in the Line2D.set_dashes method, I see that
the offset support is reserved for a TODO.  So perhaps you should just
fix the docstring to remove the offset language and just include the
on/off sequence for ink

    def set_dashes(self, seq):
        """
        Set the dash sequence, sequence of dashes with on off ink in
        points.  If seq is empty or if seq = (None, None), the
        linestyle will be set to solid.

        ACCEPTS: sequence of on/off ink in points
        """
        if seq == (None, None) or len(seq)==0:
            self.set_linestyle('-')
        else:
            self.set_linestyle('--')
        self._dashSeq = seq  # TODO: offset ignored for now

>
> Thanks,
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,

In the process of documenting "linestyles" for contour, I noticed that 
in a lot of places, linestyle can be this dash tuple, which is described 
in Collection as:

		The dash tuple is::

                 (offset, onoffseq),

             where *onoffseq* is an even length tuple of on and off ink
             in points.

But for the life of me, I cannot make this work.  Can anyone give me a 
better explanation, or better yet, a working small example (that we 
could hopefully add to the example directory)?

Thanks,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Yes.  The FontProperties objects have a list of options that they try in 
order.

(The fname parameter is sort of an implementation detail rather than a 
public API.)

Cheers,
Mike

Jae-Joon Lee wrote:
> Hello,
>
> When I need to use unicode string in matplotlib, I often set the font
> name directly as below.
>
>  import matplotlib.font_manager as fm
>  fp1=fm.FontProperties(fname="/users/research/lee/.fonts/malgun.ttf")
>
> This used to work. But not anymore. And I guess this is related with a
> recent change in font_manager.py (r5356 by Michael),
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/font_manager.py?r1=5195&r2=5356
>
> Note that "return fname" bacame "return fname[0]".
> So, its seems that now we need to provide a list of filenames for
> fname parameters. And a code like below works.
>
>  fp1=fm.FontProperties(fname=["/users/research/lee/.fonts/malgun.ttf"])
>
> Is this change intended? I just want to make sure before I start
> changing my codes.
> Regards,
>
> -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
> 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

Hello,

When I need to use unicode string in matplotlib, I often set the font
name directly as below.

 import matplotlib.font_manager as fm
 fp1=fm.FontProperties(fname="/users/research/lee/.fonts/malgun.ttf")

This used to work. But not anymore. And I guess this is related with a
recent change in font_manager.py (r5356 by Michael),

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/font_manager.py?r1=5195&r2=5356

Note that "return fname" bacame "return fname[0]".
So, its seems that now we need to provide a list of filenames for
fname parameters. And a code like below works.

 fp1=fm.FontProperties(fname=["/users/research/lee/.fonts/malgun.ttf"])

Is this change intended? I just want to make sure before I start
changing my codes.
Regards,

-JJ

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
> to press the middle button to end (I'll do a post to the user's list).
> Many laptops don't have a middle button. Although suggestions are
> found on the web that pushing both buttons simultaneously works, I
> have never seen it work. What you have to do is configure your
> touchpad such that a corner acts as the middle button. Once I figured
> that out, I could end manually selecting the labels. Very nice. If I
> may, I strongly recommend you change the code such that pushing the
> right button ends the manual input. Is there any reason not to use the
> right button for that?
> 
> I hope you can fix the inline problem. Thanks for all the other new
> cool features,
> 
> Mark
> 
> On Tue, Aug 19, 2008 at 4:06 PM, <ka...@mp...> wrote:
>         Hi,
>         
>         I am currently on vacation, so I can´t be of much help - back
>         beginning of next month.  It would be useful if
>         you could try the clabel and ginput demo scripts and send
>         images of the resulting figures so that we can determine
>         exactly what things work and don´t work.
>         
>         Thanks,
>         David
>         
>         
>         
>         Mark Bakker <ma...@gm...> ha escrito:
>         
>         
>         
>                 Hello David and the developers list-
>                 
>                 I have had little luck on the mailing list, so sorry
>                 for writing you
>                 directly (David may be on vacation).
>                 
>                 I have two problems labeling contour lines in 0.98.3.
>                 
>                 First, when I call clabel, it removes all contours
>                 that are not labeled
>                 (because the label doesn't fit on the section of
>                 contour, I presume).
>                 This seems like a bug to me (or a really odd feature).
>                 It doesn't do this
>                 when inline = False, but I don't think it should do it
>                 either when inline =
>                 True
>                 Easy example:
>                 
>                                         x,y =
>                                         meshgrid( linspace(-10,10,50),
>                                         linspace(-10,10,50) )
>                                         z = log(x**2 + y**2)
>                                         cobj = contour(x,y,z) # Note
>                                         that there are 8 contours
>                                         levels (11
>                 contour sections in all)
>                                         cobj.clabel()
>                 <a list of 8 text.Text objects>
>                                         draw()  # Now only 5 contours
>                                         are drawn; the ones in the
>                                         middle are
>                 removed.
>                 
>                 Second, when using the new manual labeling of contour
>                 labels (which is
>                 pretty neat!), how do I end this feature?
>                 The doc string says: right click, or potentially click
>                 both mouse buttons
>                 together (which already worries me).
>                 Neither works for me on win32, mpl 0.98.3, TkAgg
>                 backend, interactive mode.
>                 Does anybody have a solution?
>                 
>                 Thanks, Mark
>                 
>         
>         
>         
>         
>         ----------------------------------------------------------------
>         This message was sent using IMP, the Internet Messaging
>         Program.
>         
> 
> 
-- 
**********************************
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
**********************************

> 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
and exploring the example directory...
> 
> 2)  If X and Y are in fact uniform, should the displayed image be the 
> same as the present imshow?  The big difference now is the boundary: 
> NonUniformImage extends boundary values indefinitely while Image uses 
> the background color for anything outside the image.  I find the 
> NonUniformImage behavior disconcerting.
You are right, it should be the same. The extrapolation present in
NonUniformImage was disconcerting to me at first too,
but I now enjoy it: it is the same as what we do in our code for
user-provided parameter dependent data: linear interpolation between
points, and flat extrapolation outside the min/max: this avoid nasty
surprises (linear extrapolation) and sidestep
the problem of providing a "default" value outside min/max bounds.
But here it is not a strong argument, as background color/full
transparency is a good default value in the matplotlib case.
I think the best approach would be to give a special kwarg
extrapolation= None/flat (and eventually add other options if needed).
> 
> 3) Should caching be added to NonUniformImage?  Every other class in the 
> image.py module uses it.
Hum, there I can not help: I do not know what caching is...Is it an
optimisation to avoid unneeded re-render, when
image size is kept unchanged? If it is, I guess optimisation can never
hurt ;-)
> 
> 4) Can we do anything with the internal function naming, at least, to 
> make the distinction between point data functions and cell data 
> functions?  My thought was to use "image" for point data and "pcolor" 
> for cell data, but this may reflect my ignorance and particular usage 
> patterns from matlab days.  What I would do is rename the _image.cpp 
> pcolor function to nonuniform_image, or something like that, to 
> distinguish it more clearly from pcolor2, which works with cell data.

Some rationalization would ne nice indeed. I do not have strong
prefences on this, image and pcolor
would work fine for me, as any other names used consistently.  It could
be the opportunity to prepare
the addition of other point/cell data function (like delaunay
triangulation of arbitrary point data in matlab, 
or non-uniform cell data with color interpolation on the cell.
For the "phong" mapping (mapping data to color after interpolating the
data for each pixel ), I am affraid the work would be even greater, as I
do not see how to use
the imshow filters in this case....except maybe using a fake "greyscale"
image working on the data directly, and they mapping the
greyscale image to color image using the color mapper pixel per pixel...
Performance would suffer, though...

Regards,

Greg.

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

"Jae-Joon Lee" <lee...@gm...> 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...@gm...> 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
> >
> >
> >
> >
> > On Fri, Aug 29, 2008 at 7:59 AM, Michael Droettboom <md...@st...> wrote:
> >> Sphinx contains one way to do this in its new "pngmath" extension.  It uses
> >> the LaTeX package "preview" which does all of this magic internally.  And I
> >> believe it's a little more general.  If I recall, the approach you're taking
> >> won't work with some LaTeX constructs such as:
> >>
> >>  \begin{align}
> >>    x & = 2
> >>    y & = 2
> >>  \end{align}
> >>
> >> Plus, Sphinx is BSD-licensed, so it should be fine to copy-and-paste
> >> whatever code is necessary.
> >>
> >> Of course, latex-preview is required to be installed, but I think it's a
> >> pretty common package.
> >>
> >> See here:
> >>
> >>  http://svn.python.org/projects/doctools/trunk/sphinx/ext/pngmath.py
> >>
> >> Cheers,
> >> Mike
> >>
> >> Jae-Joon Lee wrote:
> >>>
> >>> On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <jd...@gm...> wrote:
> >>>
> >>>>
> >>>> On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <lee...@gm...>
> >>>> wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> First of all, I borrowed this idea from the PyX which is in GPL.
> >>>>> Although there is little of copying, other than the basic idea, I'm
> >>>>> not 100% sure if this could be BSD-compatible.
> >>>>>
> >>>>
> >>>> I think it is fine to borrow the idea; what we need to do is a clean
> >>>> room implementation with no copying.  You can best answer that, so if
> >>>> you tell us your patch is cleanly implemented, we can accept it.
> >>>>
> >>>> JDH
> >>>>
> >>>>
> >>>
> >>> Thanks for the response.
> >>>
> >>> Well, the only part I borrowed from PyX is TeX related commands they
> >>> use (there is not much of implementation as far as TeX-related code is
> >>> concerned). From their code, I learned the meaning and usage of the
> >>> following TeX commands
> >>>
> >>> \newbox
> >>> \setbox
> >>> \immediate\write16
> >>>
> >>> And I used the same TeX commands in my code.
> >>> But I personally think this is not a (code) copy.
> >>>
> >>> Other than this, the code is clean.
> >>> Regards,
> >>>
> >>> -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
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>>
> >>
> >>
> >
> 
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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...@gm...> 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
>
>
>
>
> On Fri, Aug 29, 2008 at 7:59 AM, Michael Droettboom <md...@st...> wrote:
>> Sphinx contains one way to do this in its new "pngmath" extension.  It uses
>> the LaTeX package "preview" which does all of this magic internally.  And I
>> believe it's a little more general.  If I recall, the approach you're taking
>> won't work with some LaTeX constructs such as:
>>
>>  \begin{align}
>>    x & = 2
>>    y & = 2
>>  \end{align}
>>
>> Plus, Sphinx is BSD-licensed, so it should be fine to copy-and-paste
>> whatever code is necessary.
>>
>> Of course, latex-preview is required to be installed, but I think it's a
>> pretty common package.
>>
>> See here:
>>
>>  http://svn.python.org/projects/doctools/trunk/sphinx/ext/pngmath.py
>>
>> Cheers,
>> Mike
>>
>> Jae-Joon Lee wrote:
>>>
>>> On Thu, Aug 28, 2008 at 4:18 PM, John Hunter <jd...@gm...> wrote:
>>>
>>>>
>>>> On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee <lee...@gm...>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> First of all, I borrowed this idea from the PyX which is in GPL.
>>>>> Although there is little of copying, other than the basic idea, I'm
>>>>> not 100% sure if this could be BSD-compatible.
>>>>>
>>>>
>>>> I think it is fine to borrow the idea; what we need to do is a clean
>>>> room implementation with no copying.  You can best answer that, so if
>>>> you tell us your patch is cleanly implemented, we can accept it.
>>>>
>>>> JDH
>>>>
>>>>
>>>
>>> Thanks for the response.
>>>
>>> Well, the only part I borrowed from PyX is TeX related commands they
>>> use (there is not much of implementation as far as TeX-related code is
>>> concerned). From their code, I learned the meaning and usage of the
>>> following TeX commands
>>>
>>> \newbox
>>> \setbox
>>> \immediate\write16
>>>
>>> And I used the same TeX commands in my code.
>>> But I personally think this is not a (code) copy.
>>>
>>> Other than this, the code is clean.
>>> Regards,
>>>
>>> -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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>

On Tue, Sep 2, 2008 at 10:40 AM, Paul Kienzle <pki...@ni...> 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

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+
> fps, which is lower than my requirement.
> 
> Below are my questions, any kind of answer or hints would be appreciated:
> 1.	Can I reach the performance requirement by using the wxagg? If yes, how
> can I get there?
> 2.	Is there any existing backend can reach the performance requirement? Can
> it be embedded with wxpython?
> 3.	What differences (especially performance aspect) between the wxagg and
> agg backend? 
> 4.	As I know, in the recent post, Paul Kienzle is planning to develop the
> opengl backend. Could the opengl backend have a great improvement on
> performance compare with the wxagg?

You can figure out how much time is involved on the front side matplotlib
by using the null backend Template:

   import matplotlib
   matplotlib.use('Template')

This will give you an upper limit on your performance since none of the
rendering costs are shown.  If that is already down to e.g., 30 fps then
you will not see anything better from an opengl backend.

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.

	- Paul

gl...@ff... 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
>    and also it can be subdivided using cell geometry criterium
>     - cell part of a regular rectangular grid *
>     - cell part of an irregular rectangular grid *
>     - cell part of a mapped rectangular *
>     - arbitray cells, but paving the plane (vertex coodinate +  
> connectivity table)
>     - fully arbitrary cells, not necessarily continuously connected
>   Again, AFAIK for now the *-marked categories are currently suported  
> in matplotlib.
> 
> In addition to those categories, one additional thing can be  
> considered when any kind of interpolation/extrapolation is performed:  
> Does the interpolation happen on the data, and then the interpolated  
> data is mapped to color (phong mapping/interpolation/shading in matlab  
> speach), or are is the interpolation performed on colors after the  
> initial user-provided data have been mapped (gouraud  
> mapping/interpolation/shading in matlab speach).
> 
> Some equivalences exists between cell based image and point based  
> image, in particular my patch can be seen as irregular rectangular  
> grid patches bith bilinear interpolation, or point data with bilinear  
> interpolation. It is more of the second one, as for example in  
> cell-data, one can expect to be able to set line styles for cell  
> boundaries, while in point data this would have no sense.
> 
> I do not see the fact that for point data the interpolation is choosen  
> by the algorithm as a bad thing: in fact, if one use point data, it is  
> because there is no cell information as such, so the fact that the  
> algorithm choose automatically the boundaries is an advantage.
> 
> For example, your NonUniformImage is a point-data image generator,  
> which work for non-uniform rectangular grids. It associate with each  
> pixel the data of the closest (using non-cartesian distance, but a  
> "manhatan distance" given by abs(x-x0) + abs(y-y0)) available point  
> data.
> My patch added bilinear interpolation, using x and y bilinear  
> interpolation between the four closest. Other type of interpolation  
> are possible, but more complex to implement.
> 
> The context in which we want to use NonUniformImage is not for image  
> processing, but for data visualisation: we have measurement data  
> dependent on two variables (RPM and frequency), and a classic way to  
> present such data is what is known in the field (acoustic radiation)  
> as a "waterfall diagram". However, the samples are not necessarily  
> taken on a regular grid. They are taken at best on an irregular grid  
> (especially for the RPM), and at worst using a non-obvious pattern.  
> There is no cell data here, boudaries are not really relevant, the  
> only thing that matter is to provide an attractive and  
> visualy-easy-to-parse image of 2D data which was sampled (or  
> simulated) on a set of points. In this context both interpolation  
> (nearest, usefull because if present only measured data extended in  
> the best way so that they cover the whole figure, without any actual  
> interpolation), and bilinear (show smoother variations, making more  
> easy to visually detect some pattern and interresting RPM/FREQUENCY  
> regions ) are interresting for our users...
> 
> A small example as you requested (a is withing the data, b is outside,  
> c is completely oustide)
>                             c
>      11    12       13
>                 a           b
>      21    22       23
>      31    32       33
> 
> Nearest interpolation (patched (small error), but already present):
>     color at a = color at 12 or 13 or 22 or 23, whichever is closest to a
>     color at b = color at 13 or 23, whichever is closest to b
>     color at c = color at 13
> Bilinear interpolation (new):
>       S=(x23-x12)(y12-y23)
>     color at a = color(12) * (x23-xa)(ya-y23)/S
>                + color(13) * (xa-x22)(ya-y22)/S
>                + color(22) * (x13-xa)(y13-ya)/S
>                + color(23) * (xa-x12)(y12-ya)/S
>     color at b = color(13) * (yb-y23)/(y13-y23)
>                + color(23) * (y13-yb)/(y13-y23)
>     color at c = color at 13
> 
> 
> As I mentioned in my first message, to complete the full array of  
> image generation (point data, cell data, various interpolation scheme  
> and geometric distribution of points or cell geometries, interpolation  
> before or after the color mapping) is a tremendous work. Not even  
> matlab has it completed, although it is far more complete than  
> matploblib for now and can be considered a worthy goal... But I think  
> this linear interpolation after color mapping on irregular rectangular  
> point data is already a usefull addition ;-)
> 
> Regards,
> 
> Greg.

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.

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.

2)  If X and Y are in fact uniform, should the displayed image be the 
same as the present imshow?  The big difference now is the boundary: 
NonUniformImage extends boundary values indefinitely while Image uses 
the background color for anything outside the image.  I find the 
NonUniformImage behavior disconcerting.

3) Should caching be added to NonUniformImage?  Every other class in the 
image.py module uses it.

4) Can we do anything with the internal function naming, at least, to 
make the distinction between point data functions and cell data 
functions?  My thought was to use "image" for point data and "pcolor" 
for cell data, but this may reflect my ignorance and particular usage 
patterns from matlab days.  What I would do is rename the _image.cpp 
pcolor function to nonuniform_image, or something like that, to 
distinguish it more clearly from pcolor2, which works with cell data.

Eric

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.

Below are my questions, any kind of answer or hints would be appreciated:
1.	Can I reach the performance requirement by using the wxagg? If yes, how
can I get there?
2.	Is there any existing backend can reach the performance requirement? Can
it be embedded with wxpython?
3.	What differences (especially performance aspect) between the wxagg and
agg backend? 
4.	As I know, in the recent post, Paul Kienzle is planning to develop the
opengl backend. Could the opengl backend have a great improvement on
performance compare with the wxagg?

Thanks a lot for reading




-- 
View this message in context: http://www.nabble.com/plot-performance-for-help-tp19249835p19249835.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

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