matplotlib-devel Mailing List for matplotlib (Page 2)

Now I see there are more options in 0.98 - 'steps-pre', 'steps-post',
'steps-mid'. The default should be steps-post for backwards
compatibility. In 0.98.3 the default is steps-pre. And sorry for the
testy tone of the previous email :)
Neil
2008年8月28日 Neil Crighton <nei...@gm...>:
> linestyle='steps' has changed behaviour between 0.91.2 and 0.98.3. The
> 'step' between two points used to move horizontally and then
> vertically from the left point neighbouring right point, now it moves
> vertically then horizontally.
>
> Was this change intentional? I hope not, because I've just spent the
> past hour working out it was the reason for my plotting routines not
> working properly :-/
>
> Neil
>

linestyle='steps' has changed behaviour between 0.91.2 and 0.98.3. The
'step' between two points used to move horizontally and then
vertically from the left point neighbouring right point, now it moves
vertically then horizontally.
Was this change intentional? I hope not, because I've just spent the
past hour working out it was the reason for my plotting routines not
working properly :-/
Neil

On Thu, Aug 28, 2008 at 6:19 AM, Sandro Tosi <mat...@gm...> wrote:
> Enthought suite is used a lot in scientific area, so mpl and enth
> almost share their users, so have it enabled would be a plus, but we
> are mainly interested in generate "no harm", so we'd like to ask you
> to confirm that enabling that support won't brake anything (but indeed
> provide a valuable asset for users).
Well, one thing to make sure of is that you do not install the version
of traits that ships with matplotlib, since it will break other
enthought packages. My understanding is that one either uses the
default rc config or the traits enabled one. Since the latter is
experimental and we are not sure if we will eventually adopt it, I
would not recommend enabling it in the debian distro. Is this your
view Darren?
JDH

This should now be fixed in SVN r6052.
Cheers,
Mike
Jae-Joon Lee wrote:
> Hi,
>
> The clip_on and clip_box arguments (and maybe clip_path also) in
> plot() command seem to have no effect. For example,
>
> In [29]: p, =plot([1,2,3], clip_on=False)
>
> In [30]: p.get_clip_on()
> Out[30]: True
>
>
> It seems that the line object is created with the given arguments but
> gets overwritten later when it is added to the axes (Axes.add_line),
>
> def add_line(self, line):
> '''
> Add a :class:`~matplotlib.lines.Line2D` to the list of plot
> lines
> '''
> self._set_artist_props(line)
> line.set_clip_path(self.patch)
>
> "line.set_clip_path(self.patch)" update clip_path, clip_box, and clip_on.
>
> So, isn't it better to do something explicitly when these arguments
> are ignored? Maybe to print out some warnings or even raise an
> exception, or do not call set_clip_path when clip_* argument is given,
> or etc.?
>
> A slightly related behavior I found unexpected is that set_clip_path()
> and set_clip_rect() method also update clip_on.
>
> 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
> 

I think this is a bug created by the conversion from 0.91 to 0.98. I'll 
look into this and let you know when it has been resolved.
Mike
Jae-Joon Lee wrote:
> Hi,
>
> The clip_on and clip_box arguments (and maybe clip_path also) in
> plot() command seem to have no effect. For example,
>
> In [29]: p, =plot([1,2,3], clip_on=False)
>
> In [30]: p.get_clip_on()
> Out[30]: True
>
>
> It seems that the line object is created with the given arguments but
> gets overwritten later when it is added to the axes (Axes.add_line),
>
> def add_line(self, line):
> '''
> Add a :class:`~matplotlib.lines.Line2D` to the list of plot
> lines
> '''
> self._set_artist_props(line)
> line.set_clip_path(self.patch)
>
> "line.set_clip_path(self.patch)" update clip_path, clip_box, and clip_on.
>
> So, isn't it better to do something explicitly when these arguments
> are ignored? Maybe to print out some warnings or even raise an
> exception, or do not call set_clip_path when clip_* argument is given,
> or etc.?
>
> A slightly related behavior I found unexpected is that set_clip_path()
> and set_clip_rect() method also update clip_on.
>
> 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
> 

