Hello, While looking at possible solutions for a matplotlib OpenGL backend, I've been experimenting with pyglet (that has no dependencies) and coded a terminal with embedded 2d arrays display. Sources & screenshots are available at: http://www.loria.fr/~rougier/glnumpy.html Since pyglet seems mature enough, I would like to know if anyone interested in helping writing the OpenGL backend (using pyglet) ? Nicolas
The idea of a shell with inline plots is a fascinating one - I like the minimalism and directness of being able to plot data like this. And the speed of OpenGL is obviously attractive. Is the figure() call syntax different from the existing syntax for figure()? I think there's a usage pattern ingrained in my head that says 'figure => new window,' and any change to the call syntax for figure would seem to open up a lot of room for confusion. It seems that the backend and the shell might be separate issues? My view of the backends is that they only deal with knowing how to draw artists, and are separate from the process of creating those artists through an interactive shell. The following old thread is also relevant, which you may have already seen: http://www.nabble.com/opengl-backend-td19192625.html Thanks, Eric B On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier <Nic...@lo...> wrote: > > Hello, > > While looking at possible solutions for a matplotlib OpenGL backend, > I've been experimenting with pyglet (that has no dependencies) and coded > a terminal with embedded 2d arrays display. > > Sources & screenshots are available at: > http://www.loria.fr/~rougier/glnumpy.html > > Since pyglet seems mature enough, I would like to know if anyone > interested in helping writing the OpenGL backend (using pyglet) ? > > > Nicolas > > > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
Hi, I agree, shell with inline plot is a different issue. I mainly coded it as a proof a concept and because I find it useful for my own needs. The figure call is quite different from the figure call of matplotlib, only the name is common. The idea was to be able to describe a configuration of arrays with a minimum amount of code. figure(Z) -> plot Z figure([Z1,Z2]) -> plot Z1,Z2 side by side figure([[Z1,Z2], [Z3,Z4]]) -> plot Z1,Z2 side by side and below, Z3,Z4 side by side You can optionally indicate that an array spans several rows or columns: figure([[Z1,'-'], [Z3,Z4]]) -> plot Z1 on two columns and below, Z3,Z4 side by side figure([[Z1,Z2], ['|', Z4]]) -> plot Z1 on two rows, then Z2 on first line and Z4 on second line. I looked at the thread you're talking about and it was the reason in the first place that I investigated pyglet. My approach is a bit different since I use a texture and a single quad to render it, it makes things quite fast. The mapping from a float array to a texture data is pretty efficient using numpy interface and it allows me to continuously update texture data (just try modifying the array from within the console). Nicolas On 3 Apr, 2009, at 17:12 , Eric Bruning wrote: > The idea of a shell with inline plots is a fascinating one - I like > the minimalism and directness of being able to plot data like this. > And the speed of OpenGL is obviously attractive. > > Is the figure() call syntax different from the existing syntax for > figure()? I think there's a usage pattern ingrained in my head that > says 'figure => new window,' and any change to the call syntax for > figure would seem to open up a lot of room for confusion. > > It seems that the backend and the shell might be separate issues? My > view of the backends is that they only deal with knowing how to draw > artists, and are separate from the process of creating those artists > through an interactive shell. > > The following old thread is also relevant, which you may have > already seen: > http://www.nabble.com/opengl-backend-td19192625.html > > Thanks, > Eric B > > > On Fri, Apr 3, 2009 at 7:17 AM, Nicolas Rougier > <Nic...@lo...> wrote: >> >> Hello, >> >> While looking at possible solutions for a matplotlib OpenGL backend, >> I've been experimenting with pyglet (that has no dependencies) and >> coded >> a terminal with embedded 2d arrays display. >> >> Sources & screenshots are available at: >> http://www.loria.fr/~rougier/glnumpy.html >> >> Since pyglet seems mature enough, I would like to know if anyone >> interested in helping writing the OpenGL backend (using pyglet) ? >> >> >> Nicolas >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>
On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier <Nic...@lo...> wrote: > > Hello, > > While looking at possible solutions for a matplotlib OpenGL backend, > I've been experimenting with pyglet (that has no dependencies) and coded > a terminal with embedded 2d arrays display. > > Sources & screenshots are available at: > http://www.loria.fr/~rougier/glnumpy.html Wow, the screenshots look gorgeous! Unfortunately I tried to run it after installing it in my path and I got this (same for glnumpy): uqbar[bin]> ./glpython Traceback (most recent call last): File "./glpython", line 70, in <module> logo = pyglet.resource.image('logo.png') File "/var/lib/python-support/python2.5/pyglet/resource.py", line 481, in image identity = self._cached_images[name] = self._alloc_image(name) File "/var/lib/python-support/python2.5/pyglet/resource.py", line 425, in _alloc_image file = self.file(name) File "/var/lib/python-support/python2.5/pyglet/resource.py", line 383, in file raise ResourceNotFoundException(name) pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not found on the path. Ensure that the filename has the correct captialisation. This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt. Cheers, f
Sorry for that, I coded it on linux and just tested on mac. I fixed the error and upload the new version on the same link. Tell me if it's ok. Nicolas On 3 Apr, 2009, at 18:55 , Fernando Perez wrote: > On Fri, Apr 3, 2009 at 4:17 AM, Nicolas Rougier > <Nic...@lo...> wrote: >> >> Hello, >> >> While looking at possible solutions for a matplotlib OpenGL backend, >> I've been experimenting with pyglet (that has no dependencies) and >> coded >> a terminal with embedded 2d arrays display. >> >> Sources & screenshots are available at: >> http://www.loria.fr/~rougier/glnumpy.html > > Wow, the screenshots look gorgeous! > > Unfortunately I tried to run it after installing it in my path and I > got this (same for glnumpy): > > uqbar[bin]> ./glpython > Traceback (most recent call last): > File "./glpython", line 70, in <module> > logo = pyglet.resource.image('logo.png') > File "/var/lib/python-support/python2.5/pyglet/resource.py", line > 481, in image > identity = self._cached_images[name] = self._alloc_image(name) > File "/var/lib/python-support/python2.5/pyglet/resource.py", line > 425, in _alloc_image > file = self.file(name) > File "/var/lib/python-support/python2.5/pyglet/resource.py", line > 383, in file > raise ResourceNotFoundException(name) > pyglet.resource.ResourceNotFoundException: Resource "logo.png" was not > found on the path. Ensure that the filename has the correct > captialisation. > > > This is on ubuntu 8.10, 64 bit, installed with --prefix=$HOME/usr/opt. > > Cheers, > > f
On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier <Nic...@lo...> wrote: > > > Sorry for that, I coded it on linux and just tested on mac. > I fixed the error and upload the new version on the same link. Tell me if > it's ok. Great! Would you have any interest in having this be shipped/developed as part of IPython itself? You are using a fair amount of internals of the ipython machinery, and we're getting ready for a large cleanup. Having your code shipped with ipython itself would give it perhaps more exposure, as well as allow it to evolve in sync with the rest of the API, since we could test it as the internals change. I think it would be great to ship this with ipython itself, and I'm sure you'd get help and contributions from the rest of the ipython team as well... Best, f
Sure, thread about IPython integration to be continued on ipython-dev list... Nicolas On 3 Apr, 2009, at 19:07 , Fernando Perez wrote: > On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier > <Nic...@lo...> wrote: >> >> >> Sorry for that, I coded it on linux and just tested on mac. >> I fixed the error and upload the new version on the same link. Tell >> me if >> it's ok. > > Great! > > Would you have any interest in having this be shipped/developed as > part of IPython itself? > > You are using a fair amount of internals of the ipython machinery, and > we're getting ready for a large cleanup. Having your code shipped > with ipython itself would give it perhaps more exposure, as well as > allow it to evolve in sync with the rest of the API, since we could > test it as the internals change. > > I think it would be great to ship this with ipython itself, and I'm > sure you'd get help and contributions from the rest of the ipython > team as well... > > Best, > > f
There has been a recent thread discussing sympy interface to pyglet in the context of matplotlib refactoring of the 3D code. See thread named 'Updating MPlot3D to a more recent matplotlib.' If you are porting pyglet interface to Ipython, Ondrej might be happy to see his sympy 3D plotting routines go there as well :) cheers, Johann Nicolas Rougier wrote: > Sure, thread about IPython integration to be continued on ipython-dev > list... > > Nicolas > > On 3 Apr, 2009, at 19:07 , Fernando Perez wrote: > > >> On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier >> <Nic...@lo...> wrote: >> >>> Sorry for that, I coded it on linux and just tested on mac. >>> I fixed the error and upload the new version on the same link. Tell >>> me if >>> it's ok. >>> >> Great! >> >> Would you have any interest in having this be shipped/developed as >> part of IPython itself? >> >> You are using a fair amount of internals of the ipython machinery, and >> we're getting ready for a large cleanup. Having your code shipped >> with ipython itself would give it perhaps more exposure, as well as >> allow it to evolve in sync with the rest of the API, since we could >> test it as the internals change. >> >> I think it would be great to ship this with ipython itself, and I'm >> sure you'd get help and contributions from the rest of the ipython >> team as well... >> >> Best, >> >> f >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
I read the thread about mplot3d and the work that has been done by Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. Jonathan's work seems to be great for simple 3D plotting while the mayavi mlab module is here for more "serious" rendering. I think I will concentrate my efforts on a simple GL terminal for IPython with embedded visualization capability. As for sympy (and because it uses pyglet), I guess the integration should be straight forward. Last version of the ipython GL terminal is on launchpad: https://launchpad.net/glipy Nicolas On 7 Apr, 2009, at 00:38 , Cohen-Tanugi Johann wrote: > There has been a recent thread discussing sympy interface to pyglet > in the context of matplotlib refactoring of the 3D code. See thread > named 'Updating MPlot3D to a more recent matplotlib.' > If you are porting pyglet interface to Ipython, Ondrej might be > happy to see his sympy 3D plotting routines go there as well :) > cheers, > Johann > > Nicolas Rougier wrote: >> Sure, thread about IPython integration to be continued on ipython- >> dev list... >> >> Nicolas >> >> On 3 Apr, 2009, at 19:07 , Fernando Perez wrote: >> >> >>> On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier >>> <Nic...@lo...> wrote: >>> >>>> Sorry for that, I coded it on linux and just tested on mac. >>>> I fixed the error and upload the new version on the same link. >>>> Tell me if >>>> it's ok. >>>> >>> Great! >>> >>> Would you have any interest in having this be shipped/developed as >>> part of IPython itself? >>> >>> You are using a fair amount of internals of the ipython machinery, >>> and >>> we're getting ready for a large cleanup. Having your code shipped >>> with ipython itself would give it perhaps more exposure, as well as >>> allow it to evolve in sync with the rest of the API, since we could >>> test it as the internals change. >>> >>> I think it would be great to ship this with ipython itself, and I'm >>> sure you'd get help and contributions from the rest of the ipython >>> team as well... >>> >>> Best, >>> >>> f >>> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>
Nicolas Rougier wrote: > > I read the thread about mplot3d and the work that has been done by > Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. > Jonathan's work seems to be great for simple 3D plotting while the > mayavi mlab module is here for more "serious" rendering. I think I > will concentrate my efforts on a simple GL terminal for IPython with > embedded visualization capability. As for sympy (and because it uses > pyglet), I guess the integration should be straight forward. > > Last version of the ipython GL terminal is on launchpad: > https://launchpad.net/glipy Hi Nicolas, I haven't tried your glipy terminal, but it looks very interesting. The main issue with an OpenGL backend for MPL is simply that a naive implementation is going to look ugly when compared, pixel-by-pixel, against the Agg or cairo backends to generate bitmaps. Agg and cairo are very good at drawing anti-aliased lines, whereas one must jump through hoops to get consumer OpenGL cards to render lines well. Here's an idea -- an OpenGLAgg backend that actually uses Agg for all the rendering, but blits the results to an OpenGL texture for display. Thus, the backend would really just be glue between the existing Agg backend and pyglet. -Andrew
What I do generally to have "nice" OpenGL output is to render screenshots at high resolution and then use something like gimp to resize them. I agree that it is far from optimal but it's pretty decent for a scientific paper. Other solutions are vector rendering of scene (using gl2ps for example) or the texture anti-aliasing technique (http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html). But, beside rendering issue, I think an OpenGL backend could be useful for experiments involving very fast rendering of large arrays. Using OpenGL texture, you can render 1000x1000 arrays with continuous update of data (on recent machines). Nicolas On 7 Apr, 2009, at 19:05 , Andrew Straw wrote: > Nicolas Rougier wrote: >> >> I read the thread about mplot3d and the work that has been done by >> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. >> Jonathan's work seems to be great for simple 3D plotting while the >> mayavi mlab module is here for more "serious" rendering. I think I >> will concentrate my efforts on a simple GL terminal for IPython with >> embedded visualization capability. As for sympy (and because it uses >> pyglet), I guess the integration should be straight forward. >> >> Last version of the ipython GL terminal is on launchpad: >> https://launchpad.net/glipy > > Hi Nicolas, I haven't tried your glipy terminal, but it looks very > interesting. > > The main issue with an OpenGL backend for MPL is simply that a naive > implementation is going to look ugly when compared, pixel-by-pixel, > against the Agg or cairo backends to generate bitmaps. Agg and cairo > are > very good at drawing anti-aliased lines, whereas one must jump through > hoops to get consumer OpenGL cards to render lines well. > > Here's an idea -- an OpenGLAgg backend that actually uses Agg for all > the rendering, but blits the results to an OpenGL texture for display. > Thus, the backend would really just be glue between the existing Agg > backend and pyglet. > > -Andrew > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Nicolas Rougier wrote: > > What I do generally to have "nice" OpenGL output is to render > screenshots at high resolution and then use something like gimp to > resize them. I agree that it is far from optimal but it's pretty > decent for a scientific paper. Other solutions are vector rendering of > scene (using gl2ps for example) or the texture anti-aliasing technique > (http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html). Yes. That is why I said a "naive" implementation. > But, beside rendering issue, I think an OpenGL backend could be useful > for experiments involving very fast rendering of large arrays. Using > OpenGL texture, you can render 1000x1000 arrays with continuous update > of data (on recent machines). Yes. I wrote a module pygarrayimage for just that: http://code.astraw.com/projects/motmot/pygarrayimage.html BTW, my ideas were meant more as "how to wedge MPL quickly into glipy with a minimum of work" rather than "a talented programmer with one year of free time to come up with the coolest scientific workflow GUI" variety. -Andrew
> > BTW, my ideas were meant more as "how to wedge MPL quickly into glipy > with a minimum of work" rather than "a talented programmer with one > year > of free time to come up with the coolest scientific workflow GUI" > variety. Sorry, I did not understood your proposal in the first place... That might be a good thing to try, I'll have a look at as soon as I have more free time. Nicolas
Eric Bruning wrote: > The idea of a shell with inline plots is a fascinating one - Then check out reinteract -- very cool: http://www.reinteract.org/trac/ (though no opengl) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
There is also: http://www.loria.fr/~rougier/pycons.html which is a gtk shell with embedded matplotlib figures. Nicolas On 5 Apr, 2009, at 06:02 , Christopher Barker wrote: > > Eric Bruning wrote: >> The idea of a shell with inline plots is a fascinating one - > > Then check out reinteract -- very cool: > > http://www.reinteract.org/trac/ > > (though no opengl) > > -Chris > > -- > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chr...@no... > > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel