Fwd: [IPython-dev] Interactive visualization in the IPython notebook 2.0
21 views
Skip to first unread message
Jason Moore
Apr 3, 2014, 12:58:21 PM4/3/14
to sy...@googlegroups.com
This is very relevant to the discussions of having 3D plotting in SymPy with three.js.
---------- Forwarded message ----------
From: Jason Grout <jason...@creativetrax.com>
Date: Thu, Apr 3, 2014 at 12:40 PM
Subject: Re: [IPython-dev] Interactive visualization in the IPython notebook 2.0
To: ipyth...@scipy.org
I should also mention that we have been working on wrapping three.js as
a widget, which may be much closer to your usecase than the matplotlib
work. I think we're nearly done (our main TODO now is wrapping
interactive picking, and then cleaning up the existing code based on the
patterns we've observed, plus documenting and providing examples).
https://github.com/jasongrout/pythreejs
Live demo of your face on a sphere:
http://sagecell.sagemath.org/?q=qjjurl (you may need to press Evaluate
to overcome the latency of loading the javascript, and you'll also need
to grant the browser permission to use your camera)
The idea behind wrapping three.js is that it provides useful scenegraph
primitives, and also renders to canvas if webgl isn't available. We
basically are just providing access to the three.js primitives in
Python, along with a few convenience classes (for example, for rendering
a function surface, or rendering a text sprite). We are also building a
converter for Sage graphics on top of this wrapping.
It sounds like vispy needs a lower layer than our pythree.js project
(since it looks like you are constructing the opengl code directly).
But it might give you some ideas...
Thanks,
Jason
On 4/3/14, 8:13, Phil Elson wrote:
> I'm not aware of IPython providing anything other than the generic (and
> useful) infrastructure for this plotting usecase, but there exists a
> comm based proof-of-concept interactive visualisation produced by Jason
> Grout in https://github.com/matplotlib/matplotlib/pull/2524 which may be
> of interest.
>
> It is also worth noting that the WebAgg backend in matplotlib is a fully
> bona fide backend available since v1.3.
>
> Essentially the only reason there isn't an interactive matplotlib
> IPython interface already is because nobody with the right technical
> expertise has had an opportunity to do - I don't believe there are any
> remaining technical hurdles, and I don't even think it is a big piece of
> work at this point.
>
> HTH,
>
> Phil
>
>
>
>
> On 3 April 2014 10:47, Cyrille Rossant <cyrille...@gmail.com
> IPyth...@scipy.org <mailto:IPyth...@scipy.org>
> http://mail.scipy.org/mailman/listinfo/ipython-dev
From: Jason Grout <jason...@creativetrax.com>
Date: Thu, Apr 3, 2014 at 12:40 PM
Subject: Re: [IPython-dev] Interactive visualization in the IPython notebook 2.0
To: ipyth...@scipy.org
I should also mention that we have been working on wrapping three.js as
a widget, which may be much closer to your usecase than the matplotlib
work. I think we're nearly done (our main TODO now is wrapping
interactive picking, and then cleaning up the existing code based on the
patterns we've observed, plus documenting and providing examples).
https://github.com/jasongrout/pythreejs
Live demo of your face on a sphere:
http://sagecell.sagemath.org/?q=qjjurl (you may need to press Evaluate
to overcome the latency of loading the javascript, and you'll also need
to grant the browser permission to use your camera)
The idea behind wrapping three.js is that it provides useful scenegraph
primitives, and also renders to canvas if webgl isn't available. We
basically are just providing access to the three.js primitives in
Python, along with a few convenience classes (for example, for rendering
a function surface, or rendering a text sprite). We are also building a
converter for Sage graphics on top of this wrapping.
It sounds like vispy needs a lower layer than our pythree.js project
(since it looks like you are constructing the opengl code directly).
But it might give you some ideas...
Thanks,
Jason
On 4/3/14, 8:13, Phil Elson wrote:
> I'm not aware of IPython providing anything other than the generic (and
> useful) infrastructure for this plotting usecase, but there exists a
> comm based proof-of-concept interactive visualisation produced by Jason
> Grout in https://github.com/matplotlib/matplotlib/pull/2524 which may be
> of interest.
>
> It is also worth noting that the WebAgg backend in matplotlib is a fully
> bona fide backend available since v1.3.
>
> Essentially the only reason there isn't an interactive matplotlib
> IPython interface already is because nobody with the right technical
> expertise has had an opportunity to do - I don't believe there are any
> remaining technical hurdles, and I don't even think it is a big piece of
> work at this point.
>
> HTH,
>
> Phil
>
>
>
>
> On 3 April 2014 10:47, Cyrille Rossant <cyrille...@gmail.com
> <mailto:cyrille...@gmail.com>> wrote:
>
> Dear IPython developers,
>
> Let me introduce you to Mustafa Kaptan (in CC), a student who has
> started to contribute to Vispy [1], and who has made an application to
> GSoC this year. He'd be interested in integrating Vispy in the IPython
> notebook for high-performance interactive visualization in the
> browser. He already made a nice proof of concept [2]. We're likely to
> need your help soon enough!
>
> There are many different and complementary approaches. For now, we've
> chosen to start with the simplest approach: the server renders a
> figure with OpenGL, outputs a PNG, and sends it to the browser with
> WebSockets and Tornado. Javascript captures user actions (mouse
> clicks, mouse moves, keystrokes...) and sends them in return to the
> server. I think that is similar to a proof of concept for matplotlib
> made by Michael Droettboom some time ago [3].
>
> IPython 2.0 now offers the right architecture for this. I was
> wondering whether there was anyone on your side working on something
> like this already? I think it would make sense to have common
> protocols, interfaces and code for matplotlib, Vispy, and other
> visualization libraries. Sending PNG and user events in JSON, creating
> a sort of "distributed" event loop, all seem generic enough to me. It
> would be too bad if we all duplicated our efforts for the same thing.
>
> Where should we start? Comms, something else? Also, we'd like to reuse
> some of this architecture for a slightly different approach. Instead
> of letting the server render the figure with OpenGL, we'd just send
> OpenGL commands and binary data to the browser (client-side rendering
> with WebGL).
>
> Best regards,
> Cyrille
>
> [1] http://vispy.org/
> [2]
> https://github.com/mfkaptan/experimental/tree/master/online_backend/tornado
> [3]
> http://mdboom.github.io/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
> _______________________________________________
> IPython-dev mailing list
>
> Dear IPython developers,
>
> Let me introduce you to Mustafa Kaptan (in CC), a student who has
> started to contribute to Vispy [1], and who has made an application to
> GSoC this year. He'd be interested in integrating Vispy in the IPython
> notebook for high-performance interactive visualization in the
> browser. He already made a nice proof of concept [2]. We're likely to
> need your help soon enough!
>
> There are many different and complementary approaches. For now, we've
> chosen to start with the simplest approach: the server renders a
> figure with OpenGL, outputs a PNG, and sends it to the browser with
> WebSockets and Tornado. Javascript captures user actions (mouse
> clicks, mouse moves, keystrokes...) and sends them in return to the
> server. I think that is similar to a proof of concept for matplotlib
> made by Michael Droettboom some time ago [3].
>
> IPython 2.0 now offers the right architecture for this. I was
> wondering whether there was anyone on your side working on something
> like this already? I think it would make sense to have common
> protocols, interfaces and code for matplotlib, Vispy, and other
> visualization libraries. Sending PNG and user events in JSON, creating
> a sort of "distributed" event loop, all seem generic enough to me. It
> would be too bad if we all duplicated our efforts for the same thing.
>
> Where should we start? Comms, something else? Also, we'd like to reuse
> some of this architecture for a slightly different approach. Instead
> of letting the server render the figure with OpenGL, we'd just send
> OpenGL commands and binary data to the browser (client-side rendering
> with WebGL).
>
> Best regards,
> Cyrille
>
> [1] http://vispy.org/
> [2]
> https://github.com/mfkaptan/experimental/tree/master/online_backend/tornado
> [3]
> http://mdboom.github.io/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
> _______________________________________________
> IPython-dev mailing list
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPyth...@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
IPyth...@scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPyth...@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
IPyth...@scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
SAHIL SHEKHAWAT
Apr 3, 2014, 1:04:31 PM4/3/14
to sy...@googlegroups.com
This seems very interesting and is definitely relevant...I am looking into it..
Thank you Jason
Reply all
Reply to author
Forward
0 new messages