Hello guys,
in a joint effort between Debian and Ubuntu on matplotlib packaging,
we were wondering if include the experimental support for
python-enthought-traits.
...
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.5.2
 enthought.traits: 2.0.5
...
Enthought suite is used a lot in scientific area, so mpl and enth
almost share their users, so have it enabled would be a plus, but we
are mainly interested in generate "no harm", so we'd like to ask you
to confirm that enabling that support won't brake anything (but indeed
provide a valuable asset for users).
Additionally, we have developed a patch for the build process
(attached) that you might be interested in merge in your codebase, in
particular hunk #2 and #3.
Cheers,
Sandro, Benjamin & Jordan
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Paul Kienzle wrote:
> Hi,
> 
> There was a recent discussion about opengl and matplotlib in the
> context of matplotlib rendering speeds.
> 
> At the scipy sprints we put together a proof of concept renderer
> for quad meshes using the opengl frame buffer object, which we
> then render as a matplotlib image. Once the data is massaged
> to the correct form we were seeing rendering speeds of about
> 10 million quads per second. See below.
> 
> Using this technique we can get the advantage of opengl without
> having to write a full backend. Please let me know if you have
> time to contribute to writing a more complete backend.
I know that I (as the other contributer :) ) plan on making this into a 
full backend provided:
1) The quadmesh code can be shown yield the gains when integrated into 
matplotlib more fully
2) I find the time (which is a matter of *when*, not if)
I'm certainly finding thus far that pyglet makes it a lot easier to do a 
full backend than some of the other python->opengl methods I'd explored 
in the past.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
There was a recent discussion about opengl and matplotlib in the
context of matplotlib rendering speeds.
At the scipy sprints we put together a proof of concept renderer
for quad meshes using the opengl frame buffer object, which we
then render as a matplotlib image. Once the data is massaged
to the correct form we were seeing rendering speeds of about
10 million quads per second. See below.
Using this technique we can get the advantage of opengl without
having to write a full backend. Please let me know if you have
time to contribute to writing a more complete backend.
 - Paul
-- meshgl.py --
# This program is public domain
import numpy
from pyglet.gl import *
import pyglet
from ctypes import POINTER,c_long,c_ubyte,c_int
def buildmesh(x,y):
 """
 x,y are corners of the mesh quadrants
 """
 # Quadlist is a list of pairs of vertices, left edge, right edge, right
 # edge, one for each row. The resulting map will look like:
 # [[p00 p10 p01 p11 p02 p12 ...] [p10 p20 p11 p21 ...] ...]
 # Note that the x,y shape will be one more than the number of data values.
 nr,nc = x.shape
 quadstrips = numpy.empty((nr-1,nc*4),'f')
 quadstrips[:,0::4] = x[:-1,:]
 quadstrips[:,2::4] = x[1:,:]
 quadstrips[:,1::4] = y[:-1,:]
 quadstrips[:,3::4] = y[1:,:]
 return quadstrips
def colorindex(z,clim,cmap):
 # Calc colour indices
 ncolors = cmap.shape[0]
 step = float(clim[1]-clim[0])/(ncolors-1)
 idx = numpy.asarray((z-clim[0])/step, dtype='i')
 idx = numpy.clip(idx, 0, ncolors-1)
 return idx
 
def buildcolor(z,clim=[0,1],cmap=None):
 """
 z are centers of the mesh quadrants.
 Note there size of z are less than size of x,y by 1 in each dim.
 """
 # Generate colours
 idx = colorindex(z, clim, cmap)
 nr,nc = z.shape
 # Quadlist is a list of pairs of vertices, left edge, right edge, right
 # edge. The resulting map will look like:
 # [[p00 p10 p01 p11 p02 p12 ...] [p10 p20 p11 p21 ...] ...]
 # The z values correspond to the bottom right corner of each quad. This
 # means we do not need the first two quads of each row and every odd
 # quad after that. The resulting color list looks like the following:
 # [[0 0 0 z00 0 z01 0 z02 ...] [0 0 0 z10 0 z11 0 z12 ...] ...]
 # Each i,j has a four byte colour value.
 colors = numpy.zeros((nr,2*nc+2,4),'B')
 colors[:,3::2,:] = cmap[idx,:]
 return colors
