[matplotlib-devel] mpld3: a D3 viewer for matplotlib
Hello, Some folks suggested I send this here. I recently started a project which can render a subset of matplotlib outputs via D3/JS/HTML for interactive browser viewing. It's still very incomplete, but I think this has a lot of potential for quick browser-based visualizations of small to medium datasets. blog post: http://jakevdp.github.io/blog/2013/12/19/a-d3-viewer-for-matplotlib/ github page: http://github.com/jakevdp/mpld3 In particular, I'm wondering if there would be a way to take advantage of the already existing functionality in the SVG backend, and monkey-patch that into a D3-generated panning/scrolling axis. I'd be interested in any feedback you have! Thanks, Jake -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Meeting...?
I'll probably not be able to swing 6am on the west coast, but other folks are more important for this call, I think :) Jake On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root wrote: > That would actually work a little bit better for me... I just have to > remember to get into work a little bit earlier. > > Ben > > On Tue, Jan 14, 2014 at 11:36 AM, Michael Droettboom wrote: > >> I'm fine with starting the meeting an hour early. How about others? >> >> Mike >> >> On 01/14/2014 04:57 AM, Michiel de Hoon wrote: >> > I can join this Thursday if we start with the discussion on timers. >> > If we can start 1 hour earlier (14:00 UTC, 9 am ET, 23:00 in Japan) >> that would be even better. >> > -Michiel. >> > >> > >> > >> > >> > On Mon, 1/13/14, Michael Droettboom wrote: >> > >> > Subject: [matplotlib-devel] Meeting...? >> > To: "[email protected]" < >> [email protected]> >> > Date: Monday, January 13, 2014, 11:36 AM >> > >> > It's probably a good time to schedule >> > another matplotlib Google Hangout. >> > >> > Is this Thursday at 1500 UTC (10 am ET) too short notice for >> > the usual >> > candidates? >> > >> > I know there was discussion of getting Michiel de Hoon on >> > today (which I >> > just saw, unfortunately). Is there another time in the >> > future that >> > works for you, Michiel? >> > >> > Mike >> > >> > -- >> > >> > _ >> > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ >> > _ ._ _ >> > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >> > >> > http://www.droettboom.com >> > >> > >> > >> -- >> > CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> > Learn Why More Businesses Are Choosing CenturyLink Cloud >> > For >> > Critical Workloads, Development Environments & >> > Everything In Between. >> > Get a Quote or Start a Free Trial Today. >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> > ___ >> > Matplotlib-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > >> >> >> -- >> _ >> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ >> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | >> >> http://www.droettboom.com >> >> >> >> -- >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Meeting...?
Thanks - we'll make it happen at some point. Perhaps I can give the seed for a discussion: the stuff I've been doing with mpld3 is a lot of fun, but it's fundamentally limited by the fact that I have to dig around the internals of the figure object to find the relevant information to construct a plot representation. I may be able to do the same thing by creating a backend, but the problem is that the draw() methods of most objects call the renderer with no reference to whether the points lie in the data space or figure space: that is, paths and points are usually specified in figure/pixel coordinates or some transformed version thereof, which makes it near impossible to construct interactive representations absent Python kernel callbacks. What I'd love to see is some enhancement of the backend framework where there are some extra flags and information passed to the renderer: i.e. for each draw command, we need to know whether the drawn object should be linked to static figure coordinates or to dynamic axes/data coordinates. I've been in touch with Cyrille Rossant from the vispy team, Chris Beaumont from the Glue team, and Matt Sundwuist from the plotly team, all of whom asked if there might be a way to use what I've done with mpld3 to enable matplotlib to export into their own front-end format. I didn't start mpld3 with that sort of extensibility in mind, but I'm starting to invest some time thinking about how to design that. With the current matplotlib package, I think there are two ways to accomplish it: one is to create a general backend-like interface based on the figure introspection that mpld3 currently uses. The artist elements in each figure contain enough information to be able to infer whether the elements should move & zoom with the axes or not. The problem is, a lot of elements (like legends, axes aspects, etc.) are not fully established until the draw() command is called, so there are a few ugly hacks required to make it happen. The other option is to use an even uglier hack, and wrap the current backend framework with an object that somehow links back into the figure and infers from the draw_*() commands whether the path/point/marker/etc. should be drawn in static figure coordinates or in dynamic axes coordinates. I've started a simple prototype backend translator which has a renderer class that uses ``inspect`` back-trace the stack and accomplish this: It's really ugly, and I'm not particularly proud about it, but I think it's the current best way to accomplish the desired behavior. Ugly hacks aside, I think all of this points to a general desire for a new type of backend-like hook that can export dynamic plot elements in data coordinates, and static plot elements in figure coordinates. An enhancement in that direction could pave the way for a lot of interesting interactive front-ends to matplotlib figures. Anyway - if any of you have suggestions or responses to this, I'd love to hear them! Thanks, Jake On Tue, Jan 14, 2014 at 9:11 AM, Michael Droettboom wrote: > Jake: I'd definitely like to get you into one of these calls at some > point. If you're able to pop in late, that would still be great -- or we > can save that for another date. Trying to get Japan, three NA timezones > and the UK all together is challenging ;) > > In any event, with Thomas, Ben, Michiel and myself confirmed, I think > that's enough to go ahead, and hopefully others who have yet to respond can > join as well. > > Mike > > > On 01/14/2014 11:57 AM, Jacob Vanderplas wrote: > > I'll probably not be able to swing 6am on the west coast, but other folks > are more important for this call, I think :) >Jake > > > On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root wrote: > >> That would actually work a little bit better for me... I just have to >> remember to get into work a little bit earlier. >> >> Ben >> >> On Tue, Jan 14, 2014 at 11:36 AM, Michael Droettboom wrote: >> >>> I'm fine with starting the meeting an hour early. How about others? >>> >>> Mike >>> >>> On 01/14/2014 04:57 AM, Michiel de Hoon wrote: >>> > I can join this Thursday if we start with the discussion on timers. >>> > If we can start 1 hour earlier (14:00 UTC, 9 am ET, 23:00 in Japan) >>> that would be even better. >>> > -Michiel. >>> > >>> > >>> > >>> > >>> > On Mon, 1/13/14, Michael Droettboom wrote: >>> > >>> > Subject: [matplotlib-devel] Meeting...? >>> > To: "[email protected]" < >>> [email protected]> >>> > Date:
Re: [matplotlib-devel] Meeting...?
On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom wrote: > > I hope all of the above makes sense... > Definitely makes sense: what I've built-up in mpld3 is essentially something that mimics this sort of visitor pattern, though it misses some things because of the draw-time difficulties you mention. I think a two-stage draw() would be a _very_ helpful restructure. Currently, I'm forced to achieve this result by writing a png to a throwaway byte-stream... Jake > > Mike > > > On 01/14/2014 01:30 PM, Jacob Vanderplas wrote: > > Thanks - we'll make it happen at some point. > > Perhaps I can give the seed for a discussion: the stuff I've been doing > with mpld3 is a lot of fun, but it's fundamentally limited by the fact that > I have to dig around the internals of the figure object to find the > relevant information to construct a plot representation. I may be able to > do the same thing by creating a backend, but the problem is that the draw() > methods of most objects call the renderer with no reference to whether the > points lie in the data space or figure space: that is, paths and points are > usually specified in figure/pixel coordinates or some transformed version > thereof, which makes it near impossible to construct interactive > representations absent Python kernel callbacks. > > What I'd love to see is some enhancement of the backend framework where > there are some extra flags and information passed to the renderer: i.e. for > each draw command, we need to know whether the drawn object should be > linked to static figure coordinates or to dynamic axes/data coordinates. > > I've been in touch with Cyrille Rossant from the vispy team, Chris > Beaumont from the Glue team, and Matt Sundwuist from the plotly team, all > of whom asked if there might be a way to use what I've done with mpld3 to > enable matplotlib to export into their own front-end format. I didn't > start mpld3 with that sort of extensibility in mind, but I'm starting to > invest some time thinking about how to design that. > > With the current matplotlib package, I think there are two ways to > accomplish it: one is to create a general backend-like interface based on > the figure introspection that mpld3 currently uses. The artist elements in > each figure contain enough information to be able to infer whether the > elements should move & zoom with the axes or not. The problem is, a lot of > elements (like legends, axes aspects, etc.) are not fully established until > the draw() command is called, so there are a few ugly hacks required to > make it happen. > > The other option is to use an even uglier hack, and wrap the current > backend framework with an object that somehow links back into the figure > and infers from the draw_*() commands whether the path/point/marker/etc. > should be drawn in static figure coordinates or in dynamic axes > coordinates. I've started a simple prototype backend translator which has a > renderer class that uses ``inspect`` back-trace the stack and accomplish > this: It's really ugly, and I'm not particularly proud about it, but I > think it's the current best way to accomplish the desired behavior. > > Ugly hacks aside, I think all of this points to a general desire for a > new type of backend-like hook that can export dynamic plot elements in data > coordinates, and static plot elements in figure coordinates. An > enhancement in that direction could pave the way for a lot of interesting > interactive front-ends to matplotlib figures. > > Anyway - if any of you have suggestions or responses to this, I'd love > to hear them! Thanks, >Jake > > > On Tue, Jan 14, 2014 at 9:11 AM, Michael Droettboom wrote: > >> Jake: I'd definitely like to get you into one of these calls at some >> point. If you're able to pop in late, that would still be great -- or we >> can save that for another date. Trying to get Japan, three NA timezones >> and the UK all together is challenging ;) >> >> In any event, with Thomas, Ben, Michiel and myself confirmed, I think >> that's enough to go ahead, and hopefully others who have yet to respond can >> join as well. >> >> Mike >> >> >> On 01/14/2014 11:57 AM, Jacob Vanderplas wrote: >> >> I'll probably not be able to swing 6am on the west coast, but other folks >> are more important for this call, I think :) >>Jake >> >> >> On Tue, Jan 14, 2014 at 8:51 AM, Benjamin Root wrote: >> >>> That would actually work a little bit better for me... I just have to >>> remember to get into work a little bit
Re: [matplotlib-devel] animation of a fill_between region
Hi Mauricio, Patch objects are a bit more difficult to work with than line objects, because unlike line objects are a step removed from the input data supplied by the user. There is an example similar to what you want to do here: http://matplotlib.org/examples/animation/histogram.html Basically, you need to modify the vertices of the path at each frame. It might look something like this: from matplotlib import animation import numpy as np import matplotlib.pyplot as plt fig, ax = plt.subplots() ax.set_xlim([0,1]) x = np.linspace(6000.,7000., 5) y = np.ones_like(x) collection = plt.fill_between(x, y) def animate(i): path = collection.get_paths()[0] path.vertices[:, 1] *= 0.9 animation.FuncAnimation(fig, animate, frames=25, interval=30) Take a look at path.vertices to see how they're laid out. Hope that helps, Jake On Sat, Feb 1, 2014 at 7:44 AM, Mauricio Calvao wrote: > Hi there, > > I have the following simple code to plot a (static) fill_between region > in a given plot. > > > import numpy as np > import matplotlib. pyplot as plt > > plt.figure() > ax=plt.axes() > ax.set_xlim([0,1]) > > x = np.linspace(6000.,7000.) > y = np.ones(np.shape(x)) > > plt.fill_between(x,y) > > > I would like now to animate this band (which is a PolyCollection object, > and not a Line2D one) so that it moves smoothly to the right up together > with being stretched, that is, to the new x positions: .7200, 8400. I saw > several animations in the matplotlib homepage, but they only looped over > line or image objects, not polycollection ones, such as fill_between... Is > this possible? > > In stackoverflow there is this link: > http://stackoverflow.com/questions/16120801/matplotlib-animate-fill-between-shape, > which might solve this question but I was not able to understand it fully > in order to have a simple minmal working example. If that is the right > direction, I would appreciate immensely if someone could provide such an > example! > > Thanks in advance > > -- > ### > Prof. Mauricio Ortiz Calvao > Federal University of Rio de Janeiro > Institute of Physics, P O Box 68528 > CEP 21941-972 Rio de Janeiro, RJ > Brazil > > Email: [email protected] > Phone: (55)(21)25627483 > Homepage: http://www.if.ufrj.br/~orca > ### > > > -- > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Question about legend rendering
Hi,
Working on mpld3, I've hit something I don't quite know how to handle. I'm
trying to render legend components in d3, and the strange thing is that
markers within the legend have empty paths. Consider the script below:
#--
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
line, = ax.plot(range(5), range(5), 'o', label='dots')
ax.legend()
print("here is the marker as it appears in the plot:")
print(line._marker.get_path())
leg = ax.get_legend()
children = leg.get_children()
print("here is the marker as it appears in the legend")
print(children[1]._marker.get_path())
#--
On the plot itself, the marker is a circle. On the legend, the marker is an
empty path. I've tried poking around in the backend code to figure out how
the renderers know what path to use when drawing the legend, but the answer
is not obvious to me.
Does anyone have insight into what special magic happens here when the
legend is rendered? Thanks,
Jake
Jake VanderPlas
Director of Research - Physical Sciences
eScience Institute, University of Washington
http://www.vanderplas.com
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
