[matplotlib-devel] glumpy, fast opengl visualization
Hello, This is an update about glumpy, a fast-OpenGL based numpy visualization. I modified the code such that the only dependencies are PyOpenGL and IPython (for interactive sessions). You will also need matplotlib and scipy for some demos. Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy No installation required, you can run all demos inplace. Homepage: http://code.google.com/p/glumpy/ Nicolas -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] missing projections
Phillip M. Feldman wrote: > Andrew Straw wrote: >> Jeff Whitaker wrote: >> >>> Dr. Phillip M. Feldman wrote: >>> Basemap offers many projections, but is missing two of the most useful ones: - For satellite applications, it would be helpful to have a "camera" projection, i.e., a projection that shows the Earth as viewed from a specified point in space. This would be a generalization of the current geostationary projection. >>> Philip: Don't think the proj4 lib supports this. >>> >> I think it's already in there -- see nsper, for near sided perspective. >> >> -Andrew >> >> > Hello Andrew- > > It does sound as thought nsper is exactly what I need, but when I try > to use it, I get the following error message: > > ValueError: 'nsper' is an unsupported projection. > The supported projections are: > > aeqd Azimuthal Equidistant > poly Polyconic > gnom Gnomonic > moll Mollweide > tmercTransverse Mercator > nplaea North-Polar Lambert Azimuthal > gall Gall Stereographic Cylindrical > mill Miller Cylindrical > merc Mercator > stereStereographic > npstere North-Polar Stereographic > geos Geostationary > vandgvan der Grinten > laea Lambert Azimuthal Equal Area > mbtfpq McBryde-Thomas Flat-Polar Quartic > sinu Sinusoidal > spstere South-Polar Stereographic > lcc Lambert Conformal > npaeqd North-Polar Azimuthal Equidistant > eqdc Equidistant Conic > cyl Cylindrical Equidistant > omercOblique Mercator > aea Albers Equal Area > spaeqd South-Polar Azimuthal Equidistant > orthoOrthographic > cass Cassini-Soldner > splaea South-Polar Lambert Azimuthal > robinRobinson > > Phillip Philip: I think Andrew meant nsper is in proj4. I'll look into adding support for it in Basemap. -Jeff -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] with projection=aeqd, width has no effect
Dr. Phillip M. Feldman wrote: > When I generate a map with the aeqd projection, the width parameter has no > effect. This looks like a bug. > Philip: I don't see this. Here's an example, does this fail for you? lon_0=-105; lat_0=40 width=4000.e3 height=4000.e3 m =\ Basemap(resolution='c',projection='aeqd',lat_0=lat_0,lon_0=lon_0,width=width,height=height) m.drawcoastlines(linewidth=0.5) m.fillcontinents() plt.show() -Jeff -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] with projection=aeqd, width has no effect
Jeff Whitaker wrote: > Dr. Phillip M. Feldman wrote: >> When I generate a map with the aeqd projection, the width parameter >> has no >> effect. This looks like a bug. >> > Philip: I don't see this. Here's an example, does this fail for you? > > lon_0=-105; lat_0=40 > width=4000.e3 > height=4000.e3 > m =\ > Basemap(resolution='c',projection='aeqd',lat_0=lat_0,lon_0=lon_0,width=width,height=height) > > > m.drawcoastlines(linewidth=0.5) > m.fillcontinents() > plt.show() > > > -Jeff > I specified width but not height. I'm not sure how the code should behave under those conditions, but in any case this was my fault. Thanks! Phillip -- 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 [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar issue
Jae-Joon Lee wrote: > 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. How do you get around this while supporting both the proportional and the non-proportional modes? > > 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. 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. > > 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. > > 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. Eric > > 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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hist() bug in log-scale with "stepfilled"
Olle Engdegård wrote: > Hi, > > Combining "stepfilled" with log scale sometimes gives inappropriate plots: > > a=[4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5] > hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True) > > The problem is not restricted to the case here with more bins than unique > elements, but sometimes reducing the bin number makes the issue go away. > > Cheers, > Olle > > > > -- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Thanks for the report. This is fixed now in r8097. mm -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] need a way to control color of labels
When labeling the lines of latitude and longitude on a map, it appears that there is currently no way to control the color of the labels. It would be great if a keyword could be added to enable this. http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html#mpl_toolkits.basemap.Basemap.drawparallels -- View this message in context: http://old.nabble.com/need-a-way-to-control-color-of-labels-tp27314724p27314724.html Sent from the matplotlib - devel mailing list archive at Nabble.com. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [IPython-dev] glumpy, fast opengl visualization
Hi Nicolas, On Mon, Jan 25, 2010 at 2:46 AM, Nicolas Rougier wrote: > > > Hello, > > This is an update about glumpy, a fast-OpenGL based numpy visualization. > I modified the code such that the only dependencies are PyOpenGL and > IPython (for interactive sessions). You will also need matplotlib and > scipy for some demos. > > Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy > No installation required, you can run all demos inplace. > > Homepage: http://code.google.com/p/glumpy/ This is great, and it would be very cool to have it updated to the new code we're now landing in ipython with a much cleaner internal API (finally :) Have you had a chance to look at the code in my trunk-dev branch? https://code.launchpad.net/~fdo.perez/ipython/trunk-dev Brian finished a large review of it and we just had a chance to go over his feedback directly, so there's now one more round of reviews to do (once he applies the changes from our discussion) and this should become trunk very soon. The apis are much cleaner, this is the big cleanup I told you about last year, and now we're getting to the point where having multiple ipython frontends is a very realistic prospect. Unfortunately we won't be able to use your code directly in IPython as it stands, since the GPL provisions in it would require us to GPL all of IPython to make use of any of it directly in IPython. Your code uses iptyhon, numpy, matplotlib and scipy (in some demos), which amounts to hundreds of thousands of lines of code; here are the sloccount outputs from their respective trunks: IPython Totals grouped by language (dominant language first): python: 47357 (99.24%) lisp: 262 (0.55%) sh: 62 (0.13%) objc:37 (0.08%) Numpy Totals grouped by language (dominant language first): ansic: 152950 (67.19%) python: 73188 (32.15%) cpp:828 (0.36%) fortran:298 (0.13%) sh: 156 (0.07%) pascal: 120 (0.05%) f90: 97 (0.04%) Matplotlib Totals grouped by language (dominant language first): python: 83290 (52.64%) cpp: 68212 (43.11%) objc: 4517 (2.85%) ansic: 2149 (1.36%) sh: 69 (0.04%) Scipy Totals grouped by language (dominant language first): cpp: 220149 (48.35%) fortran: 87240 (19.16%) python: 79164 (17.38%) ansic:68746 (15.10%) sh: 61 (0.01%) Glumpy: Totals grouped by language (dominant language first): python:3751 (100.00%) We're looking at ~300.000 lines of python alone in these tools. It's unfortunately not realistic for us to consider GPL-ing them in order to incorporate glumpy into the core set; it would be fantastic if you were willing to consider licensing your code under a license that is compatible with the body of work you are building on top of. You are obviously free to choose your license as you see fit, and end users (myself included) will be always able to use glumpy along with ipython, numpy, matplotlib and scipy. So *users* get all of the benefit of your contribution, and for that I am the first to be delighted and grateful that you've put your code out there. But as it stands, your code builds on close to half a million lines of other code which can not benefit back from your contributions. If you consider licensing glumpy to be compatible with ipython, numpy and matplotlib, it would be possible to incorporate your ideas back into those projects: perhaps in some places the right solution would be to fix our own designs to better provide what glumpy needs, in other cases we may find fixes you've made fit better upstream, etc. But this kind of collaboration will not be possible as long as glumpy can benefit from our tools but our codes are not allowed to benefit from glumpy (without changing licenses, which isn't going to happen). I hope you consider this from our perspective and in the most friendly and open manner: I completely respect your right to license your own code as you see fit (I've seen people put out GPL 'projects' that effectively consist of 3 lines that import IPython and make a function call, and that's OK too, and allowed by the license I chose to use). The only reason I ask you is because I think your tool is very interesting, and it would ultimately lead to a much more productive relationship with ipython, numpy and matplotlib if it could be a collaboration instead of a one-way benefit. Best regards, Fernando. -- 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 [email protected]
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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