def draw_quads(x,y,z,clim=[0,1],cmap=None):
 strips = buildmesh(x,y)
 colors = buildcolor(z,clim,cmap)
 nr,nc = strips.shape
 nc = nc/2 # pair of vertices per point
 starts = numpy.arange(0,nr*nc,nc,'i')
 counts = numpy.ones(nr,'i')*nc
 glEnableClientState(GL_VERTEX_ARRAY)
 glEnableClientState(GL_COLOR_ARRAY)
 glVertexPointer(2,GL_FLOAT,0,strips.ctypes.data)
 glColorPointer(4,GL_UNSIGNED_BYTE,0,colors.ctypes.data)
 glMultiDrawArrays(GL_QUAD_STRIP, #starts, counts, nr)
 starts.ctypes.data_as(POINTER(c_int)),
 counts.ctypes.data_as(POINTER(c_int)),
 nr)
 glDisableClientState(GL_VERTEX_ARRAY)
 glDisableClientState(GL_COLOR_ARRAY)
 
def set_scene(w,h):
 """Set up the openGL transform matrices"""
 glViewport(0, 0, w, h)
 glMatrixMode(GL_PROJECTION)
 glLoadIdentity()
 glMatrixMode(GL_MODELVIEW)
 glLoadIdentity()
 glShadeModel(GL_FLAT)
 glEnable(GL_BLEND)
 glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
 # Clear scene
 glClearColor(1, 1, 1, 0)
 glClear(GL_COLOR_BUFFER_BIT)
def renderbuffer(w,h,draw):
 """Render buffer to off screen framebuffer object"""
 # Make sure we support frame buffers
 if not pyglet.gl.gl_info.have_extension('GL_EXT_framebuffer_object'):
 raise RuntimeError("This OpenGL does not support framebuffer objects")
 # Create a frame buffer context
 framebuffers = (GLuint*1)(0)
 glGenFramebuffersEXT(1, framebuffers)
 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, framebuffers[0])
 # Create a render buffer
 renderbuffers = (GLuint*1)(0)
 glGenRenderbuffersEXT(1, renderbuffers)
 glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, renderbuffers[0])
 glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_RGBA8, w, h)
 glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, 
 GL_RENDERBUFFER_EXT, renderbuffers[0])
 status = glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT)
 if status != GL_FRAMEBUFFER_COMPLETE_EXT:
 raise RuntimeError("Could not create GL framebuffer")
 # Render scene
 set_scene(w,h)
 draw()
 glFlush()
 # Retrieve buffer
 buffer = numpy.empty((h,w,4),'B')
 glReadPixels(0, 0, w, h, GL_RGBA, GL_UNSIGNED_BYTE, buffer.ctypes.data)
 # View the buffer in the window
 #glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0)
 # Release buffer
 glDeleteRenderbuffersEXT(1, renderbuffers)
 return buffer
# === DEMO CODE BELOW ===
def testmesh(shape=(3,2)):
 """sample scene"""
 # Quad mesh vertices (nr x nc)
 nr,nc = shape
 x = numpy.arange(nr)[None,:] + numpy.arange(nc)[:,None]
 y = numpy.arange(nr)[None,:] + numpy.zeros((nc,1))
 # Quad mesh values (nr-1 x nc-1)
 z = x[:-1,:-1]
 # Grayscale RGBA colormap
 R = numpy.linspace(0,255,64)
 alpha = numpy.ones(64,'B')*255
 cmap = numpy.array([R,R,R,alpha],'B').T
 if True:
 # Green box in center using default -1,1 coords
 glColor3f(0., 1., 0.)
 glRectf(-0.5, 0.5, 0.5, -0.5)
 
 # Set data coordinates
 glPushMatrix()
 glOrtho(0,x.max()*2,0,y.max()*2,-1,1)
 if True:
 # Blue box unit size at 1,1 in data coords
 glColor4f(0., 0., 1., 1.)
 glRectf(1, 2, 2, 1)
 draw_quads(x,y,z,clim=[z.min(),z.max()],cmap=cmap)
 glPopMatrix()
