Re: [matplotlib-devel] Flash rendering in the Agg backend
While I cannot say much about the compound renderering in Agg as I know little about it, but the upsampling method that Mike mentioned seems quite robust. Just a quick question, will it affect the rendered quality of AA'ed artists, like texts? What I mean is, drawing texts w/ AA on (in the upsampled canvas) and downsampling the result may give poor quality? But maybe there is a way to adjust how AA is done in the first place. Maybe what we can try is to upsample only selected artists, similar to rasterization in vector backends or agg_filter. This will likely consume more memory and maybe more CPU, but may give minimal side effects. While it is not directly related to the current issue, I thought it would be good to have, within a backend, multiple layers to render and the final result is a composite of those layers. And we may upsample some layers or apply effects selectively. And do the alpha compositing of layers in the end. This will be also useful for animations as we can only update selected layers. Back to the original issue, I am inclined to play with Mike's upsamping method to see if it solves the problem without significant side effects. Regards, -JJ On Thu, Mar 7, 2013 at 6:54 AM, Michael Droettboom md...@stsci.edu wrote: Thanks for bringing this up -- I was just looking at the test images the other day and was reminded how filled contouring doesn't look as good as it could be. I had played with the compound renderer example in Agg some years ago, but couldn't really understand how it worked, so ultimately gave up on it. I appreciate the research you've done here, because it illustrates pretty clearly what is required. I guess in the actual Agg draw_path_collection renderer, we would have to build a style_handler table dynamically based on the collection and then iterate through it as we draw... At least it's clear now how that could be accomplished. I wonder, though, and the SVG article you link to hints at this, if we wouldn't be better off just upsampling our Agg rendering instead. The advantage of such an approach would be that the structure or ordering of the drawing wouldn't matter at all -- allaying most of Eric's concerns. It seems like it just overall be easier to do the right thing. And it should benefit all things, including other tricky things like quadmeshes, automatically. Of course, the downside is a performance hit. Assuming 2x oversampling, it means the screen buffer will be 4x the size, rendering will take up to four times as long, and then you have to downsample again (which in the best case would happen in hardware). Compound rendering has a memory penalty, too, of course, since the scanlines for all of the paths have to be stored until finally rendered out simultaneously. Estimating what that overhead is much harder, of course, and is more content dependent, whereas the performance hit upsampling is straightforward and has an obvious upper bound. I put together a very quick hack on my agg-upsampling branch, which hardcodes the upsampling to 2x in each direction. It currently only works with the GtkAgg backend (even file saving won't work correctly), and I only fixed things up for contour plotting, so images (and probably other things) will be misplaced. But it should give an idea for the performance hit and quality benefit enough to play around with. Mike On 03/06/2013 03:27 PM, Michael Droettboom wrote: I'm trying to compile your examples, but it seems perhaps you forget to include a file -- pixel_formats.hpp? It's not in the agg24 source tree. Mike On 03/06/2013 12:06 PM, Phil Elson wrote: Smart rendering of adjacent, anti-aliased patches is a question which has come up a couple of times in various guises in the past. It is my understanding that the lack of this functionality led us to disable anti-aliasing for contouring and is the reason the following image has a white stripe around the circle where there should be just a nice blend of the two colors: import matplotlib.pyplot as plt import numpy as np import matplotlib.patches as mpatches import matplotlib.path as mpath import matplotlib.collections as mcol # create two paths. One a circle, the other # a square with the same circle cut out. x = np.linspace(0, np.pi * 2, 1000) circle_coords = np.array(zip(*[np.sin(x) * 0.8, np.cos(x) * 0.8])) pth_circle = mpath.Path(circle_coords) sqr_codes = np.repeat(mpath.Path.MOVETO, len(circle_coords) + 5) sqr_codes[1:5] = mpath.Path.LINETO sqr_codes[6:] = mpath.Path.LINETO sqr_coords = np.concatenate([[[-1, -1], [-1, 1], [1, 1], [1, -1], [-1, -1]], circle_coords[::-1]], axis=0) sqr_path = mpath.Path(sqr_coords, sqr_codes) ax = plt.axes() patches = [mpatches.PathPatch(pth_circle), mpatches.PathPatch(sqr_path)] col = mcol.PatchCollection(patches, antialiaseds=True, edgecolors='none',
Re: [matplotlib-devel] Use of meta on Artist
Note that we already use a decorator for a similar purpose (allow_rasterization). Also, please note that the draw method is not just for drawing things. There are other things being done within the draw method, and I think some of them still need to be done even though the artist is invisible. My personal inclination on this issue is to refactor the draw method, the only method being called during the drawing time. But, yes there are sideeffects. Regards, -JJ On Tue, Nov 27, 2012 at 3:40 AM, Ryan May rma...@gmail.com wrote: On Mon, Nov 26, 2012 at 12:23 PM, Eric Firing efir...@hawaii.edu wrote: On 2012/11/26 7:12 AM, Michael Droettboom wrote: The problem is that I don't think we can do this for all artists. Some may need to create groupings, or push and pop state even if they are invisible. For instance, this is used in the SVG backend to create named groupings (possibly empty) that are referenced from Javascript to provide interactivity. I think I'd rather keep this to the contained solution in the PR and not try to generalize it beyond that. If we did want to generalize, this would only apply to leaf node artists, and not artists that simply exist to contain other artists -- and conceivably we could implement that using either a decorator or explicit chaining to a base class, but in any event it would have to be a manual process to determine which artists this would apply to. We could insert a class in the heirarchy of ConcreteArtist (or somesuch) to handle this. I think we should be rather conservative about this sort of thing. Sometimes it is better to just explicitly put the two lines in each method than to come up with machinery to do it for you. Each level of depth in an inheritance hierarchy or meta chain is an additional level of complexity for someone reading the code. And if someone forgets to put in those lines, the penalty is typically from small to nil; but if they are put in automatically by fancy methods, and they are not really wanted or something else goes wrong, it can make debugging painful. I think you and Mike are skirting around a key point here. You can always add the line if you need it, but if you don't need it (or can't use it), by use of a metaclass, there's no way to opt out so to speak. I'll also add that we don't need to add any more indirection (i.e. another Python function call) to our drawing stack--we really need to be doing everything possible to take every last millisecond out of the call to draw(). Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Misalignment imshow vs. grid lines
On Tue, Oct 30, 2012 at 12:25 AM, Nicolas Rougier nicolas.roug...@inria.fr wrote: Thanks for testing. If I zoom at any line cross, the lines are definitely at the wrong place for me. As jules hummon commented, I see lines in right places when I zoom in. As for screen aliasing I'm not sure since both the png and pdf seems to be wrong in my case. It still can be some aliasing-related issue. Note that with interpolation=nearest, the images are rasterized with given dpi even if you save the figure as pdf. The agg backend tries to adjust the location of lines and images so that they are well-aligned with the pixels, and the issue seems to be related with that behavior. In my case, using interpolation=none worked out okay. So give it a try. Regards, -JJ Weird ! Nicolas On Oct 29, 2012, at 15:40 , jules hummon wrote: Nicolas I get that too, (with your script and various things in my work). But if you zoom in, the lines are in the right place. Is it some kind of screen aliasing? Jules -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
I'd agree with Eric on most of his points. On Mon, Oct 15, 2012 at 5:22 AM, Eric Firing efir...@hawaii.edu wrote: If some of the PEP8 commits include genuine bug-fixes that need to be in v1.2.x, then these fixes should be made via PRs directly against v1.2.x. I think it is not a good idea to have a PR that mixes a bug-fix with a PEP8 fix that is not related with the bug. Maybe we need to ask for separate PRs, one for PEP8 fix and one for bug-fixes. Regards, -JJ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] gca() returns Axes
On Wed, Aug 22, 2012 at 6:40 AM, Eric Firing efir...@hawaii.edu wrote: Correction: now I can't reproduce what I thought I was seeing; plt.gca() is returning an AxesSubplot as it should. Maybe the problem is in the axes_grid1 toolkit. It is appearing in the last figure of the tight_layout tutorial in the docs. For axes which uses axes_locator, tight_layout works if the axes_locator have associated subplotspec. And, only allowing instance of SubplotBase is too strict. The PR below addresses this issue. https://github.com/matplotlib/matplotlib/pull/1170 And it will work again for the axes_grid1 cases. Regards, -JJ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Added Phil Elson as a developer
Welcome aboard, Phil! Regards, -JJ On Thu, May 31, 2012 at 8:55 PM, John Hunter jdh2...@gmail.com wrote: Phil Elson has been making pull requests for some time now on matters great and small, from hairy transformations improvements to minor docstring cleanups to GUI fixes. Given his prolific work, I thought it would be suitable to recognize him as a core matplotlib developer by adding him to the github organization. While the distributed nature of the github system blurs the line between official and regular developers, it is helpful to recognize those who make frequent quality contributions and give them the permissions to merge pull requests into the main repo. Thanks for all your help Phil, and welcome aboard. JDH -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Inconsistent naming of legend points
I think what we may do is to make the default value of scatterponts to None, and if None, set it to the value of numpoints. But, I want to hear how others think about it. Regards, -JJ On Fri, Mar 30, 2012 at 11:39 PM, Pim Schellart p.schell...@astro.ru.nl wrote: Dear all, there is an inconsistency in the naming of the variable that describes the number of points to display in the legend. For `plt.plot` and `plt.errorbar` it is called numpoints but for `plt.scatter` it is called scatterpoints. It would be less confusing if both could be set with a simple numpoints in the legend function. Please let me know what you think. Kind regards, Pim Schellart -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.1.1rc does not fix tight_layout for figtext?
I'm afraid that, unfortunately, it won't be fixed soon (if ever, as far as I can tell). What tight_layout does is to adjust the *subplot parameters* of the figure so that the subplots fit in. Artists created with figtext command is not affected by the subplot parameters, i.e. there is not much thing we can do for these artists within the current implementation. It would be better if some warning is printed in such case (there are lots of cases that tight_layout will fail), but this is not currently done. Depending on your need, you may leave out some area for figtext when you call tight_layout. This is only supported for gridspec though. import matplotlib.pyplot as plt import matplotlib.gridspec as gridspec fig = plt.figure() gs1 = gridspec.GridSpec(2, 2) ax_list = [fig.add_subplot(ss) for ss in gs1] fig.text (02, 0, test, horizontalalignment='left', verticalalignment='bottom', size=5) fig.text (0.5, 1, 01, horizontalalignment='left', verticalalignment='top', size='x-small') gs1.tight_layout(fig, rect=[0, 0.03, 1, 0.97]) # adjust rect parameter to make some room for figtext. Regards, -JJ On Wed, Mar 28, 2012 at 9:17 PM, Neal Becker ndbeck...@gmail.com wrote: I just tried 1.1.1rc to see if it fixed the tight_layout for figtext. I have a semilogy plot, and add some lines of text on the bottom (and top): plt.figtext (0, 0, res['carriers'].values, horizontalalignment='left', verticalalignment='bottom', size=5) plt.figtext (0.5, 1, self.pageno, horizontalalignment='left', verticalalignment='top', size='x-small') ##plt.tight_layout(pad=1.0) plt.tight_layout() The text on the bottom is overprinting the x axis - the same as happened with the previous release. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...
On Mon, Jan 30, 2012 at 5:26 AM, Jeff Whitaker jsw...@fastmail.fm wrote: unless matplotlib takes into account all the artist objects associated with a figure. My primary reason behind not accounting all the artists was that, in general, Matplotlib does not know the exact bounding box of artists when the artists are clipped. In the current implementation, axes title, axis labels and ticklabels are only accounted, and we have an optional parameter of *bbox_extra_artists* so that users can manually change this behavior. By the way, for now, I'm more inclined to change the behavior to account all the texts artists (at least), although we may see white space sometimes. Regards, -JJ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...
Please see if this PR works. https://github.com/matplotlib/matplotlib/pull/689 Regards, -JJ On Mon, Jan 30, 2012 at 1:03 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Mon, Jan 30, 2012 at 5:26 AM, Jeff Whitaker jsw...@fastmail.fm wrote: unless matplotlib takes into account all the artist objects associated with a figure. My primary reason behind not accounting all the artists was that, in general, Matplotlib does not know the exact bounding box of artists when the artists are clipped. In the current implementation, axes title, axis labels and ticklabels are only accounted, and we have an optional parameter of *bbox_extra_artists* so that users can manually change this behavior. By the way, for now, I'm more inclined to change the behavior to account all the texts artists (at least), although we may see white space sometimes. Regards, -JJ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in Draggable Legend
I just committed a change that I believe that fixes this problem. https://github.com/matplotlib/matplotlib/commit/be420a34031c9c50813bc5be5f01a3cfb49639a1 Regards, -JJ On Fri, Mar 4, 2011 at 12:58 AM, James Kitchen jim...@yahoo.com wrote: Hi all, I found a small bug in the Draggable Legend feature when you single-click on a legend, but don't drag it. It raises a TypeError. Here's code to reproduce. Try dragging the legend, then single-click the legend. #!/usr/bin/env python import matplotlib as mpl import pylab fig = pylab.figure() ax = fig.add_subplot(111) ax.plot(range(10), range(10), c='r', marker='^', picker=5, label='Ramp') legn = ax.legend() legn.draggable() pylab.show() Here's the stacktrace when I single-click: Exception in Tkinter callback Traceback (most recent call last): File C:\Python26\lib\lib-tk\Tkinter.py, line 1410, in __call__ return self.func(*args) File C:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py, line 312, in button_release_event FigureCanvasBase.button_release_event(self, x, y, num, guiEvent=event) File C:\Python26\lib\site-packages\matplotlib\backend_bases.py, line 1561, in button_release_event self.callbacks.process(s, event) File C:\Python26\lib\site-packages\matplotlib\cbook.py, line 262, in process proxy(*args, **kwargs) File C:\Python26\lib\site-packages\matplotlib\cbook.py, line 188, in __call__ return mtd(*args, **kwargs) File C:\Python26\lib\site-packages\matplotlib\offsetbox.py, line 1466, in on_release self.finalize_offset() File C:\Python26\lib\site-packages\matplotlib\legend.py, line 51, in finalize_offset loc_in_canvas = self.get_loc_in_canvas() File C:\Python26\lib\site-packages\matplotlib\offsetbox.py, line 1512, in get_loc_in_canvas ox, oy = offsetbox._offset TypeError: 'instancemethod' object is not iterable Jim -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] legend refactoring
On Sun, Feb 13, 2011 at 6:08 AM, Benjamin Root ben.r...@ou.edu wrote: In particular, the following just produces an empty box: This has been fixed in my side, and the fix will be included when I commit. Another use-case that doesn't seem addressed yet (and isn't quite right in regular mpl either) is legends for stemplots. So far, I only implemented legend for bars and errorbars. For other plots, such as stemplot, while I'll try to implement some of them eventually, contribution from others will be needed. Regards, -JJ -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] some issues with legend
On Sun, Jan 30, 2011 at 10:32 PM, Peter Butterworth butt...@gmail.com wrote: When plotting interactively is it actually possible to update the legend with the current plots while retaining the previous legend settings (position, visibility, etc.) ? I think it is possible, but will be quite difficult to do for a normal user. I may try to add some method that can ease this. here are some observations on the mpl legend operation: leg = ax.get_legend() #0 OK. but the recommended way to update a legend seems to be using #1 ? leg = ax.legend() #1 OK leg.draggable(True) #3 enables the legend to be moved with mouse. New in mpl1.0.1. OK leg.set_visible(False) #4 hides legend. OK ax.legend(loc=3) #2 defines a legend location. OK but why no locations outside the plotting area ? Legend can be located outside the plotting area, anywhere you want. http://matplotlib.sourceforge.net/users/legend_guide.html#legend-location ax.legend(ax.lines) #5 labels are different by default from #1. ?? http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.legend If there is a single non-keyword argument, it is treated as a list of labels. ax.legend([]) #6 draws an empty square. ?? To me, the current behavior seems reasonable. What do you expect? leg._loc: #7 allows you to know the legend location. in #2 value is int, in #3 value is a tuple (if the legend has been moved) OK but why is the attribute private ? I guess this is a valid point. I'll add a public interface to access this value. What to exclude from a legend : Objects without an explicit label (labels starting with _) #8. OK Objects that are not in the viewing area #9. should be default behavior ?? Objects that are not set visible #10. should be default behavior ?? For #9, I don't think there is an exact algorithm to check if a path is inside the viewing are or not when cubic splines are involved. If there is (and that algorithm is feasible), we may consider making that a default behavior. Otherwise, I'm not inclined to include a partial solution. For #10, I'll make it a default behavior if there is no objection. Regards, -JJ -- thanks, peter butterworth -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git-svn matplotlib mirror
On Wed, Jan 26, 2011 at 7:28 PM, Pauli Virtanen p...@iki.fi wrote: The complete magic stanza is: git reflog expire --expire=0 --all git prune git repack -f -a -d git gc --prune=0 Wonderful! With this, I get about 40 MB! Regards, -JJ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] backporting typo fixes?
Big thank you for correcting those typos where virtually all of them are mine. I'm +1 for backporting these changes as they will not break anything. But others may have different ideas. Regards, -JJ On Tue, Jan 18, 2011 at 4:35 AM, Paul Ivanov pivanov...@gmail.com wrote: Hi everyone, I just committed a big typos fix to trunk (r8925), should changes like this be backported to the maintenance branch? best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk00mfQACgkQe+cmRQ8+KPe3GgCeJfWOFkR3eVcxFmk6LoBLfwBX QfoAn00POewPxxsyz+x3pMV2QKlcxRuh =cNxK -END PGP SIGNATURE- -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Path.to_polygons problem
Can you see if setting the should_simplify to False work? i.e.,
path=cs.collections[5].get_paths()[0] #210 vertices
path.should_simplify = False
path.to_polygons()
At least, it seems to conserve the number of vertices.
Regards,
-JJ
On Tue, Jan 18, 2011 at 5:07 PM, Lionel Roubeyrie
lionel.roubey...@gmail.com wrote:
Hi,
is there a existing patch for this problem or do we have to use/modify
iter_segments for the moment?
thanks
2011/1/15 Lionel Roubeyrie lionel.roubey...@gmail.com:
The problem appends on some paths/polygons, not all. Have a look at
the joined pictures. The to_polygons method normally take care about
polygons holes, but here some vertices are not converted, resulting in
wrong geometries.
#
import numpy as np
import pylab as plb
a=np.recfromtxt('rpatch3.grid', delimiter='\t',names=True)
lev=np.linspace(a.ux.min(), a.ux.max(), 10)
cs=plb.tricontourf(a.lon, a.lat, a.ux, lev)
path=cs.collections[5].get_paths()[0] #210 vertices
path.to_polygons() #16 vertices :(
#
Cheers
2011/1/14 Michael Droettboom md...@stsci.edu:
It's not obvious to me that this is wrong. The path has a MOVETO
command (1) in the middle, and thus should require the creation of two
polygons. Can you provide some code or pictures that demonstrate the
problem?
Mike
On 01/13/2011 05:54 PM, Lionel Roubeyrie wrote:
Hi all,
Using the last 1.0.1 matplotlib version,sometimes exporting paths to
polygons gives wrong results like here (paths come from a
tricontourset) :
In [94]: path
Out[94]:
Path([[ 172.0079229 -43.79390934]
[ 171.97660793 -43.785 ]
[ 171.96206864 -43.78273625]
[ 171.959 -43.78114859]
...
[ 171.593 -44.00678244]
[ 171.64906502 -44.01 ]
[ 171.654 -44.01077106]
[ 171.7068607 -44.0160044 ]], [1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2])
In [95]: path.vertices.shape
Out[95]: (210, 2)
but to_polygons gives another result :
In [98]: path.to_polygons()
Out[98]:
[array([[ 172.0079229 , -43.79390934],
[ 171.86039224, -43.65 ],
[ 172.081 , -43.54450289],
[ 172.386 , -43.57010293],
[ 172.60631978, -43.67753099],
[ 172.59231502, -43.71219961],
[ 172.325 , -43.78095532],
[ 172.02 , -43.79497729]]),
array([[ 171.715 , -44.0160044 ],
[ 173.02676111, -43.92 ],
[ 172.935 , -43.53340591],
[ 171.40281884, -43.70029758],
[ 171.37760645, -43.94389688],
[ 171.54044973, -44.0037666 ],
[ 171.7068607 , -44.0160044 ],
[ 171.7068607 , -44.0160044 ]])]
Cheers
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Lionel Roubeyrie
lionel.roubey...@gmail.com
http://youarealegend.blogspot.com
--
Lionel Roubeyrie
lionel.roubey...@gmail.com
http://youarealegend.blogspot.com
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
Re: [matplotlib-devel] two gridspec patches (fix getitem bug and docs)
Thanks for the patches. I just committed the getitem patch to the trunk with slight modifications. As I think this is not a serious bug, I didn't push it to the maintenance branch. I'll review the doc patch and commit it later this week. On the other hand, I don't think it is a good idea to have the GridSpec iterable. While the code below could be handy, outer_grid = GridSpec(4, 4) for cell in outer_grid: ... It could be confusing as the code below would not work. for cell in outer_grid[:]: ... In other words, iter(outer_grid) != iter(outer_grid[:]). outer_grid[:] is not iterable actually. So my current inclination is to force the GridSpec also not iterable. How others think? Regards, -JJ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Annotations - negative points and pixels don't wrap
The patch is applied to the maintenance branch (r8846) and the trunk (r8847). -JJ On Wed, Dec 22, 2010 at 11:49 PM, Stan West stan.w...@nrl.navy.mil wrote: From: Jae-Joon Lee [mailto:lee.j.j...@gmail.com] Sent: Monday, December 13, 2010 05:24 Attached is a preliminary fix. So, please test it if you can. Thank you. Your fix seems to do the trick. I personally think it is better to use offset points for these cases which makes the internal logic much simpler. I can see that, and that's what I was using as a work-around. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Annotations - negative points and pixels don't wrap
I believe this was recently introduced when I refactored the annotation code. Attached is a preliminary fix. So, please test it if you can. Since the change during the refactoring was rather significant, I'm not 100% sure if this will restore the old behavior without affecting the new functionality. The examples I tried (including yours) seem to work fine. I'll test this myself a few more days, and commit to the svn. I personally think it is better to use offset points for these cases which makes the internal logic much simpler. Regards, -JJ On Sat, Dec 11, 2010 at 6:07 AM, Stan West stan.w...@nrl.navy.mil wrote: Hi. The docs for Annotation [1] say that negative coordinates given for [ figure | axes ] [ points | pixels ] xycoords are to be interpreted relative to the top-right corner, but I found that they act relative to the bottom-left corner as for positive coordinates. This can be seen in the attached script and in the annotation_demo.py example [2], where the string bottom right (points) bleeds off the left edge of the figure. [1] http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.text.Annotation [2] http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo.html -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel fix_annotation.diff Description: Binary data -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] bbox of eps backend : test needed
Hi, I just committed a simple change that disables pstoeps in ps backend when xpdf distiller is used. Without this, output bbox was incorrect with xpdf distiller and usetex=False. Getting the correct bbox with the ps backend is very tricky, and it'll be appreciated if others help me test this. Here is a simple test script (this needs to be run with most recent svn version of matplotlib, and you need to able to use ustex=True!). It will produce 6 eps files. Please check if any of the eps files have incorrect bbox. And report which file has wrong bbox and your setup : your OS, gs version number (output from gs -v), pdftops version number (output from pdftops -v). It will be also good if you report your setup even when everything is okay. Regards, -JJ import matplotlib.pyplot as plt plt.plot([1,2]) for distiller in [False, xpdf, ghostscript]: for usetex in [True, False]: plt.rcParams[ps.usedistiller]=distiller plt.rcParams[text.usetex]=usetex plt.savefig(test_bbox_%s_%s.eps % (distiller, usetex)) -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] sub-sub-plots, sub-sub-sub-plots, etc.
On Sat, Oct 23, 2010 at 7:09 AM, Kynn Jones kyn...@gmail.com wrote: Without knowing much about the internals of matplotlib, it seems to me that the best way to do this would be to define a container class that can have itself as one of the contained elements. In this way, a containment hierarchy of arbitrary depth could be defined. But it is my understanding that there is no immediate way to do this in matplotlib now, so I'd have to implement it myself. Matplotlib has a simple hierachy of Figure-Axes-Artists (this is not 100% correct description as a matter of fact, see http://matplotlib.sourceforge.net/users/artists.html for more details). All Axes instances have associated positions within a figure instance. If you want to have a hierarchy of multiple axes, what you can do basically is to make those positions in hierarchical manner. This can be very trivial depending on what exactly you want (e.g., how you want the axes sizes (and the gaps inbetween) specified). However, there are a few ways to ease this process. http://github.com/astraw/mplsizer mpl v1.0 has gridspec. http://matplotlib.sourceforge.net/users/gridspec.html#gridspec-using-subplotspec For example, you may do something like import matplotlib.gridspec as gridspec fig = gcf() gs0 = gridspec.GridSpec(2, 2) ax = fig.add_subplot(gs0[0, 0]) gs00 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs0[1]) ax2 = fig.add_subplot(gs00[0]) gs000 = gridspec.GridSpecFromSubplotSpec(2, 2, subplot_spec=gs00[1]) ax3 = fig.add_subplot(gs000[0]) Or, you can use axes_grid toolkit as mentioned above. Regards, -JJ -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Suggested revisions to multiple_yaxis_with_spines example
I push the new example in r8740. Thanks. -JJ On Sat, Oct 9, 2010 at 12:15 AM, Stan West stan.w...@nrl.navy.mil wrote: Greetings. I initially encountered some difficulty following the multiple_yaxis_with_spines example, especially regarding what the functions make_patch_spines_invisible and make_spine_invisible were doing to the par2 axes and why. For example, make_spine_invisible is really making one of the spines visible. I'd like to offer the attached modifications, which mainly simplify the manipulations and add explanatory comments. Minor changes include removing access to a global variable in make_patch_spines_invisible and removing a duplicated set_xlabel. The generated figure is unchanged. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clf(), Axes3D and add_subplot
Eric, The drawing order of multiple axes in a same figure depends on the order of axes. And this has been the order that axes is added to the figure (given that they have same zorder value). However, the current implementation does not preserve this order. For example, ax1 = axes([0.1, 0.1, 0.5, 0.5]) ax2 = axes([0.4, 0.4, 0.5, 0.5]) draw() # ax2 on top of ax1 sca(ax1) draw() # ax2 underneath ax1 For some artist that spans multiple axes (e.g., an arrow connecting two points in different axes), the drawing order of the axes is important. We may manually adjust the zorder. Still. I think it is better if Figure.axes preserves the order that axes are added. I believe this bug also affects the maintenance branch. Are you planning to propagate this changes to the maint. branch also? Besides, I think none of the matplotlib artist add itself to its parent during the initialization. And, I think this is more of the design choice, i.e., the artist instance is added to its parent after the initialization. Anyhow, such distinction may not very practical in the current implementation and I'm completely okay with your changes (except the issues above). Regards, -JJ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clf(), Axes3D and add_subplot
On Thu, Sep 9, 2010 at 9:38 AM, Eric Firing efir...@hawaii.edu wrote: Fixed in 8693. Thanks! -JJ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clf(), Axes3D and add_subplot
On Thu, Sep 9, 2010 at 4:13 AM, Eric Firing efir...@hawaii.edu wrote: I don't think I understand the point you are making here--is it that the Axes3D is a lone anomaly? Yes. And I feel that Axes3D better not add itself to the figure during the instance initialization. Just a different view of the current bug. The main purpose of the changes I made was to clarify the tracking of axes by having them internally listed in only one data structure instead of always having to add or remove them from three separate structures. Fixing the 3D bug was a side-effect. Whether the changes I made were a net improvement, or a good design, remains debatable. Criticisms and suggestions for improvement or replacement are welcome. I think this is what need to be done and I think you did it right (thank you for your effort). I just wanted to raise a question of whether we let Axes3D add itself to its parent (although this is not a bug anymore). If you and others feel okay about it, then that's completely fine with me also. Regards, -JJ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clf(), Axes3D and add_subplot
On Fri, Sep 3, 2010 at 4:14 AM, Benjamin Root ben.r...@ou.edu wrote: I think there are multiple issues here. Primarially, there is the issue that Axes3D is attaching itself to a figure. However, in the interest of backwards-compatibility, we can't just fix this outright. There is also the issue that there are multiple places in the Figure class that are adding axes to the figure object. Ideally, shouldn't we have a single function that performs proper checks and adds an axes? Then that function should be used in the other class functions to perform this action. In my opinion, there is too much duplicated code here. While I agree that we need to do something with the duplicated code, I think our priority should be fixing a bug. The easiest solution (that is backward compatible) seems to be registering an Axes class that does not add itself to the figure. For example, class Axes3DBase(Axes): # All of the original Axes3D stuff, but do not add itself to the figure during the initialization class Axes3D(Axes3DBase): def __init__(self, ...) Axes3DBase.__init__(self, ...) self.fig.add_axes(self) # And register Axes3DBase instead of Axes3D import matplotlib.projections as proj proj.projection_registry.register(Axes3DBase) Regards, -JJ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom-sized and spanning subplots
On Wed, Sep 1, 2010 at 9:33 AM, Benjamin Root ben.r...@ou.edu wrote: matplotlib version 1.0 now has a few different tools that could help you. There is GridSpec, http://matplotlib.sourceforge.net/api/gridspec_api.html# http://matplotlib.sourceforge.net/users/gridspec.html There is also AxesGrid1: http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/index.html#toolkit-axesgrid-index axesgrid1 can do things that gridspec cannot (e.g., fixed size axes such as 5x5 inch) , but I would recommend it for an experienced user. Regards, -JJ Maybe one of these could be what you are looking for? -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs
Hmm, it seems that somehow I only applied the patch to the trunk. http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revisionrevision=8418 But I think the patch also need to be applied to the maint. version. I'll see what I can do. Regards, -JJ On Wed, Aug 25, 2010 at 3:42 AM, Erik Tollerud erik.tolle...@gmail.com wrote: Did this fix ever get applied? I was looking at some other svn changes and it still says none of this part of legend.py has been altered... On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud erik.tolle...@gmail.com wrote: Jae-Joon, your patch looks to be effectively the same except for slightly different behavior when more than 3 points are present... but that was what was originally intended - the numpoints- scatterpoints was a good catch! I'm not sure if I put those numbers in the first places (maybe not), yes, that was what was originally intended. And I'm inclined to leave it as is. I'll commit the change soon. Thanks again. -JJ -- Erik Tollerud -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] broken imshow
Michael, In your commit 8585, you added an extra apply_translation command in the make_image function (line 594 of image.py, note that there is another one at line 599). Currently, imshow command places image in wrong place (except when interpolation is nearest ) and I think this is because of the extra translation. Tor reproduce the problem, import numpy as np import matplotlib.pyplot as plt arr = np.arange(100).reshape((10, 10)) plt.imshow(arr, interpolation=bilinear, extent=(1,2,1,2)) plt.xlim(0,3) plt.ylim(0,3) plt.show() The image are not at what it meant to be. Removing one of the translation solves the problem. And I guess that line is there by mistake? Can you check this and commit the fix if possible. Regards, -JJ -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Exploring
I don't think this is just an issue of bbox_inches option. For
example, if you create an axes of rect=[0,0,1,1] and save the figure
(w/o bbox_inches option), you will see a similar behavior.
Also, I believe that the result depends on the backends.
I think this kind of issue is quite difficult to resolve and I doubt
if this will be solved anytime soon.
Any contribution will be very much appreciated.
Regards,
-JJ
On Sat, Jul 31, 2010 at 5:48 AM, Damon McDougall
d.mcdoug...@warwick.ac.uk wrote:
Aha! Even without the text, i.e. setting label1On = False for all the major
ticks, the behaviour I see is that with bbox_inches = 'tight' and pad_inches
= 0.0 I get the saved figure which includes the black border line for the
bottom and left edges, but not the top and right edges. This may have
something to do with it. Maybe it's an issue with the bounding box not being
'inclusive' and leaving out the end points?
Regards,
-- Damon
--
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.mcdoug...@warwick.ac.uk
On 30 Jul 2010, at 20:33, Eric Firing wrote:
On 07/30/2010 06:32 AM, Damon McDougall wrote:
Hmm, it seems as though tick labels get clipped on the top and on the right
when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this
behaviour. Is there perhaps a bug in Bbox.union that's causing this?
Not likely. Much more likely is a problem in calculating the rendered
size of the text.
Eric
Regards,
-- Damon
--
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.mcdoug...@warwick.ac.uk
On 30 Jul 2010, at 16:03, Tony S Yu wrote:
On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
Hi,
I'm interested in fiddling around with the matplotlib source. Let's say
we set up various things:
from matplotlib.figure import Figure()
from matplotlib.backends.backend_pdf import FigureCanvasPdf as
FigureCanvas
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(1, 1, 1)
fig.savefig('asd.pdf', bbox_inches='tight')
I would like to know what exactly happens when bbox_inches='tight' is
passed to savefig(). I've been searching in the figure.py source and
nowhere can I see the bbox_inches='tight' keyword being tested for in the
savefig() method. Having said that, all of the kwargs do get passed on to
the canvas.print_figure() method, so I looked in the backend_pdf.py file
but couldn't find a print_figure() method. Could someone point me in the
right direction?
Regards,
-- Damon
That's funny: I was just looking at bbox_inches='tight' recently. You'll
find the relevant section in matplotlib.backend_bases.print_figure.
Best,
-Tony
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] noslice with interpolation 'nearest'
In r8472, I tried to modify the image slicing so that it works even if images are rotated and skewed. And the noslice option is now gon. Let me know if it causes any problem. Regards, -JJ On Tue, Jun 22, 2010 at 11:05 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: Eric, I should have left more comments about my change. The issue is that the current slicing algorithm sometimes fails with _draw_unsampled_image which support arbitrary affine transformation of the image. The slicing gets wrong when the image is significantly skewed or rotated. So, as a temporary measure, I simply wanted to disable the slicing until we have a correct algorithm in place. I guess a quick (still temporary) fix is to check if affine transform is needed, and do the slicing if not. Something like below. The condition is not exactly correct, but I think it would work in most of cases. I actually didn't test the patch. I'll be out of town until the end of this week. On a second thought, I think it should not be difficult to workaround the slicing thing for arbitrary affine transform. I'll think about the whole issue again when I get back. If you have a better idea, please go ahead and implement. Regards, -JJ diff --git a/lib/matplotlib/image.py b/lib/matplotlib/image.py index 7c1128f..b65f446 100644 --- a/lib/matplotlib/image.py +++ b/lib/matplotlib/image.py @@ -248,9 +248,14 @@ class _AxesImageBase(martist.Artist, cm.ScalarMappable): + if self._image_skew_coordinate: + no_slice = True + else: + no_slice = False + im, xmin, ymin, dxintv, dyintv, sx, sy = \ self._get_unsampled_image(self._A, self.get_extent(), - self.axes.viewLim, noslice=True) + self.axes.viewLim, noslice=no_slice) if im is None: return # I'm not if this check is required. -JJL On Tue, Jun 22, 2010 at 8:45 PM, Eric Firing efir...@hawaii.edu wrote: JJ, In AxesImageBase._draw_unsampled_image, there is a call to _get_unsampled_image(...noslice=True). When using imshow(Z, interpolation='nearest'), this defeats the slicing that makes such a difference when zooming and panning a small chunk of a large image. Changing it to False makes imshow work better; I don't understand why one would ever want noslice=True. Am I missing something? Can we just change it to False? Or remove the noslice option and kwarg entirely? Eric -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] noslice with interpolation 'nearest'
Eric, I should have left more comments about my change. The issue is that the current slicing algorithm sometimes fails with _draw_unsampled_image which support arbitrary affine transformation of the image. The slicing gets wrong when the image is significantly skewed or rotated. So, as a temporary measure, I simply wanted to disable the slicing until we have a correct algorithm in place. I guess a quick (still temporary) fix is to check if affine transform is needed, and do the slicing if not. Something like below. The condition is not exactly correct, but I think it would work in most of cases. I actually didn't test the patch. I'll be out of town until the end of this week. On a second thought, I think it should not be difficult to workaround the slicing thing for arbitrary affine transform. I'll think about the whole issue again when I get back. If you have a better idea, please go ahead and implement. Regards, -JJ diff --git a/lib/matplotlib/image.py b/lib/matplotlib/image.py index 7c1128f..b65f446 100644 --- a/lib/matplotlib/image.py +++ b/lib/matplotlib/image.py @@ -248,9 +248,14 @@ class _AxesImageBase(martist.Artist, cm.ScalarMappable): +if self._image_skew_coordinate: +no_slice = True +else: +no_slice = False + im, xmin, ymin, dxintv, dyintv, sx, sy = \ self._get_unsampled_image(self._A, self.get_extent(), - self.axes.viewLim, noslice=True) + self.axes.viewLim, noslice=no_slice) if im is None: return # I'm not if this check is required. -JJL On Tue, Jun 22, 2010 at 8:45 PM, Eric Firing efir...@hawaii.edu wrote: JJ, In AxesImageBase._draw_unsampled_image, there is a call to _get_unsampled_image(...noslice=True). When using imshow(Z, interpolation='nearest'), this defeats the slicing that makes such a difference when zooming and panning a small chunk of a large image. Changing it to False makes imshow work better; I don't understand why one would ever want noslice=True. Am I missing something? Can we just change it to False? Or remove the noslice option and kwarg entirely? Eric -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc build failure
The issue was related with the change in Sphinx v1.0b2, which I think I fixed in r8447. At least, the html are built fine and uploaded fine. However, the link to trunk-docs still does not work. http://matplotlib.sourceforge.net/trunk-docs/ Can someone check what's wrong? TIA, -JJ On Sat, Jun 5, 2010 at 1:54 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: The link to the trunk-version of the documentation http://matplotlib.sourceforge.net/trunk-docs/ has not been working for a few days. And this seems to be due to build failure on one of th build bot. http://mpl-buildbot.code.astraw.com/waterfall However, the the documentation build just fine in my local installation. Does anyone else has doc build failure? Andrew, can you take a look if you have a chance? Regards, -JJ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
On Wed, Jun 9, 2010 at 6:22 PM, Eric Firing efir...@hawaii.edu wrote: Jeff can correct me if I am wrong, but I think adjustable='box' is essential for basemap because the maximum data limits are set when the Basemap instance is created. In some cases the characteristics of the projection, and in all cases the extraction of coastlines, is set at instantiation time. You can zoom in to show smaller regions, but you don't want apply_aspect to expand the data limits beyond their initial values. I think that, as axes in matplotlib, by default, has adjustable='box', it should be okay without explicitly setting adjustable='box' in most cases. With explicit adjustable='bbox', * you will fix when a user accidentally provided an axes with wrong adjustable value. * On the other hand, you will prohibit any axes sharing when Basemap is used (there are cases when axes sharing is fine even if the aspect is set to equal). So, I guess my point is that it might be good in this case to let the user be responsible for what he is doing. Since I'm not a regular Basemap user, it is just my point of view (which might be wrong) from the outside. Regards, -JJ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs
On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud erik.tolle...@gmail.com wrote: Jae-Joon, your patch looks to be effectively the same except for slightly different behavior when more than 3 points are present... but that was what was originally intended - the numpoints- scatterpoints was a good catch! I'm not sure if I put those numbers in the first places (maybe not), yes, that was what was originally intended. And I'm inclined to leave it as is. I'll commit the change soon. Thanks again. -JJ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
On Thu, Jun 10, 2010 at 1:13 PM, Benjamin Root ben.r...@ou.edu wrote: Taking out adjustable='box' had the same effect for me as setting adjustable='box-forced Just a quick comment. As you can verify, the axes created with AxesGrid will have adjustable=datalim. With AxesGrid, the size of each axes is adjusted before they call apply_aspect, hence the value of adjustable actually does not matter from the AxesGrid point of view. My recollection is that bbox-forced option was originally meant to be used with a normal axes. Regards, -JJ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs
Thanks for reporting these. I took a look at your patch and slight revised it (see the attached). While I believe that my patch is compatible to yours, it'll be great if you check my patch to see if I missed anything. I'll commit the change soon. Regards, -JJ On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior in the legend and managed to track down the source of the problem and make a fix (a diff against the current svn is attached). Specifically, two things were fixed: *The markerscale argument for the legend seems to do nothing... The attached diff properly applies the markerscale scaling for polygon/circle collections and the markers for lines with markers (but NOT patches or the width of lines elements in the legend). *If the scatterpoints argument was 3, all points beyond 3 disappeared. This was because the default scatteryoffset only had 3 entries, so if you didn't specifically overwrite this, the points beyond 3 didn't appear. I've re-worked this so that now the default properly deals with a number of points other than 3. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel scatterfix_jjlee.diff Description: Binary data -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
On Wed, Jun 9, 2010 at 4:18 PM, Eric Firing efir...@hawaii.edu wrote:
My sense is that box-forced lets you shoot yourself in the foot with
shared axes, box doesn't. The reason I prohibited sharing x and y axes
with adjustable as box is that it is not clear what should happen, or
will happen--fundamental inconsistencies can arise. Suppose you have
two axes sharing x and y. You set aspect to 1 for the first and 2 for
the second. The first axes is drawn, executing apply_aspect and setting
the box dimensions accordingly. Then the second is drawn, also
executing apply_aspect. It is inconsistent with the first. There is no
solution that satisfies all constraints. The basic point is that when
using apply_aspect with adjustable as box, you have to have freedom to
change one of the axes, and this is not in general consistent with
sharing both axes--though it may be in particular cases.
Very likely there is a way of refining the logic, but beware: getting
aspect ratio control to work under a wide range of conditions, including
all sorts of zooming and resizing, is tricky and laborious. It is much
easier to break it than to fix it, and the breakage can be hard to spot.
Eric
box-forced must be only used in a very limited cases when axes
sharing is okay.
For example, when both x and y axis are shared and both axes have same
aspect ratio and the original axes position of both axes have same
width and height.
Hm, maybe it is better to limit the visibility of the box-forced
option from normal users.
For the issue of the Basemap using
ax.set_aspect('equal',adjustable='box',anchor=self.anchor)
I think (adjustable=box) is not necessary here. Simply using
ax.set_aspect('equal',anchor=self.anchor)
should work and it will also resolve the compatibility issue with
axes_grid toolkit.
But this issue should be addressed by Jeff. I'm not quite familiar with Basemap.
Regards,
-JJ
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs
I'm not very kin to implement every possible options for every possible cases. If you need customization beyond what the current legend class provide, I recommend you to use proxy artists. http://matplotlib.sourceforge.net/users/legend_guide.html#using-proxy-artist I personally think that the drawing of the legend handle should be delegated to the associated artist (but fall back to the default behavior when not provided). Regards, -JJ On Wed, Jun 9, 2010 at 4:32 PM, Benjamin Root ben.r...@ou.edu wrote: I was trying the patch and I realized a possible use-case that might not have been thought of before. Consider the situation where a user does a scatter plot with markers of two different sizes. Then, it isn't that far-fetched that the user might also want to control the markerscale for each marker in the legend. A particular example would be that a user selected a smaller markersize for the second scatterplot so that one could see the markers from the first scatterplot if they share the same coordinates. However, they may wish to display the markers in the legend so that they have the same size. Currently, the markerscale argument accepts only a scalar, and not a list. I don't know how difficult it would be to modify it do that, but it is a thought. Ben Root On Wed, Jun 9, 2010 at 2:23 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: Thanks for reporting these. I took a look at your patch and slight revised it (see the attached). While I believe that my patch is compatible to yours, it'll be great if you check my patch to see if I missed anything. I'll commit the change soon. Regards, -JJ On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior in the legend and managed to track down the source of the problem and make a fix (a diff against the current svn is attached). Specifically, two things were fixed: *The markerscale argument for the legend seems to do nothing... The attached diff properly applies the markerscale scaling for polygon/circle collections and the markers for lines with markers (but NOT patches or the width of lines elements in the legend). *If the scatterpoints argument was 3, all points beyond 3 disappeared. This was because the default scatteryoffset only had 3 entries, so if you didn't specifically overwrite this, the points beyond 3 didn't appear. I've re-worked this so that now the default properly deals with a number of points other than 3. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] doc build failure
The link to the trunk-version of the documentation http://matplotlib.sourceforge.net/trunk-docs/ has not been working for a few days. And this seems to be due to build failure on one of th build bot. http://mpl-buildbot.code.astraw.com/waterfall However, the the documentation build just fine in my local installation. Does anyone else has doc build failure? Andrew, can you take a look if you have a chance? Regards, -JJ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root ben.r...@ou.edu wrote: I have noticed that the svn repo still does not have rasterization decorators for some of the collections (e.g., PolyCollection, EllipseCollection, CircleCollection if I remember correctly). Don't know what are supposed to be the final list of Collection that are eligible for that decorator, but it is incomplete at this point in the trunk. Did you actually test that the rasterization does not work for these artist? They are supposed to, and and they do in my installation. If you simply saying that the draw method of these artist are not decorated, they don't need one because Collection.draw which is called inside their draw method is already decorated. Regards, -JJ -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: [Matplotlib-users] [mplot3d] change axis background color
On Wed, Jun 2, 2010 at 10:51 AM, Benjamin Root ben.r...@ou.edu wrote: This is from the matplotlib-users list. A user noticed that he can not change the background color of a 3d plot with arguments to .savefig(). Is this a bug or is it intentional? Thanks, Ben Root I think it is just that they are implemented differently. The background of axes3d is not actually a figure background but an axes patch. If you want, you can make the patch invisible. This will show the default gray background of the figure. Also, the options like transparent=True will work. ax.patch.set_visible(False) Regards, -JJ -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
It seems that pcolormesh silently ignores some of the keyword parameters, and rasterized is one of them. And I'm not sure this is intended behavior or not and I hope other developers step in. In the meantime, use a member method explicitly. p2 = pcolormesh(arr) p2.set_rasterized(True) Regards, -JJ On Tue, Jun 1, 2010 at 12:05 PM, Benjamin Root ben.r...@ou.edu wrote: On Tue, Jun 1, 2010 at 9:39 AM, Ryan May rma...@gmail.com wrote: On Mon, May 31, 2010 at 11:28 AM, Benjamin Root ben.r...@ou.edu wrote: Markus, That is good to know that it has been fixed. As for the difference in pcolor and pcolormesh, I think it has to do with the fact that pcolormesh is composed of many lines while pcolor is composed of many polygons. It is probably more efficient to rasterize polygons than lines. To be blunt, this makes no sense whatsoever. First, pcolormesh and pcolor differ in that it pcolor uses a generic PolyCollection to draw the quads, while pcolormesh uses a quadmesh object, which can be more efficient at the cost of generality, as it only needs to render a set of identical quads. Second, if you're talking rasterized drawing, in the end what gets written to a file is a 2D array of RGBA values. It doesn't matter what you use to produce the results: identical image on the screen - identical array in file. It's possible that there are slight differences that you can't really see that produce different arrays, but that won't cause a factor of 8 difference in size. My guess is that pcolormesh isn't rasterizing properly. Indeed, you are right that lines aren't drawn. I have looked back at the images produced by my test script that I posted to this thread and I see where I got confused. The pcolormesh result in pdf and eps files have very faint white blocks around each quad. At high enough data resolution, the color part of the quads look like lines while the white lines look like dots. This happens regardless of using rasterized=True or not, and I don't think it is visible in png files (although I am testing some very high resolution png files to verify). Ben Root -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
If Basemap explicitly sets aspect=1 and adjustable=box at the same
time, you cannot use this with any axes that shares its axis with
others (including the axes created by the AxesGrid).
You need to somehow avoid the set_aspect call with adjustablebox
(you can set box-forced in stead).
-JJ
On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root ben.r...@ou.edu wrote:
On a related note, I have noticed an incompatibility between AxesGrid and
Basemap. It appears that Basemap will explicitly set adjustable='box' when
it calls ax.set_aspect(), but AxesGrid will error out, saying that it has to
be 'datalim'. What are the implications of using 'box-forced' instead of
'box' in Basemap?
Ben Root
On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote:
ax1 = subplot(121)
ax2 = subplot(122, sharex=ax1, sharey=ax1)
ax1.set_adjustable(box-forced)
ax2.set_adjustable(box-forced)
arr1 = np.arange(100).reshape((10, 10))
ax1.imshow(arr1)
arr2 = np.arange(100, 0, -1).reshape((10, 10))
ax2.imshow(arr2)
Note the use of set_adjustable(box-forced).
sharex and sharey does not get along with axes of aspect=1
adjustable=box.
-JJ
On Thu, May 27, 2010 at 2:10 PM, phob...@geosyntec.com wrote:
Do the “sharex” and “sharey” kwargs help?
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes
http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html
-paul
From: Adam Fraser [mailto:adam.n.fra...@gmail.com]
Sent: Thursday, May 27, 2010 10:44 AM
To: matplotlib-users
Subject: [Matplotlib-users] Is there a way to link axes of imshow plots?
Suppose I have a figure canvas with 3 plots... 2 are images of the same
dimensions plotted with imshow, and the other is a scatterplot. I'd like
to
be able to link the x and y axes of the imshow plots so that when I zoom
in
one, the other zooms to the same coordinates, and when I pan in one, the
other pans as well.
I started hacking my way around this by
subclassing NavigationToolbar2WxAgg
(shown below)... but there are several problems here.
1) This will link the axes of all plots in a canvas since all I've done
is
get rid of the checks for a.in_axes()
2) This worked well for panning, but zooming caused all subplots to zoom
from the same global point, rather than from the same point in each of
their
respective axes.
Can anyone suggest a workaround?
Much thanks!
-Adam
from matplotlib.backends.backend_wxagg import NavigationToolbar2WxAgg as
NavigationToolbar
class MyNavToolbar(NavigationToolbar):
def __init__(self, canvas, cpfig):
NavigationToolbar.__init__(self, canvas)
# override
def press_pan(self, event):
'the press mouse button in pan/zoom mode callback'
if event.button == 1:
self._button_pressed=1
elif event.button == 3:
self._button_pressed=3
else:
self._button_pressed=None
return
x, y = event.x, event.y
# push the current view to define home if stack is empty
if self._views.empty(): self.push_current()
self._xypress=[]
for i, a in enumerate(self.canvas.figure.get_axes()):
# only difference from overridden method is that this one
doesn't
# check a.in_axes(event)
if x is not None and y is not None and a.get_navigate():
a.start_pan(x, y, event.button)
self._xypress.append((a, i))
self.canvas.mpl_disconnect(self._idDrag)
self._idDrag=self.canvas.mpl_connect('motion_notify_event',
self.drag_pan)
def press_zoom(self, event):
'the press mouse button in zoom to rect mode callback'
if event.button == 1:
self._button_pressed=1
elif event.button == 3:
self._button_pressed=3
else:
self._button_pressed=None
return
x, y = event.x, event.y
# push the current view to define home if stack is empty
if self._views.empty(): self.push_current()
self._xypress=[]
for i, a in enumerate(self.canvas.figure.get_axes()):
# only difference from overridden method is that this one
doesn't
# check a.in_axes(event)
if x is not None and y is not None and a.get_navigate() and
a.can_zoom():
self._xypress.append(( x, y, a, i, a.viewLim.frozen(),
a.transData.frozen()))
self.press(event)
--
___
Matplotlib-users mailing list
matplotlib-us...@lists.sourceforge.net
https
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
If possible, can you try the latest svn version and see if it makes any difference? Also, see if increasing the dpi helps, i.e., savefig(..., dpi=150) Given the nature of the rasterization, I'm not sure if we can completely avoid the white gap for low dpi settings. But the displacement issue you see (although think it has been fixed in the svn) needs to be fixed. Regards, -JJ -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Proposal for Broken Axes
On Mon, Mar 29, 2010 at 12:30 PM, Jeff Klukas klu...@wisc.edu wrote: # Create BrokenAxes with bottom from 0 to 5 and top from 30 to 35 ax = plt.broken_axes(ybounds=[0.,5.,30.,35.]) # Plot a line onto BOTH subaxes ax.plot(range(35),range(35)) The call to plot would get routed through __getattribute__, which would then call plot for each of the subaxes. This would be much more intuitive than my existing breaky solution, where you have to loop over all subaxes and plot on each individually. How do you want to handle l1, = ax.plot(range(35), range(35)) l1.set_color(r) then? I think keeping two (or more) separate artists for each axes while an user think there is only one artist (because only one axes is exposed to the user) is not a good idea. Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sun, Mar 21, 2010 at 8:10 PM, Fernando Perez fperez@gmail.com wrote: Mmh, back to this one: I do think it would be something useful to have somewhere, because typing draw() after *every* operation when working interactively does get tiresome, it seems to me... If we encourage calling subplots() for new teaching, then we do want it to be as pleasant as pyplot to use interactively, I think... I think the first issue that needs to be addressed is whether we want to encourage OO api in the interactive mode (I mean, when a user expect the figure gets updated as soon as a command is executed). Using *subplots* does not necessarily mean that we need to use OO api, since we now have *sca* in the pyplot namespace. So. how other developers think? Are we going to encourage OO api in the interactive mode? Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Selecting all the way to the edge of a plot
I guess I misunderstood your original issue. I think I fixed this in r8210. So please give it a try. Regards, -JJ On Sun, Mar 21, 2010 at 6:42 PM, Anne Archibald aarch...@physics.mcgill.ca wrote: On 21 March 2010 18:10, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald aarch...@physics.mcgill.ca wrote: Often when I want to zoom in, I want to change only (say) the upper x and y limits. I pushed a change into the svn that enables this, but in a different way than you suggested. The behavior I implemented is similar to the current behavior of the pan mode, i.e., if you hold the x key pressed during pan/zoom, only the x-axis is updated. Same for y key. I hope this is good for your needs also. Well, it's an interesting feature, but it doesn't address the problem I'm seeing. What I'd like to be able to do is, say, to change only the upper x and y limits, simply click where I want those limits to be and drag right off the corner of the plot. This actually works, but when I do this the drag rectangle freezes the moment my pointer leaves the axes, so that it does not represent the area being zoomed to. I've attached a screenshot illustrating the bug. Note where the pointer is and where the to be zoomed rectangle is. I use Linux, with the default backend, whatever that is. Anne Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu wrote: Done in svn 8205. Thanks! Or, how about we make axes an context manager. This would require dropping support for Python 2.4. I don't think making the Axes a context manager means dropping python 2.4 support (note that I'm not saying we use with statement in the mpl source). Everything should work fine in python 2.4 (please correct me if I'm wrong). It just gives a user a choice. If a user runs his/her script with python 2.5 and higher, he/she has an option to use an axes as an context manager. Of course, if he/she want his/her own code supported in python 2.4, he/she should not use with statement. Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu wrote: By the way, given that we now have suplots in the pyplot namespace, can we have sca also? Done in svn 8205. Eric, A minor question. I wonder whether an explicit for-loop inside pyplot.sca is necessary? Here is a slight variation w/o a for-loop (well, the for-loop is implicitly done with the in operator I guess) that seems to work for me, but I may be missing something. managers = _pylab_helpers.Gcf.get_all_fig_managers() if ax.figure.canvas.manager in managers and \ ax in ax.figure.axes: _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager) ax.figure.sca(ax) return raise ValueError(Axes instance argument was not found in a figure.) Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Selecting all the way to the edge of a plot
On Sun, Mar 14, 2010 at 3:43 PM, Anne Archibald aarch...@physics.mcgill.cawrote: Often when I want to zoom in, I want to change only (say) the upper x and y limits. I pushed a change into the svn that enables this, but in a different way than you suggested. The behavior I implemented is similar to the current behavior of the pan mode, i.e., if you hold the x key pressed during pan/zoom, only the x-axis is updated. Same for y key. I hope this is good for your needs also. Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sun, Mar 21, 2010 at 6:07 PM, Eric Firing efir...@hawaii.edu wrote: I think your version would need an additional try/except or conditional, because a Figure doesn't necessarily have a canvas assigned to it, and a canvas doesn't necessarily have a manager. Granted, the problem would arise only under odd circumstances involving a mixture of pyplot and OO styles--and maybe there is actually something that would prevent the problem from arising at all--but I would want to be sure the problem either was handled, or could not arise. So, I think my version ends up being simpler, safer, and easier to understand--at least for me. I see. Thanks! -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez fperez@gmail.com wrote:
I wonder if it's possible to put things like a draw_if_interactive()
call at the end of the OO methods... I realize that pyplot was the
only one meant to do that, but if we are to encourage using the OO api
more, then it's going to have to be as pleasant to use as pyplot... I
don't know the codebase well enough to mess with this right now, so I
hope someone who's more versed in that part of the code can make a fix
for this whose impact isn't too severe on the runtime of OO code.
I'm not very inclined to this but I'll wait to hear what others think.
I use oo api in the interactive mode but I still prefer to call draw()
explicitly.
Of course, we can make it optional.
By the way, given that we now have suplots in the pyplot namespace,
can we have sca also?
For example,
# Two subplots, the axes array is 1-d
f, axarr = subplots(2, sharex=True)
sca(axarr[0])
plot(x, y)
title('Sharing X axis')
sca(axarr[1])
scatter(x, y)
Or, how about we make axes an context manager.
# Two subplots, the axes array is 1-d
f, axarr = subplots(2, sharex=True)
with axarr[0]:
plot(x, y)
title('Sharing X axis')
with axarr[1]:
scatter(x, y)
This may not very useful in the interactive mode, but may make a
script (written in pylab mode) more readable.
Regards,
-JJ
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problem with scatter legend entries with dpi != 72
Thanks for the report. A fix has been committed in r8191 (maint. branch) and r8292 (head). Give it a try and let me know of any problems. Regards, -JJ On Sat, Mar 13, 2010 at 4:49 PM, Ray Speth sp...@mit.edu wrote: Hello, I am encountering a problem with the legend entries for scatter plots when setting a figure DPI different from the default of 72. When the DPI is higher than 72, the markers in the legend become disproportionately large and get scrunched together. It looks like what is happening is the marker size is being transformed twice, and the offsets are not being transformed at all. I have tried to debug it, and it looks like the problem is the way that the DrawingArea that contains the legend interacts with the Collection object. To fix the spacing, the _transOffset property of the Collection needs to be set, but the transform being applied by the DrawingArea ends up scaling the marker size instead. I have attached a sample script which shows the problem. I am using the current development version of matplotlib checked out from git, with Python 2.6.2. The issue also exists in version 0.99.1. Thanks, Ray Speth -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] FontProperties being ignored...
Do you have fonts whose family name is sans serif? Maybe you meant sans-serif? sans-serif searches for fonts whose family name is in rcParams[font.sans-serif], but sans serif only search for sans serif. I don't think it has anything to do with annotation. Check if findfont gives you a correct font. Please report back with matplotlib version etc., if findfont finds a correct font but annotation still shows with a wrong font. Regards, -JJ import matplotlib.font_manager fm = matplotlib.font_manager.fontManager print matplotlib.font_manager.findfont(normalFont) On Thu, Mar 4, 2010 at 7:07 PM, James Evans jreva...@earthlink.net wrote: All, I just submitted bug #2963827 detailing this, but thought that I would echo the problem here… When plotting annotations and specifying the FontProperties to use, the specified values are completely ignored. See the attached script and image for an example. Am I doing something inherently wrong, or is this really a bug? Thanks, --James Evans -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] image_nonuniform.py broken in trunk HEAD
Should be fixed with r8178. Regards, -JJ On Wed, Mar 3, 2010 at 5:19 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Wed, Mar 3, 2010 at 4:48 PM, John Hunter jdh2...@gmail.com wrote: JJ is this related to your commit in r8035 : support unsampled image for ps backend It seems to be. I'll take a look. Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] annotation improvement
A few days ago I committed a patch with which I tried to improve the coordinate handling of annotation. And I updated the annotation guide which describes the change in some detail. http://matplotlib.sourceforge.net/trunk-docs/users/annotations_guide.html#using-complex-coordinate-with-annotation And here is an example http://matplotlib.sourceforge.net/trunk-docs/examples/pylab_examples/annotation_demo3.html I hope this is useful for others as this has been one of my wishlist. Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Feb 18, 2010 at 11:50 PM, Fernando Perez fperez@gmail.com wrote: I defer to your wisdom here: I had no clue about this, so I went for the clumsier API. If you are right, it would also make the implementation much simpler, as I had to play some not-totally-obvious gymnastics to alter axis creation order based on this parameter. After quickly going through the mpl source (and in my experience), I think it is quite safe to assume that there is no master-slave relation among the shared axes. One more, related question: is it possible/reasonable to share *both* x and y axes? Yes, it is possible as I often do. It would be really nice if you were correct. The api could be nicer and the implementation simpler. Also, how about subplots returns a some kind of object so that we may define some methods on it. We can define __iter__ method so that above syntax also works. As an example, mysubplots = subplots(4,1, sharex=True) mysubplots.label_outer() ax1, ax2, ax3, ax4 = mysubplots Mmh, more than I have time for right now, I'm afraid (I'm really pushing it with these little side-trips already). But if you do have a minute to do it, run with it. I can only commit to finish the basic implementation with the changes discussed above, plus any fixes to share* based on clarifying these points. A fancier object API would be great to have, so by all means go ahead if you have the bandwidth! I, personally, am more interested in implementing some form of a general interface (base class) for a set of axes, although I have no immediate plan. If I have a chance to work on this, I will try to adjust those to work with well your code. Regards, -JJ Cheers, f -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:17 PM, John Hunter jdh2...@gmail.com wrote: Perhaps the solution to my sharex conundrum is to support an axes number, eg ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1) I thought there is no master and slave for an axis-sharing? If that's the case, maybe sharex=True should be suffice? Also, how about subplots returns a some kind of object so that we may define some methods on it. We can define __iter__ method so that above syntax also works. As an example, mysubplots = subplots(4,1, sharex=True) mysubplots.label_outer() ax1, ax2, ax3, ax4 = mysubplots Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Subclasses Axes
On Sat, Feb 13, 2010 at 2:23 PM, T J tjhn...@gmail.com wrote: Subclasses of Axes, such as PolarAxes, inherit many functions which make implicit assumptions of rectilinear coordinates. From a design perspective, it seems like most of these functions should not belong to the parent class, and that, perhaps, there should exist a RectilinearAxes(Axes) class. Essentially, Axes should contain only the methods that are generic enough for every type of axis. If I were to create my own subclass of Axes, I'll either have to tell people to not use some of the methods or I'll have to re-implement them all (which is definitely not going to happen quickly). Does this refactoring seem reasonable? In general, I think this is reasonable thing to do. However, I'm afraid that this refactoring will involve significant efforts as the current Axes implementation implicitly assumes rectlinear coordinates in so many places. So, I'm not sure if any of the developers is willing to dive in, but any contribution will be welcomed. Regards, -JJ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar issue
I just committed the changes. Regards, -JJ On Wed, Jan 27, 2010 at 2:31 PM, Eric Firing efir...@hawaii.edu wrote: Jae-Joon Lee wrote: On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: Adding a set_ticks method seems reasonable. A patch is attached. It looks like exactly what I had in mind with respect to set_ticks. I wasn't thinking about set_ticklabels; my sense is that manually setting ticklabels tends to be tricky and error-prone, and should be discouraged. Maybe it should be permitted only when a FixedLocator is already in use. It does some refactoring and introduces three new methods, set_ticks, set_ticklabels and update_ticks, on the colorbar class. So, now one can do imshow(np.arange(100).reshape((10,10))) cb = colorbar() cb.set_ticks([0, 40, 80]) Issuing a warning when user try to call Axis.set_ticks (or others) directly seems not straight forward as the axes can be created externally (i.e., when *cax* is provided). Attached patch against svn (without your patch) shows how this can be done for the Axes methods. I would be more difficult (but not impossible) for the Axis methods, because we need to use them. I think that handling the Axes methods *may* be worthwhile (marginal), but handling the Axis methods is more trouble than it is worth. Eric I'll wait for response for a few more days and will commit the change. Regards, -JJ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] registerable backend and minor refactoring of backend-ps
Dear all, I just committed a small change that enables a user to register a custom backend that will be used with savefig. For example, import matplotlib.backend_bases from matplotlib.backends.backend_ps import FigureCanvasPS, RendererPS class RendererPSCustom(RendererPS): def draw_path(self, gc, path, transform, rgbFace=None): print custom draw path RendererPS.draw_path(self, gc, path, transform, rgbFace) class FigureCanvasPSCustom(FigureCanvasPS): _renderer_class = RendererPSCustom def print_eps_custom(self, outfile, *args, **kwargs): print Using Custome backend return self._print_ps(outfile, 'eps', *args, **kwargs) matplotlib.backend_bases.register_backend(eps_custom, FigureCanvasPSCustom) plt.plot([1,2,3]) plt.savefig(a.eps, format=eps_custom) # this will save the file using backend_ps_cmyk The api may need some cleanups or modifications, and any suggestion will be welcomed. Also committed is a some refactoring of ps backend but the change should be quite transparent. Regards, -JJ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ps backend with images in cmyk
I'm experimenting with a customized ps backend that saves images in cmyk colorspace. It simply converts the rgb image to cmyk (using lcms), and nothing more (i.e., it does not embed the icc profile inside the eps file). While I don't see practical usefulness of this other than for a previewing purpose, give it a try if you're interested (the current svn matplotlib is required). Any comment of suggestion will be welcomed. http://github.com/leejjoon/mpl_ps_cmyk Regards, -JJ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] registerable backend and minor refactoring of backend-ps
Nothing much in the regards of the functionality.
It only provides a way to use custom backends with savefig, which I
think is more convenient for interactive use. For example, with the
ps_cmyk backend that I'm playing with, the only thing that I need to
do is to import the module (ps_cmyk) and call
savefig(test.eps, format=eps_cmyk)
And all other (interactive) work flow is not affected by the use of
the custome backend.
In non-interactive mode where a user explicitly calls
matplotlib.use, there is no need to register a backend.
Regards,
-JJ
On Wed, Feb 3, 2010 at 4:15 PM, Ryan May rma...@gmail.com wrote:
On Wed, Feb 3, 2010 at 2:01 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote:
Dear all,
I just committed a small change that enables a user to register a
custom backend that will be used with savefig.
For example,
import matplotlib.backend_bases
from matplotlib.backends.backend_ps import FigureCanvasPS, RendererPS
class RendererPSCustom(RendererPS):
def draw_path(self, gc, path, transform, rgbFace=None):
print custom draw path
RendererPS.draw_path(self, gc, path, transform, rgbFace)
class FigureCanvasPSCustom(FigureCanvasPS):
_renderer_class = RendererPSCustom
def print_eps_custom(self, outfile, *args, **kwargs):
print Using Custome backend
return self._print_ps(outfile, 'eps', *args, **kwargs)
matplotlib.backend_bases.register_backend(eps_custom, FigureCanvasPSCustom)
plt.plot([1,2,3])
plt.savefig(a.eps, format=eps_custom) # this will save the file
using backend_ps_cmyk
The api may need some cleanups or modifications, and any suggestion
will be welcomed.
Also committed is a some refactoring of ps backend but the change
should be quite transparent.
I like it. Out of curiosity, is there anything that this approach
brings (other than simplicity) that isn't already covered by the
support for:
matplotlib.use('module:://')
?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar issue
On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: Adding a set_ticks method seems reasonable. A patch is attached. It does some refactoring and introduces three new methods, set_ticks, set_ticklabels and update_ticks, on the colorbar class. So, now one can do imshow(np.arange(100).reshape((10,10))) cb = colorbar() cb.set_ticks([0, 40, 80]) Issuing a warning when user try to call Axis.set_ticks (or others) directly seems not straight forward as the axes can be created externally (i.e., when *cax* is provided). I'll wait for response for a few more days and will commit the change. Regards, -JJ colorbar.diff Description: Binary data -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] colorbar issue
John and others developers, I think the current colorbar implementation has some (minor) issue related with how ticks are treated. Here is a quick example, imshow(np.arange(100).reshape((10,10))) cb = colorbar() This gives you a nice colorbar, However, an issue arises when you want to change the ticks. cax = cb.ax cax.set_yticks([0, 40, 80]) And the colorbar got messed up. Changing ticks and ticklabels after the colobar is created is quite tricky. And, the easiest solution is to set those when creating the colorbar. As far as I can see, the real confusion comes fromthe fact that, in the current colorbar implementation, the data coordinate of the colorbar axes has nothing to do with the actual color scale. In the above example, while the color scale ranges from 0 to 99, the data coordinate (ylim) is still from 0 to 1. A few months back, I worked on a revised implementation of the colorbar, and that version of colorbar is currently included in the axes_grid toolkit. It is backward-compatible, but it uses axes_locator feature that I'm a bit reluctant to push into the mainline matplotlib. So, here is a few possible resolutions I consider. 1) leave it as is. but issue a warning when a users calls set_yticks (or its relatives) on the colobar axes. 2) use the reimplemented version of the colorbar, but drop the axes_locator part. The colorbar will be fully functional except the extend feature (triangles at the ends of the colorbar. see http://matplotlib.sourceforge.net/examples/api/colorbar_only.html). 3) use the reimplemented version of the colorbar. 4) someone else comes up with a better implementation. I don't think there is an immediate need for any changes as I see it as a minor issue. I'm just posting this as there has been a few recent questions regarding the colorbar behavior in the user list. Any suggestion and/or comments? Regards, -JJ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar issue
How do you get around this while supporting both the proportional and the non-proportional modes? I must confess that I never considered that option. And, no, my current implementation does not support non-proportional mode. So, I guess syncing the data coordinate with ticks has its own problem. 1) leave it as is. but issue a warning when a users calls set_yticks (or its relatives) on the colobar axes. Based on a quick look, I think that with some refactoring, we could add a set_ticks method. In a way, the question here is whether the colorbar should be thought of as a conventional axes object, or whether it is OK for it to have its own API. I think the latter is more natural, because it is a specialized object; once its orientation is established, there is only one set of ticks and one axis label. Ideally, cbar.ax would be an Axes object stripped down to its essentials; but that would involve major mpl refactoring. Intercepting calls to set_yticks and set_xticks and replacing them with warnings to use a new set_ticks would be good. Adding a set_ticks method seems reasonable. 2) use the reimplemented version of the colorbar, but drop the axes_locator part. The colorbar will be fully functional except the extend feature (triangles at the ends of the colorbar. see http://matplotlib.sourceforge.net/examples/api/colorbar_only.html). This is not acceptable. The extend feature is essential. I see. 3) use the reimplemented version of the colorbar. 4) someone else comes up with a better implementation. Regarding 3 or 4, if you or anyone else can come up with a better implementation, preserving at least the present functionality, that's great. The present implementation was a pain to develop and is hard to understand and maintain. As a person who never uses extend and non-proportional mode, I'm afraid that I do not have much motivation for now. But, it would be great if someone can come up with a better implementation! Regards, -JJ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pgfplots (TikZ) backend: implementation strategy
On Tue, Jan 12, 2010 at 5:14 PM, Nico Schlömer nico.schloe...@gmail.com wrote: I attached a PDF with two figures, one PDF generated and one TikZ (generated using my little script). There's clearly a difference in how seamless the two figures embed into the document, but I might not be using the PDF backend appropriately. Any hints on how I could get the fonts in place to allow for a fairer comparison? Matplotlib determines the font properties when the output file is created. But, TikZ (at least the way how your translator works) lets those information determined when latex is run. No doubt that TikZ result is much better than the matplotlib backends, but that is because TikZ and maplotlib works differently. While TikZ results looks better, this will greatly limit the functionality of matplotlib. And I'm afraid that your translator will not do much more than converting very simple plots. Anyhow, good luck with your project! Regards, -JJ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc build problem with axes_grid
The error happens because of the *.rst files under doc/examples that are not in sync with examples/*.py. Removing that directory (doc/examples) will solve the problem (the directory will be repopulated when you run make.py again). Here is a related link. http://old.nabble.com/python-make.py-html-failure-tt26894350.html Maybe we need something like python make.py clean? Regards, -JJ On Fri, Jan 1, 2010 at 11:09 PM, Eric Firing efir...@hawaii.edu wrote: I wanted to make a small fix to the contour docstring, and test it before committing, so I tried building the docs from scratch. It fails with the last part of the traceback being: File /usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py, line 414, in plot_directive options, state_machine) File /usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py, line 337, in _plot_directive shutil.copyfile(plot_path, os.path.join(destdir, fname)) File /usr/lib/python2.6/shutil.py, line 52, in copyfile fsrc = open(src, 'rb') IOError: [Errno 2] No such file or directory: u'/home/efiring/programs/py/mpl/mpl_trunk/doc/mpl_examples/axes_grid/demo_fixed_size_axes.py' /usr/lib/python2.6/shutil.py(52)copyfile() - fsrc = open(src, 'rb') I suspect the problem is that doc/examples/axes_grid has many .rst files for .py scripts that are no longer present, at least on my svn checkout. I have a demo_fixed_size_axes.pyc sitting around, but no corresponding .py, again indicating that the .py was removed from svn. Is there some step I am missing, or is there a need to remove from the svn tree those .rst files that lack corresponding .py? Eric -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling in the ps backend.
I change the api to support an arbitrary affine transform. The current api is def draw_image(self, gc, x, y, im, dx=None, dy=None, transform=None): dx, dy is the width and height of the image, i.e., The 4 edge points of the image will be (x, y), (x+dx, y), (x+dx, y+dy), (x, y+dy) after transformed by *transform*. And if transform involves rotation or skew, the image should also be rotated and skewed. Attached is a small example to utilized this functionality. Note that it only works with the ps-backend. I personally don't have much use case for rotated or skewed images. So, it would be great if others can suggest some user-space api. What I have in my mind is to extend the extent keyword of the imshow and make it optionally take a tuple of 6 numbers, which are (x1, x_lrc, x2, y1, y_lrc, y2). x1, x2, y1, y2 are same as the original extent, and the (x_lrc, y_lrc) represent the coordinate of the lower-right corner of the image. So, the imshow in the attached example will become somthing like im = plt.imshow(Z, interpolation='nearest', cmap=cm.jet, origin='lower', extent=[-2, 3, 4, -3, -2, 2]) And, the transformation will be calculated internally by the Image class. Any thought? -JJ On Wed, Dec 16, 2009 at 3:41 PM, Andrew Straw straw...@astraw.com wrote: Jae-Joon Lee wrote: On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen j...@iki.fi wrote: While the backend API is being changed, would it be similarly easy to support arbitrary affine transformations? It would make the API more symmetric, since many other draw_* methods take an affine transformation, and I guess at least the PS and PDF backends could easily support this. Yes, supporting arbitrary affine transform would not be difficult. On the other hand, I'm not sure if that feature is practically useful, assuming that other rasterizing backend won't implement it. I'll think about it. I second the notion that affine transformations on images would be useful. There are a lot of things one can do with this, such as make pseudo-perspective projections of texture-mapped rectangles. This is exactly one of the things that I routinely do in Inkscape. I'm reasonably sure Cairo supports arbitrary affine transformations when drawing image data -- I don't know about Agg. -Andrew #!/usr/bin/env python import numpy as np import matplotlib.cm as cm import matplotlib.mlab as mlab import matplotlib.pyplot as plt import matplotlib.transforms as mtransforms delta = 0.25 x = y = np.arange(-3.0, 3.0, delta) X, Y = np.meshgrid(x, y) Z1 = mlab.bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0) Z2 = mlab.bivariate_normal(X, Y, 1.5, 0.5, 1, 1) Z = Z2-Z1 # difference of Gaussians im = plt.imshow(Z, interpolation='nearest', cmap=cm.jet, origin='lower', extent=[-2, 4, -3, 2]) #plt.savefig(test.eps) def get_rotate_and_skew_transform(im, x3, y3): x1, x2, y1, y2 = im.get_extent() tr1 = mtransforms.Affine2D() tr1.translate(-x1, -y1) x2a, y2a = tr1.transform_point((x2, y2)) x3a, y3a = tr1.transform_point((x3, y3)) inv_mat = 1./(x2a*y3a-y2a*x3a) * np.mat([[y3a, -y2a],[-x3a, x2a]]) a, b = (inv_mat * np.mat([[x2a], [x2a]])).flat c, d = (inv_mat * np.mat([[y2a], [0]])).flat tr2 = mtransforms.Affine2D.from_values(a, c, b, d, 0, 0) tr = (tr1 + tr2 + mtransforms.Affine2D().translate(x1, y1)).inverted().get_affine() return tr x1, x2, y1, y2 = im.get_extent() x3, y3 = 3, -2 tr = get_rotate_and_skew_transform(im, x3, y3) # anchor points in circle plt.plot([x1, x2, x3], [y1, y2, y3], o) # original extent in black plt.plot([x1, x2, x2, x1, x1], [y1, y1, y2, y2, y1], k-) trans2 = tr + plt.gca().transData.get_affine() im.set_transform(trans2) # transformed extent in red plt.plot([x1, x2, x2, x1, x1], [y1, y1, y2, y2, y1], r-, transform=trans2) plt.savefig(a.eps) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling in the ps backend.
On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw straw...@astraw.com wrote: It's not clear to me if this proposal lets one specify any arbitrary affine transformation. Does it? I believe it does. 3 coordinates will define 6 equations where we have 6 unknowns of the affine matrix. The question is how user want to specify the transform. The extended extent keyword would be useful for the cases like the pseudo-perspective projection that you mentioned. But, it will not be very convenient for the cases like simple rotation. In general -- very nice. Thanks. In specific, I think the way you have already implemented things is sufficient. I think if a user can write a little helper function (as in your demo) to avoid a dumbed-down API being part of MPL, that would be best. Anyone specifying their own affine transform is probably going to want a pretty precise level of control, anyway. (Of course if your extent keyword proposal is already a general purpose API, then please ignore this comment.) I, personally, don't like the idea that user needs to define his/her own transform to rotate/skew the image. Rotation and skew seems more like properties of the image, rather than the transform. Anyhow, unless others step in, I may leave it as is (partially because I don't have much use case for rotated/skewed images for now). And, I hope someone implement similar affine transform for other backends. For the backends that requires resampling (agg, etc.), it might be better if the affine transform is taken care during the resampling (i.e., in the Image.draw method) rather than to be delegated to the backends. Regards, -JJ -Andrew -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling in the ps backend.
On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen j...@iki.fi wrote: Jae-Joon Lee lee.j.j...@gmail.com writes: While extending this to other backend such as pdf and svg should be straight forward, I want to hear how others think about the overall approach, e.g., api change and such. The current approach is to minimize change in backends. While the backend API is being changed, would it be similarly easy to support arbitrary affine transformations? It would make the API more symmetric, since many other draw_* methods take an affine transformation, and I guess at least the PS and PDF backends could easily support this. Yes, supporting arbitrary affine transform would not be difficult. On the other hand, I'm not sure if that feature is practically useful, assuming that other rasterizing backend won't implement it. I'll think about it. * If there are multiple images (and the ps backend is used), the images are resampled as they are compositted into a single image. The Figure.draw method already has some logic for not compositing multiple images: if len(self.images)=1 or not_composite or \ not allequal([im.origin for im in self.images]): I suppose this could also include a check for whether all images have the same transformation. Anyway, I'm not quite sure what the win from compositing is for a vector backend. One benefit of compositing would be an indirect support of alpha compositing in the ps backend, although it is not clear this is practically useful. Checking whether compositing is required seems not very straight forward to me. We may try to sort out images that needs to be composited and those does not. Anyhow, I am personally happy with the current behavior so I may leave it as is, and let others take it if they want. * The current solution forces not to resample whenever interpolation==nearest, I think this is generally good behavior. However, on the highly extreme case of very high resolution of image (e.g., image dpi 1000 ?), it might be better if the image is resampled (i.e., downsampled). This sounds like it would make sense for naive users but could get very annoying for somebody who really does want high resolution (e.g. for zooming in in a viewer application). What I meant was the case when the dpi of the image painted on the canvas is much higher than the dpi of the canvas itself (I mean the dpi of the typical postscript output device). Anyhow, I guess the current behavior is good enough, and it seems more reasonable to let users do the down-sampling explicitly if they want. Regards, -JJ -- Jouni K. Seppänen http://www.iki.fi/jks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] imshow without resampling in the ps backend.
A patch that enables drawing image in ps backend without resampling is committed in r8035. So, please test it if you're interested. The raw image is to be used only when interpolation==nearest and there is only one image. While extending this to other backend such as pdf and svg should be straight forward, I want to hear how others think about the overall approach, e.g., api change and such. The current approach is to minimize change in backends. There are a few minor issues, whose solution is not clear to me. * If there are multiple images (and the ps backend is used), the images are resampled as they are compositted into a single image. * The current solution forces not to resample whenever interpolation==nearest, I think this is generally good behavior. However, on the highly extreme case of very high resolution of image (e.g., image dpi 1000 ?), it might be better if the image is resampled (i.e., downsampled). One option would be to introduce a new resample keyword in the imshow command (which will become the attribute of the images). Regards, -JJ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Z-Order Sorting
The recent zorder-related changes broke the some of the rasterization feature, and I just committed a fix. In doing so, I replaced dsu.sort(key=lambda x: x[0]) to dsu.sort(key=itemgetter(0)) which I think is slightly faster (although speed is not much of concern here). Regards, -JJ On Tue, Dec 1, 2009 at 11:17 PM, Eric Firing efir...@hawaii.edu wrote: John Hunter wrote: On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing efir...@hawaii.edu wrote: This is easy to fix by using the key kwarg (added in python 2.4) of the sort method, because python uses a stable sort. It looks like it only needs to be fixed in Axes.draw, because Figure.draw has never paid any attention to zorder anyway. I'll do it now. It does now in svn HEAD -- I just added this yesterday. Yes, I saw that after I sent the first message, so I stabilized the sort in Figure.draw also. Eric -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Wed, Nov 11, 2009 at 7:12 PM, Andrew Straw straw...@astraw.com wrote: I had a patch waiting in the wings for that, but I wanted to see the dust settle before committing it. I think the dust is officially settled, so please commit yours or else I'll commit mine. Please go ahead. By the way, I just encountered some zorder issue with the new patch. The thing is, zorder=1 for Images seems to high. For example, patches also have zorders=1. So, if I draw an image, and add some patches (which I often do to indicate regions of interests), the patches are drawn before images and become invisible. This happens because images are appended to dsu list after all other artists. Reducing the zorder of images would be a one option. Or we may add images to the dsu list before all other artists, which seems sensible to me. Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Thu, Nov 12, 2009 at 3:45 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: By the way, I just encountered some zorder issue with the new patch. The thing is, zorder=1 for Images seems to high. For example, patches also have zorders=1. So, if I draw an image, and add some patches (which I often do to indicate regions of interests), the patches are drawn before images and become invisible. This happens because images are appended to dsu list after all other artists. The other thing I noticed by quickly going through axes.py is that when _axisbelow==True, the zorders of xaxis and yaxis is set to 0.5, which is lower than images. While the doc say *axisbelow*draw the grids and ticks below the other artists I don't think one wants to draw axis (grid+ticks) even below images. Well, there should be a few ways to fix this, but how others think about reducing the Image's zorder to 0? Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
I also committed a small patch that makes zorders respected among images (not with other artists) for noncomposit backends. Anyhow, can we get rid of the second items in the dsu list? My guess is that this is to make the sort stable, but python sort is already stable, isn't it? -JJ On Tue, Nov 10, 2009 at 4:06 PM, Andrew Straw straw...@astraw.com wrote: Andrew Straw wrote: John Hunter wrote: On Mon, Nov 9, 2009 at 10:21 AM, Andrew Straw straw...@astraw.com wrote: Hi All, I have addressed what I think is a long-standing wart: zorder is mostly ignored for imshow(). (See e.g. http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314 ) The question is whether I should apply the attached patch. I went ahead and committed this patch to the trunk in r7950. Here's the CHANGELOG entry: 2009-11-10 Single images, and all images in renderers with option_image_nocomposite (i.e. agg, macosx and the svg backend when rcParams['svg.image_noscale'] is True), are now drawn respecting the zorder relative to other artists. (Note that there may now be inconsistencies across backends when more than one image is drawn at varying zorders, but this change introduces correct behavior for the backends in which it's easy to do so.) Jae Joon raised a couple of concerns: 1) the patch would introduces inconsistent behavior between backends -- namely that PS and other backends, when given more than one image, would composite (or rasterize) all images and stick them underneath everything else. Agg would have proper zordering between images and other artists. 2) there is doubt about the utility of such functionality. Jae-Joon says I think it is often sufficient if we draw images at the bottom but respect zorders among images. As for #1, it seems to me this is simply a bug/limitation with the compositing functionality (e.g. the PS backend). The SVG backend has the possibility to turn compositing on or off based on the svg.image_noscale rcParam, and perhaps other backends could grow something similar. I can't see why this patch -- that specifically solves the bug/limitation in the backends where its easily possible -- should be held back due to this. As for #2, perhaps my use case will be convincing -- I'm trying to draw reconstructions of various experimental setups, and the easiest way to do this is to create texture-mapped rectangles in which I can control the zorder -- a single texture may need to be over some artists but under others. Perhaps there's an easier way to achieve this, but I'm not aware of it. Jae Joon has also stated that he's OK with the patch, so I went ahead and committed it. In light of all this, please let me know if you still have concerns, and hopefully they can be addressed. In the worst case, we can back this patch out. -Andrew -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Mon, Nov 9, 2009 at 1:01 PM, John Hunter jdh2...@gmail.com wrote: Your patch is only applied when len(images)=1 or renderer.option_image_nocomposite(), both of which will be False when using Agg with multiple images, no? I believe renderer.option_image_nocomposite() is True for the agg backend. So, it will work with agg. -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Mon, Nov 9, 2009 at 12:44 PM, Eric Firing efir...@hawaii.edu wrote: PS backend already does things differently from others because it doesn't handle alpha, correct? Does the patch make this situation any worse? When there are multiple Images and render.option_image_nocomposite() is false (as in the ps backend ), the images are composited (rasterized) into a single image before it is passed to the backend. So, AS FAR AS the images are concerned, I think the ps backend does handle alpha correctly and the results are consistent between backends. And with the Andrew's patch, and if there are non-image artists between two images, the results can be different. For example, those non-image artists can be obscured by the foreground image in the agg backend, but will always show up in the ps backend. So, I think this is somewhat different issue than alpha being ignored in the ps backend. Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow zorder (patch for review)
On Mon, Nov 9, 2009 at 3:55 PM, Andrew Straw straw...@astraw.com wrote: What's the motivation of the ps backend compositing (rasterizing to a single bitmap) multiple images? It seems it will, by design, preclude the use of non-image artists between two images. I guess the motivation is to reduce output file size. Maybe Axes.draw() should disable compositing in the scenario where a non-image artist is sandwiched by image artists and suffer the increased file size. I can't say about what the original intention was, but I guess one of the benefit is that you can have alpha compositing of multiple images. I personally think that no alpha support for images is a more serious issue than no alpha support for other artists like lines and patches. So, I'm +1 for doing the alpha compositing of images before passing it to the backends (that do not support the alpha compositing). However, as I said in my first email, I don't think there are much cases that this actually matters, while I'm also not sure about the benefit of having images above other artists like lines. Anyhow, as far as zorders between images are respected (in all backends!), it should be good. Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Incorrect output from demo_text_path.py on mac
It seems that this could be bug in textpath.py that picks up wrong
glyph. Unfortunately, I cannot spend much time on this until the end
of this week.
As a matter of fact, I'm far from an expert on this issue. While I
wrote the textpaht.py, the code is largely based on the code in the
pdf_backend and svg_backend. So, I hope someone who is more
knowledgeable than me step in.
On the other hand, it seems that some glyph-name related bug has
recently fixed in the amsfont. And, this might be related to the
current issue.
http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README
I'm not sure what version of amsfont you're using but, can you try to
update them to newest 3.0.2 version? And see if that makes any change?
I'll try to look into this later this week.
Regards,
-JJ
On Tue, Nov 3, 2009 at 10:26 PM, tcb thecolourblu...@gmail.com wrote:
hi,
i took a quick look at what is going on here- but I have still not quite
found the problem. From tracing things back into the ft2font code, it seems
that the wrong glyph index is getting passed in or used somewhere. I put
this debugging code into ft2font.cpp in FT2Font::load_glyph
#define MAX_LEN 1024
unsigned char bf[MAX_LEN];
FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);
std::cout FT2Font::load_glyph __FILE__ : __LINE__
glyph_index
num
face-family_name
face-style_name
FT_Get_Postscript_Name(face)
[ bf ]
std::endl;
I modified your example demo_text_path2.py to just load the single symbol
'\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' - and
the output I get is this from the command line:
FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium CMMI12
[ xi ]
so, it seems to pick the correct font but the wrong glyph name (xi instead
of pi)- I am not sure what the index should be. What gets displayed is the
'\xi' symbol- you can see from the first output I sent that '\pi' has been
replaced by '\xi' - the indexes of all the symbols are just offset by one, I
think.
If the correct glyph index is being passed to ft2font, then it could very
well be a problem with freetype.
regards
On Tue, Nov 3, 2009 at 6:19 PM, tcb thecolourblu...@gmail.com wrote:
Hi,
Yes, with the pdfbackend, and using just the plain text code (with
usetex=True), the correct output is produced (for Text but not TextPath). I
modified your demo_text_path2.py to draw with text, and attached the output.
This is the terminal output from running your attached code. I am using
the texlive 2009 distribution- which appears to be working fine, I have not
noticed any problems at all. What is the difference between the bluesky and
amsfonts?
texname, type1name, enc, char_id
cmex10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
None CMEX10-34
cmsy10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
None CMSY10-49
cmex10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
None CMEX10-88
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb
None CMMI12-110
cmr17
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMR17-61
cmr17
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMR17-49
cmsy10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMSY10-0
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-101
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-105
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-25
cmr17
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMR17-50
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-110
cmex10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMEX10-35
phvr8r
/usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb
/usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc
Nimbus%20Sans%20L%20Regular-2
regards,
On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote:
On Tue, Nov 3, 2009 at 4:23 AM, tcb thecolourblu...@gmail.com wrote:
and if I convert the dvi with dvipng, it all seems in order
(demo_text_path_tex.png). I haven't looked closely into how the
textpath
stuff works, but I thought it would read the dvi as a path, and display
that
on the screen- if that is correct then I dont know how it ends up
displaying
a different symbol from what is in the dvi file.
Well, dvi files only contains the name of the tex font. What textpath
does is to pick up corresponding type I font and convert them to path
using the freetype library (as far as I know, this is what dvipng
Re: [matplotlib-devel] Incorrect output from demo_text_path.py on mac
On Tue, Nov 3, 2009 at 4:23 AM, tcb thecolourblu...@gmail.com wrote: and if I convert the dvi with dvipng, it all seems in order (demo_text_path_tex.png). I haven't looked closely into how the textpath stuff works, but I thought it would read the dvi as a path, and display that on the screen- if that is correct then I dont know how it ends up displaying a different symbol from what is in the dvi file. Well, dvi files only contains the name of the tex font. What textpath does is to pick up corresponding type I font and convert them to path using the freetype library (as far as I know, this is what dvipng and matplotlib pdf backend does). So, my guess is that, textpath is somehow picking up wrong fonts, or wrong glyphs. The code works fine at least in my mac os X tiger w/ texlive 2008, and in ubuntu with texlive 2007. As I don't have any access to mac os X 10.6, it would be hard to track down what is wrong. Here are a few more test I wish you to run. *) Check if pdf backend produces a correct result. Do not use textpath example, but simply use text command with usetex=True, and see if the pdf output is okay. FWIW, the textpath code is largely borrowed from the pdfbackend. *) Run the attached code, and post the terminal output. The output is basically the name of the tex font and the name of the substituted type1 font, etc. For your reference, here is my output. texname, type1name, enc, char_id cmex10 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb None CMEX10-34 cmsy10 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb None CMSY10-49 cmex10 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb None CMEX10-88 cmmi12 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb None CMMI12-110 cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMR17-61 cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMR17-49 cmsy10 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMSY10-0 cmmi12 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMMI12-101 cmmi12 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMMI12-105 cmmi12 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMMI12-25 cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMR17-50 cmmi12 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMMI12-110 cmex10 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb None CMEX10-35 pncr8r /usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb /usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc Century%20Schoolbook%20L%20Roman-232 Regards, -JJ demo_text_path2.py Description: Binary data -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Layout of subplots in output
I now think this is not the dpi issue. Can you check the size of your figure in mac os X backend, after the plot is drawn? print f.get_size_inches() 8x6 inch is the default. With dpi setting of 300 and bigger, the figure size (in pixel) will be likely larger than your monitor size. And it seems that in mac os X backend, the figure gets shrunken to fit the display, effectively reducing the figuresize. So, my recommendation is to use smaller dpi for screen display (default is something like 80), and increase the dpi when saving the figure (savefig has a dpi parameter). Regards, -JJ 2009/11/2 Stéfan van der Walt ste...@sun.ac.za: Hi JJ this bug has been fixed in the svn. Unfortunately, I still see the same behaviour using the latest version from SVN. As noted earlier, I work around the issue now by switching to the pdf backend. Regards Stéfan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Incorrect output from demo_text_path.py on mac
Thanks for the report. And I wonder if you can provide us some more details of your configuration and do some more tests. 1) You're not using usetex mode, correct? 2) Does your mathtext work fine otherwise? I mean, with the ordinary text command, not the textpath example. Regards, -JJ On Mon, Nov 2, 2009 at 2:45 PM, tcb thecolourblu...@gmail.com wrote: Hi, I am running the svn version of matplotlib on a mac (OSX 10.6 with latest macports), and there is a problem with the output from demo_text_path.py. It does give the correct output on linux, so I assume the problem is either with the installed fonts on the mac, or with the mathtext code (in particular the tables in _mathtext_data.py). From the output, you can see that the text is correct in the upper subplot, but in the lower one, where is uses mathematical symbols, it is garbled. I get the same output for different backends (I have checked with macosx, GTKAgg and pdf). If I can help to figure out the problem, please let me know, regards, tcb -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Layout of subplots in output
Stefan, Can you try to install matplotlib again, after removing old ones. The mac os X had a bug that does take care of the dpi. But I guess this bug has been fixed in the svn. http://old.nabble.com/Re%3A-Font-size-and-savefig-p23337463.html -JJ 2009/11/1 Stéfan van der Walt ste...@sun.ac.za: Hi John 2009/11/1 John Hunter jdh2...@gmail.com: To avoid the overlap on the titles and ticks, you will want to play with the font size of the ticks and title, but most importantly the subplots_adjust parameters hspace and wspace. If using a suptitle, you may also want to adjust top. Thanks for the advice, I'll play around with those parameters. I was surprised that this works fine under Linux, so I tried switching to the PDF backend on OSX, and now everything renders perfectly. Could it be that the MacOSX backend does something strange? Regards Stéfan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl_toolkit.axes_grid default axes class should be changed?
Thanks for your suggestion and the patch.
However, I'm not very inclined to make such a change any time soon,
since that custom axes class is one of my primary motivation
(supporting the cuvelinear grid) behind the axes_grid toolkit. And
other part of axes_grid toolkit depends on this behavior.
On the other hand, I'm trying to make some reorganization effort of
the axes_grid toolkit in the future, during which I will try to
separate out things that depends on the custom axes.
FYI, note that you can turn off the customized behavior by
ax.toggle_axisline(False)
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axisline
This should bring back the original behavior of the matplotlib axes
(if it does not, it should be considered a bug). Of course this will
disable some of the functionality of the axes_grid.
I'm thinking about issuing a warning (about the different behavior
from the original matplotlib) whenever axes_grid is imported
(optinally turned off using rcparams). This may help others not to
wast their time when something does not work.
Regards,
-JJ
On Tue, Oct 27, 2009 at 1:53 PM, Pauli Virtanen pav...@iki.fi wrote:
Hi,
mpl_toolkit.axes_grid.AxesGrid uses a custom axes type as the default
type of axes it creates. I think it might be more user-friendly to use
matplotlib.axes.Axes as the default -- the functionality in basic use
seems to be the same.
The custom axes handle drawing ticks quite differently from matplotlib's
usual Axes. I just spent an hour wondering why
grid[0].xaxis.get_major_ticks()[-1].label.set_horizontalalignment(right)
had no effect -- the answer is that LocatableAxis draws ticks using a
custom tick artist, and that the correct axis object is in
grid[0].axes[bottom]. And in fact, it cannot adjust the align of
individual tick labels.
The AxesGrid is really useful, so I'd suggest the following change:
--- lib/mpl_toolkits/axes_grid/axes_grid.py.orig 2009-10-27
19:51:43.0 +0200
+++ lib/mpl_toolkits/axes_grid/axes_grid.py 2009-10-27 19:52:13.0
+0200
@@ -210,10 +210,10 @@
if axes_class is None:
- axes_class = LocatableAxes
+ axes_class = maxes.Axes
axes_class_args = {}
else:
- if isinstance(axes_class, maxes.Axes):
+ if issubclass(axes_class, maxes.Axes):
axes_class_args = {}
else:
axes_class, axes_class_args = axes_class
--
Pauli Virtanen
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] alpha/transparency now failing in scatter (after upgrade to Ubuntu 9.10)
On Mon, Oct 26, 2009 at 2:35 AM, boo.da...@csiro.au wrote: Also (a different problem), I get an error message (when adding a legend, that no labels were defined). This is also changed behaviour since the upgrade. Seems like scatter has changed... but why? This is a known bug. http://www.nabble.com/No-legend-using-scatter-function-td24816047.html#a24816047 This is fixed in the svn, and I guess 0.99.1.1 shipped with this fixed. If you don't want to upgrade, use the workaround in the above post. Regards, -JJ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] default q shortcut?
Can you post your patch so that others can review? Regards, -JJ On Wed, Oct 21, 2009 at 3:23 AM, Georg Brandl g.bra...@gmx.net wrote: Hi, one thing I missed when I switched from Gnuplot to matplotlib was that I can't press q to close a window but have to use the window manager; in one environment I work in that means I have to use the mouse to close a window. I made a custom key handler that does the following: try: event.canvas.manager.destroy() except AttributeError: pass which seems to work, at least with GtkAgg (I didn't venture to find out why the AttributeError is raised, it works in spite of that). Would it make sense to have that shortcut by default (and working for all windowing backends)? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] patheffect
Hi all, Last night, I committed a patch to support what I'm calling a patheffect. You may think of it as a customization of the Renderer.draw_path method. I added an example patheffect_demo.py and its output is attached. Actually, this is nothing new, and mpl already can do these kind of thing. What I wanted with the patheffects feature is to make it more easy (especially with Text). And something like below is what I came up with. txt = ax1.annotate(test, (1., 1.)), (0., 0), txt.set_path_effects([PathEffects.withStroke(linewidth=3, foreground=w)]) I'm not quite sure if the current API is optimal and I'll appreciate any API suggestions. Regards, -JJ attachment: patheffect_demo.png-- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Text.get_prop_tup omits _rotation_mode
Thanks.
I can reproduce the bug and the patch looks good.
The patch is applied to the maint. branch and the svn head.
Regards,
-JJ
On Thu, Oct 15, 2009 at 4:30 PM, Stan West stan.w...@nrl.navy.mil wrote:
Developers:
I happened upon a small bug in which changing the rotation mode of text does
not take effect until another property is changed:
t = plt.text(0.5, 0.5, 'Lorem ipsum', rotation=-45)
# rotation_mode defaults to None
t.set_rotation_mode('anchor')
plt.draw() # the new rotation mode doesn't take effect
t.set_rotation(-44)
plt.draw() # now the angle and rotation mode are updated
This seems to be corrected by adding _rotation_mode to the properties
handled by get_prop_tup; I've attached a patch for your review.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] added PathPatch3D in mplot3d.art3d
Reinier and others, I just added a PathPatch3D class in mplot3d.art3d. It is a slight variation of Patch3D that respect the codes the bezier curve (I believe Patch3D does not). An example is also added as pathpatch3d_demo.py, with a screenshot below. http://dl.getdropbox.com/u/178748/mpl/pathpatch3d_demo.png It will be appreciated if Reinier of others review the code (the patch is quite small). My original intention was to have an option for the labels (including ticklabels) look as if they are in the particular plane of axes (as partly demonstrated in my example). But I won't be able to work on it soon. Regards, -JJ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] draw_text and draw_tex w/ textpath
Hi, The backend_base in the trunk now has the draw_text_as_path method which draws the text using the textpath module. The draw_text and the draw_tex method calls it by default. This will enable a primitive support for text and tex for all the backend which implements draw_path method. This should not affect the functionality of existing backends. The draw_text_as_path in the backend_base is a very basic implementation. It simply calls draw_path for rendering. A special version of the draw_tex method for the svg backend is implemented, which caches the glyph paths of characters to reduces the output size. So, here are examples. usetex w/ svg backend : http://dl.getdropbox.com/u/178748/mpl/tex_demo.svg text with html5 canvas backend : http://dl.getdropbox.com/u/178748/mpl/test.html Well, the quality of the rendered text is not best, but seems good enough for me. Regards, -JJ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-buildbot] buildbot failure in matplotlib on Ubuntu 8.04, Python 2.4, amd64
On Fri, Sep 4, 2009 at 4:06 PM, John Hunterjdh2...@gmail.com wrote: On Fri, Sep 4, 2009 at 2:54 PM, Andrew Strawstraw...@astraw.com wrote: Should I remove dvipng from the buildslaves to check for this kind of thing in the future, or should I keep it installed so we can test functionality that uses it? I think we should have at least one build slave with dvipng and one w/o. This is a real bug that the buildbot caught since we do not require dvipng for a normal mpl install. Yes, this should be my fault. I didn't expect that importing a texmager would raise an exception. I'll fix it soon. Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-buildbot] buildbot failure in matplotlib on Ubuntu 8.04, Python 2.4, amd64
On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Leelee.j.j...@gmail.com wrote: Yes, this should be my fault. I didn't expect that importing a texmager would raise an exception. I'll fix it soon. I just committed a changeset that I think would fix this (the textpath.py imports texmanager only when required). But I couldn't test it as I don't have a machine w/o dvipng at this time. Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Canvas HTML5 backend
On Tue, Sep 1, 2009 at 12:57 PM, Michael Thompsonmichae...@gmail.com wrote: 2009/9/1 John Hunter jdh2...@gmail.com: On Tue, Sep 1, 2009 at 10:32 AM, Michael Thompsonmichae...@gmail.com wrote: Hi, I'm trying to work on the canvas javascript backend I found here [1]. I'm trying to add text but the canvas origin is at the top left, how can I transform the co-ordinates from the matplotlib to canvas? def draw_text(self, gc, x, y, s, prop, angle, ismath=False): ctx = self.ctx ctx.font = 12px Times New Roman; ctx.fillStyle = Black; ctx.fillText(%r % s, x, y) [1] http://bitbucket.org/sanxiyn/matplotlib-canvas/src/80e9abf6d251/backend_canvas.py The backend canvas should know its height, so height-y should transform from bottom to top Thanks, turns out to be a problem setting the size of the canvas element that the javascript is rendered into. If self.flipy is set then the text.py takes care of subtracting y from the height. Next problem is the text alignment, look OK on the right axis but wrong on the left I presume it's the alignment. The documentation says that s should be a matplotlib.text.Text instance and I can use s.get_horizontalalignment() but it seems that s is a unicode string. How can I find the alignment I should set on the text? Michael My understanding is that all the backends should use left-bottom alignment. Text alignment in matplotlib is handled by mpl itself (not by the backend), and for this to work, you have to define get_text_width_height_descent method correctly. The real question is how we know the metric of the font that will be used for rendering. I have little knowledge about the html canvas specification, but I presume that the situation is very similar to the svg case. Unless we embed the fonts (the svg backend has an option to embed the fonts as paths), I don't think it is possible to get it right. Again, I have little knowledge about html5 canvas thing, and I hope any expert out ther clarify this issue. -JJ ps. gnuplot seems to use embedded fonts for their html5 canvas backend (I haven't checked carefully but their demo output uses canvastext.js, originally from http://jim.studt.net/canvastext/) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Canvas HTML5 backend
On Tue, Sep 1, 2009 at 6:03 PM, Michael Thompsonmichae...@gmail.com wrote: I see firefox 3.5 (html5) has a method to measure the width of the text, I'll look at using this in a javascript function to render the text. I'm not sure if this helps. *Matplotlib* (not the browser) needs to know the size of the text when it creates plots. And the issue is that matplotlib does not know, in general, what font the browser will pick up for rendering. It seems that people are using @font-face embedding which are supported by newer version of firefox and safari. So, one option would be to use @font-face to specify (and provide) the fonts that are used when the plot is created by matplotlib. The other option is to embed the texts as paths as done in the svg banckend. Of course, there always is a font license issue. -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A few new feature in svn : BboxImage, AnnotationBox, etc.
Hi, There are a few new features I have committed into the svn. Nothing significant, but hopefully useful (and fun to play with). Here is a quick summary with screenshots ( I made a separate page because it involves number of images). http://abitofpythonabitofastronomy.blogspot.com/2009/08/few-new-things-in-mpl-svn.html Give them a try when you have a chance. The api is still experimental and any suggestion will be welcomed. On the other hand, I needed to make some minor changes to the existing code. While I hope it does not break any, let me know if anything odd happens. Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problem with draw method in svn version?
On Tue, Aug 4, 2009 at 5:33 AM, Jonathan Demaeyerjonathan5...@hotmail.com wrote: Hello, Thank you for your answer. When I explicitly give None as renderer argument, everything work well. Now I guess the question is why the default value is not used by the method? The Axes.draw is the only the draw method that has a default value for renderer argument. Well, we'd better have a separate decoratorfor Axes.draw. By the way, rasterization support wasn't introduced earlier than the 0.98.3 version? Yes, the rasterization support was there for a while. I was talking about the support for rasterization per aritst by decorating the draw methods of individual artists. -JJ Regards, Jonathan Jae-Joon Lee a écrit : I guess this is related with the decorator introduced by rasterization support. While most of the artist seems to explicitly require the renderer instance as the second argument of the draw method, the draw method in the Axes class have default value of None. The easiest fix seems to let the decorator returns the method with renderer=None as in the Axes. By the way, Jonathan, I guess the easiest workaround for you is to modify your code so that it explicitly gives the renderer argument. As you see the default value for renderer is None. Just call it as draw(None). Regards, -JJ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] curvelinear coordinate support in axes_grid and a possible refactoring of mpl.
Hello, I recently committed a support for a curvelinear grid in the axes_grid toolkit. What it does for you is to draw a ticks and grid appropriate for a curvelinear coordinate system, as in the example below. http://matplotlib.sourceforge.net/_images/demo_floating_axis1.png The main motivation behind this work was to display astronomical images with matplotlib. However, I included this in the axes_grid toolkit hoping that this could be also useful in other fields. The reason I'm posting this email is related to a possible refactoring of the matplolib, that John once mentioned, to better support the ticks and spines. To support the curvelinear grid, I had to create a customized Axes class, and I believe that some of my effort overlaps with the refactoring that John mentioned. In the linked document below, I tried to describe the changes I made for this. http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/axislines.html I guess some of my idea or implementation may be considered to be a part of the refactoring (if it ever happens :) ). Or, at least, I hope that the issues I had with mpl's current Axes implementation are reflected in the refactoring efforts. Well, I just wanted to toss around some ideas and hear what others think. Regards, -JJ ps. Are we having a sprint during the scipy conference by the way? I may join remotely. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Should gc.set_alpha accept strings?
I committed the original example into the svn, and I admit that I was not careful with the code. I agree that the arguments should be float (the doc does say that set_alpha takes float). The example is now updated to use floats (svn r7300). Regards, -JJ On Mon, Jul 27, 2009 at 9:15 AM, Michiel de Hoonmjldeh...@yahoo.com wrote: Hi everybody, Should the set_alpha method of a graphics context accept a string (instead of a number) as an argument? Currently, some backends (agg, ps, pdf) accept strings such as 0.2, whereas others (svg, cairo, Mac OS X) do not. Usually that is not a problem, since in almost all cases set_alpha is called with a number as the argument. However, the example axes_zoom_effect.py, which was recently added to examples/pylab_examples, has these lines: prop_patches[alpha]=0.2 which causes a call to gc.set_alpha of the form gc.set_alpha(0.2). Backends that do not allow strings choke on that. Whereas in general it may perhaps be useful to allow such strings, it adds complexity to the code, and I don't see a good use case for it. --Michiel. -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
