[matplotlib-devel] 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=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 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 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 caseexcept 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. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 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 > 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, <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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() > > 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
[matplotlib-devel] setting the font name directly
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] setting the font name directly
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 > Matplotlib-devel@lists.sourceforge.net > 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