class Window(pyglet.window.Window):
 """Pyglet driver"""
 def __init__(self, w, h):
 super(Window, self).__init__(width=w, height=h, resizable=True)
 glClearColor(1.,1.,1.,1.)
 self._dirty = True
 def on_resize(self, w, h):
 print "resize"
 set_scene(w,h);
 self._dirty = True
 def draw(self):
 if self._dirty:
 print "draw"
 #window.clear()
 testmesh()
 self._dirty = False
 self.flip()
 
 def run(self):
 counter = 0
 while not self.has_exit and counter < 1000:
 self.dispatch_events()
 self.draw()
 counter += 1
 
def plot():
 """Matplotlib driver"""
 import pylab
 print "start rendering"
 b = renderbuffer(400,500,lambda: testmesh((1000,1000)))
 print "done rendering"
 pylab.imshow(b,origin='lower')
 pylab.show()
if __name__ == "__main__":
 #Window(400,500).run()
 plot()

Hi,
The clip_on and clip_box arguments (and maybe clip_path also) in
plot() command seem to have no effect. For example,
 In [29]: p, =plot([1,2,3], clip_on=False)
 In [30]: p.get_clip_on()
 Out[30]: True
It seems that the line object is created with the given arguments but
gets overwritten later when it is added to the axes (Axes.add_line),
 def add_line(self, line):
 '''
 Add a :class:`~matplotlib.lines.Line2D` to the list of plot
 lines
 '''
 self._set_artist_props(line)
 line.set_clip_path(self.patch)
"line.set_clip_path(self.patch)" update clip_path, clip_box, and clip_on.
So, isn't it better to do something explicitly when these arguments
are ignored? Maybe to print out some warnings or even raise an
exception, or do not call set_clip_path when clip_* argument is given,
or etc.?
A slightly related behavior I found unexpected is that set_clip_path()
and set_clip_rect() method also update clip_on.
Regards,
-JJ

David Baddeley wrote:
> Are there any plans for path simplification in any of the non-agg backends? When plotting large numbers of data points (~50k upwards in my case) using the ps backend the resulting file are rather large (several MB). More of a concern is that they take a very long time (~5 minutes) to render with ghostscript on a modern computer with obvious negative implications if sending to a postscript printer / including in publication graphics.
David,
Going back through my mail, I found your message. I don't know if 
anyone replied. In case no one did: yes, I think that having some path 
simplification for non-agg backends is a good idea, although slightly 
dangerous, and I hope it is not dropped. I don't really have time to 
think about your questions now; if you don't get, or haven't gotten, a 
reply from anyone, please submit your patch in a ticket:
http://sourceforge.net/tracker/?atid=560722&group_id=80706&func=browse
This should help keep it from getting forgotten.
Only quick comments below:
> 
> I've added some _very_ simple path simplification to backend_ps.py, which is sufficient for my usage (see attached diff - against 0.98pre, rev 5075). Its pretty ugly though with an arbitrary delta value for determining whether it is safe to skip a point, and a boolean switch to turn it on & off, both currently as module-level variables. 
> 
> If there is enough interest, and I was pointed in the direction of the necessary info I could try and clean it up a bit for potential inclusion.
> 
> I'd need to know the following:
> Is the backend itself the best/preferred place to be doing path simplification?
Surely it should be factored out so that the same code can be applied to 
ps, pdf, and svg. Either the path module or the backend_bases module 
seems the likely home for the code.
> What would be the best method of doing the configuration (turning on/off, setting delta)?
> It would obviously be desirable to automagically select a reasonable delta value - although this is potentially difficult as the resulting graph can be arbitrarily scaled - any ideas?
Agreed. The last time I looked, matlab essentially assumed there is a 
limit to the "arbitrary scaling", and used integers for postscript 
coordinates.
One might have an rc setting: off, auto, or a fixed value in physical 
page coordinates.
Eric
> 
> best wishes,
> David

On Sat, Aug 23, 2008 at 5:58 PM, Stéfan van der Walt <st...@su...> wrote:
> Hi all,
>
> I am putting together a new frontpage for SciPy.org, and I would like
> to add a link to the Matplotlib project. I have been trying to
> generate a windrose, which is part of your logo, but the script posted
> to the list a while ago simply produces a blank plot. Do you have a
> version available that runs under the SVN version of Matplotlib?
A precursor to our script to generate the logo is in
examples/api/logo2.py and it is currently working under svn, so you
may want to start with that.
I recall and earlier post where the windrose functionality (which
isn't included in mpl yet) was broken on the trunk because it hadn't
been ported to the new transforms api. Our logo simply makes a bar
plot with polar axes.
Let me know if you have any problems.
JDH

Hi all,
I am putting together a new frontpage for SciPy.org, and I would like
to add a link to the Matplotlib project. I have been trying to
generate a windrose, which is part of your logo, but the script posted
to the list a while ago simply produces a blank plot. Do you have a
version available that runs under the SVN version of Matplotlib?
Thanks!
Stéfan

I agree with Darren. In my previous response, I was assuming Agg-2.4 would be the requirement in Debian.
If you are planning to link to a different version, licensing may be an issue (I can't really comment on that as IANAL), but there's a high likelihood of compatibility issues. The upgrade from 2.3 to 2.4 was reasonably painful and it's impossible (without large #ifdef's of course) to code across both simultaneously.
Cheers,
Mike

As you sort of allude to, Agg is so heavily templatized that there's little benefit to linking against a shared library (little disk space savings, for instance).
However, there are some .cpp (i.e. non-header files) that need to be compiled and linked. If Debian doesn't include a shared library, how would we link to those?
You can see what .cpp files we need (we don't need all of them) by looking at build_agg in setupext.py
Assuming you can get this to work with Debian's packages, I think the cleanest way to find and link to it is by using pkg-config. Does the Agg Debian package provide a pkg-config .pc file? There is code in setupext to do pkg-config lookups -- we could try that first, and if that fails, fall back on out included copy of Agg.
What we would want to avoid, of course, is including the system Agg and linking against the local Agg as your patch appears to do. That could be a problem, especially wrt any Debian-specific patches added in the future.
Sorry I can't help more now (I'm away from the office), but let me know how far you get with this info and if you run up against something else.
Cheers,
Mike

On Thursday 21 August 2008 19:15:49 Sandro Tosi wrote:
> Hello,
> I'm currently trying to study if it's possible to remove the bundled
> agg library and use the one available in Debian instead.
>
> Currently (and sadly) we have only a -dev package (that contains only
> the development stuff) and not a real shared library to link against.
>
> If it will be available, do you think it would be possible to link the
> mpl source code against that one?
>
> As of now, I was only able to force to use the system headers file with:
>
> --- matplotlib-0.98.3.orig/setupext.py 2008年08月22日 00:12:08.622829529 +0200
> +++ matplotlib-0.98.3/setupext.py 2008年08月22日 00:12:20.759521159 +0200
> @@ -585,7 +585,7 @@
> # before adding the freetype flags since -z comes later
> add_base_flags(module)
> add_numpy_flags(module)
> - module.include_dirs.extend(['src', '%s/include'%AGG_VERSION, '.'])
> + module.include_dirs.extend(['src', '/usr/include/agg2/', '.'])
>
> # put these later for correct link order
> module.libraries.extend(std_libs)
This is something we have discussed in the past and decided against 
supporting, because agg-2.5 is released under the terms of the GPL. 
Darren

Hello,
I'm currently trying to study if it's possible to remove the bundled
agg library and use the one available in Debian instead.
Currently (and sadly) we have only a -dev package (that contains only
the development stuff) and not a real shared library to link against.
If it will be available, do you think it would be possible to link the
mpl source code against that one?
As of now, I was only able to force to use the system headers file with:
--- matplotlib-0.98.3.orig/setupext.py 2008年08月22日 00:12:08.622829529 +0200
+++ matplotlib-0.98.3/setupext.py 2008年08月22日 00:12:20.759521159 +0200
@@ -585,7 +585,7 @@
 # before adding the freetype flags since -z comes later
 add_base_flags(module)
 add_numpy_flags(module)
- module.include_dirs.extend(['src', '%s/include'%AGG_VERSION, '.'])
+ module.include_dirs.extend(['src', '/usr/include/agg2/', '.'])
 # put these later for correct link order
 module.libraries.extend(std_libs)
Thanks in advance,
Sandro
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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

Thanks for catching this. Looks like the correct solution to the error I introduced.
Cheers,
Mike

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.

On Tue, 2007年11月20日 at 11:15 -1000, Eric Firing wrote:
> Jeff Whitaker wrote:
> > If I draw two images with imshow, then set_zorder for one of them to be 
> > higher than the other, should that one be the one that displays?
> 
> Jeff,
> 
> It is a wart. Images are handled separately from other artists, and 
> always drawn first, either as a composite or in the order in which they 
> were added to the list. Here is the relevant code in the Axes.draw() 
> method:
> 
> if len(self.images)<=1 or renderer.option_image_nocomposite():
> for im in self.images:
> im.draw(renderer)
> else:
> # make a composite image blending alpha
> # list of (mimage.Image, ox, oy)
> 
> 
> mag = renderer.get_image_magnification()
> ims = [(im.make_image(mag),0,0)
> for im in self.images if im.get_visible()]
> 
> 
> im = mimage.from_images(self.bbox.height()*mag,
> self.bbox.width()*mag,
> ims)
> im.is_grayscale = False
> l, b, w, h = self.bbox.get_bounds()
> # composite images need special args so they will not
> # respect z-order for now
> renderer.draw_image(l, b, im, self.bbox)
> 
> Maybe the set_zorder method for images should raise a warning, since it 
> can't do what one might reasonably expect.
> 
> Mike may be able to comment on the prospects for removing this wart at 
> some point in the transforms branch; he is looking at related questions 
> right now.
> 
> Eric
> 
> > 
> > for example, with
> > 
> > from pylab import *
> > delta = 0.025
> > x = y = arange(-3.0, 3.0, delta)
> > X, Y = meshgrid(x, y)
> > Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
> > Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
> > Z = Z2-Z1 # difference of Gaussians
> > im2 = imshow(Z2, interpolation='bilinear', cmap=cm.gray,
> > origin='lower', extent=[-3,3,-3,3])
> > im2.set_zorder(2)
> > im1 = imshow(Z1, interpolation='bilinear', cmap=cm.gray,
> > origin='lower', extent=[-3,3,-3,3])
> > im1.set_zorder(1)
> > show()
> > 
> > I expected Z2 to be plotted, but I actually see Z1. In fact, I always 
> > see the last one that was plotted, regardless of what I set the zorder to.
> > 
> > I'm using the latest SVN, with GTKAgg.
> > 
> > -Jeff
> > 
Any idea if the "wart" can be removed? I tried to use zorder with the
SVN matplotlib (in conjuction with alpha-transparency, it can give a
great way to represent missing data in waterfall diagram)
but without success, image is still always in the back....
I did not use imshow, but NonUniformImage, but I guess the problem is
the same for all AxisImage instances...
BTW, I also submitted a patch to NonUniformImage to allows for bilinear
interpolation on rectangular non-uniform grids. I think the original
code was yours, so maybe you have something to say about the patch ;-)
Best regards,
Greg.

Hi Darren,
2008年8月18日 Darren Dale <dsd...@gm...>:
> Nevermind. It turns out its not exactly poor performance, but for some reason
> the gui events were not getting processed as frequently on windows. Maybe Qt
> changed something in an attempt to optimize performance.
>
> I applied a patch in svn 6043, but its a really simple fix. At the end of
> backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this line:
>
> QtGui.qApp.processEvents()
>
> It seemed to improve things on my windows laptop, but let me know if it fixes
> the problem for you.
Good work Darren, thanks, it works perfectly!
That is great news because I found (and reported) this bug three
months ago, so I was beginning to worry about the future of Qt4
backend.
Now I can consider updating PyQt in Python(x,y).
> I forgot to mention, the svg icons display fine for me with windows xp,
> matplotlib-0.98.
Forget about it, I've just found out that this is related to one of my
own-made packages.
Thanks
Pierre

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

On Monday 18 August 2008 09:33:47 Pierre Raybaut wrote:
> Hi Darren,
>
> 2008年8月18日 Darren Dale <dsd...@gm...>:
> >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg'
> >> by '.png' for all the icons to be displayed correctly on the navigation
> >> toolbar (only one was already loaded in the right file format).
> >
> > Could this be a problem with your installation of Qt4? I have been using
> > the
>
> I really don't know, I'll have to check this. I really thought it was
> a bug because the icons aren't all in the same format as if they were
> partially replaced from svg to png for example, so I didn't think it
> could come from my installation. But I'll check my installation.
>
> > svg icons for a while now, without any issues. In what way are they
> > displayed incorrectly?
>
> They are not displayed at all.
>
> > Did you compile qt4 without svg support?
>
> I use the official PyQt binaries, so yes, I guess.
I forgot to mention, the svg icons display fine for me with windows xp, 
matplotlib-0.98.

On Monday 18 August 2008 16:17:03 Pierre Raybaut wrote:
> Darren Dale a écrit :
> >> If you need something to prove that this has nothing to do with my
> >> machine or my software, I can tell you that there is exactly the same
> >> bug on a virtual machine, after a clean Windows XP install, and using
> >> only the official Python MSI installer and the official PyQt installer
> >> (and the latest matplotlib release of course). I also saw the same bug
> >> on three other machines, but the real proof is the VM.
> >
> > I'm not familiar with virtual machines, so I guess I dont understand what
> > that proves. I'm looking for something that indicates this is an issue
> > with matplotlib and not Qt. You found a problem once you upgraded from
> > 4.3.3, but I have not seen a similar problem. I'll try running your test
> > script on a
>
> I've just received another proof (I know that it does not solve the
> problem, but I'm feeling less lonely!): a canadian Python/Qt user
> experienced exactly the same bug (and he did the test on three different
> machines, two with XP and one with Vista).
>
> > windows machine tonight, but in the meantime, perhaps you could try to
> > determine if there is a step in
> > backend_qt4agg.FigureCanvasQTAgg.paintEvent (or somewhere else) that is
> > the source of the bottleneck.
>
> What do you mean exactly?
Nevermind. It turns out its not exactly poor performance, but for some reason 
the gui events were not getting processed as frequently on windows. Maybe Qt 
changed something in an attempt to optimize performance.
I applied a patch in svn 6043, but its a really simple fix. At the end of 
backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this line:
 QtGui.qApp.processEvents()
It seemed to improve things on my windows laptop, but let me know if it fixes 
the problem for you.
Darren

Jae-Joon Lee wrote:
> Hi all,
> 
> With the current svn, It fails with the following Exception if I try
> to draw markers (I'm using GtkAgg backends and I presume this only
> happens with Agg backends). Can others confirm this?
> 
> 745 renderer.draw_markers(
> 746 gc, Path.unit_circle(), transform, path, path_trans,
> --> 747 rgbFace)
> 748
> 749
> 
> ValueError: Codes array is wrong length
> 
> 
> And this seems to be due to the error checking code in
> "src/agg_py_path_iterator.h" recently introduced by Michael (r6033).
> At line 42,
> 
> if (PyArray_DIM(m_codes, 0) != PyArray_DIM(m_vertices, 1))
> throw Py::ValueError("Codes array is wrong length");
> 
> I guess the second argument of the PyArray_DIM should be 0 in both cases.
> 
> if (PyArray_DIM(m_codes, 0) != PyArray_DIM(m_vertices, 0))
> throw Py::ValueError("Codes array is wrong length");
> 
> 
> Above simple change worked fine for me.
Thank you, I committed the fix.
Eric
> 
> 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