[matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
[I sent this email a few weeks ago already, but I wasn't subscribed to matplotlib-devel at the time and it seems that the message was never approved by the moderator. So here comes my second attempt. :)] Hi all, this is my first post to this mailing list, so let me take the opportunity to thank everyone involved for an amazing piece of software and all the hard work you guys put into it! It is very much appreciated indeed. I have a quick question/suggestion regarding the save() method in the matplotlib.animation.Animation class. I recently produced an animation in which I needed to set tight bounding boxes when saving the individual frames. Obviously savefig() supports this, but there is no way to pass this information to the Animation.save() method. Would it make sense to let Animation.save() accept additional keyword arguments which are simply passed on to savefig() in each step of the animation loop? Or am I overlooking potential drawbacks of this approach? A simple patch with this idea is attached. Feel free to use it as is or to modify at will if you think this is useful. Many thanks and kind regards, Max 0001-Allow-Animation.save-to-accept-keyword-arguments-whi.patch Description: Binary data -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
Hi Damon, many thanks for the quick (and positive :)) reply, > Sounds like a great idea! Would you feel comfortable having a go at an > implementation? You can make a pull request out of it. The rest of the > developers can then deliberate and provide feedback for you. I attached a patch to my previous email which contains an implementation, but perhaps it didn't make it through to the list? But since I had to clone the git repository anyway to implement it, I'm happy to make a pull request, too. I'll have to find out how to do that since I've never done it before, but I guess it can't be too difficult. Will give it a shot later today. Thanks again and best regards, Max -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
Awesome, many thanks for the detailed instructions, as well as for the valuable suggestions by Eric and Jens. I have now created a pull request containing the proposed change, including the suggested modifications: https://github.com/matplotlib/matplotlib/pull/1442 Any comments/feedback would be much appreciated. Best wishes, Max 2012/10/31 Damon McDougall : > On Wed, Oct 31, 2012 at 7:40 AM, Maximilian Albert > wrote: >> Hi Damon, >> >> many thanks for the quick (and positive :)) reply, >> >>> Sounds like a great idea! Would you feel comfortable having a go at an >>> implementation? You can make a pull request out of it. The rest of the >>> developers can then deliberate and provide feedback for you. >> >> I attached a patch to my previous email which contains an >> implementation, but perhaps it didn't make it through to the list? But >> since I had to clone the git repository anyway to implement it, I'm >> happy to make a pull request, too. I'll have to find out how to do >> that since I've never done it before, but I guess it can't be too >> difficult. Will give it a shot later today. > > You need to fork the main matplotlib repo, so you have your own copy > associated with your github account: > https://help.github.com/articles/fork-a-repo > > Once you've forked it, clone it and create a branch: > > git clone my-forked-repo-url > cd matplotlib > git checkout -b my_awesome_new_feature > # ... hack hack hack ... > git commit -am "Useful commit message here" > git push origin my_awesome_new_feature > > Once you've done that, make a pull request by following the > instructions here: > https://help.github.com/articles/using-pull-requests > > Once you've done that, congratulations! > > Hope this helps. > Best wishes, > Damon > > -- > Damon McDougall > http://www.damon-is-a-geek.com > B2.39 > Mathematics Institute > University of Warwick > Coventry > West Midlands > CV4 7AL > United Kingdom -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
Hi all,
quick update on this: I pushed a small change to make the default
argument immutable (thanks to Jens for pointing this out). Just a
couple more questions/comments:
1) Should there be a test for this? I couldn't find any tests for the
Animation class, so I haven't added one. But perhaps I just missed
them.
2) I discovered this morning that my change uncovers/introduces a bug
in the Animation class, so I'd appreciate a bit more input on whether
it should be merged in the current state. Here is an explanation:
My original use case the suggested change was to be able to set tight
bounding boxes when saving animation frames. At the time I simply
saved all frames to separate images and combined them manually using
avconv, which worked fine. I saw that in the development version of
matplotlib there is built-in support for this, so that the video file
is created automatically. Now whenever I change the bounding box, e.g.
by passing something like savefig_kwargs={'bbox_inches': 'tight'} to
Animation.save(), then the output video shows complete garbage
(similar to white noise). I presume this is because the 'frame_size'
property in the MovieWriter class is not aware of the bounding box
changes introduced by savefig_kwargs and thus reports a frame size to
the video converter that is different from the actual size of the
saved frames.
I don't have much time to look into this at the moment, but I just
wanted to point it out. Does anyone have a quick idea for a good fix,
before I get the time to look into the details of how the MovieWriter
class works?
Many thanks,
Max
2012/10/31 Maximilian Albert :
> Awesome, many thanks for the detailed instructions, as well as for the
> valuable suggestions by Eric and Jens. I have now created a pull
> request containing the proposed change, including the suggested
> modifications:
>
>https://github.com/matplotlib/matplotlib/pull/1442
>
> Any comments/feedback would be much appreciated.
>
> Best wishes,
> Max
>
>
> 2012/10/31 Damon McDougall :
>> On Wed, Oct 31, 2012 at 7:40 AM, Maximilian Albert
>> wrote:
>>> Hi Damon,
>>>
>>> many thanks for the quick (and positive :)) reply,
>>>
>>>> Sounds like a great idea! Would you feel comfortable having a go at an
>>>> implementation? You can make a pull request out of it. The rest of the
>>>> developers can then deliberate and provide feedback for you.
>>>
>>> I attached a patch to my previous email which contains an
>>> implementation, but perhaps it didn't make it through to the list? But
>>> since I had to clone the git repository anyway to implement it, I'm
>>> happy to make a pull request, too. I'll have to find out how to do
>>> that since I've never done it before, but I guess it can't be too
>>> difficult. Will give it a shot later today.
>>
>> You need to fork the main matplotlib repo, so you have your own copy
>> associated with your github account:
>> https://help.github.com/articles/fork-a-repo
>>
>> Once you've forked it, clone it and create a branch:
>>
>> git clone my-forked-repo-url
>> cd matplotlib
>> git checkout -b my_awesome_new_feature
>> # ... hack hack hack ...
>> git commit -am "Useful commit message here"
>> git push origin my_awesome_new_feature
>>
>> Once you've done that, make a pull request by following the
>> instructions here:
>> https://help.github.com/articles/using-pull-requests
>>
>> Once you've done that, congratulations!
>>
>> Hope this helps.
>> Best wishes,
>> Damon
>>
>> --
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> B2.39
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> West Midlands
>> CV4 7AL
>> United Kingdom
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
Hi all, apologies for the delay in getting back to you! The end of last week was quite busy and I was away from my computer during the weekend. 2012/11/1 Ryan May : > You might have more luck using a temp-file based writer. By default, > movies are created by piping in the data to the command; this is much > faster, but, at least as I've done it now, requires a fixed number of > bytes per frame. Try passing writer='ffmpeg_file' or > writer='mencoder_file' to the command to save the animation. Yes, this works indeed. Thanks for pointing it out! I had feared that getting the 'bbox_inches' argument to work at all would be much more involved. > If I get a chance (or someone else if you want to help), I'll see if > there's any way to make the pipe-based writers work with > variable-sized frames. That would be awesome of course. :) > Failing that, we could just ignore the tight > bbox option when using pipes for saving movies. I like this idea. I have now updated my branch so that the save() method checks which writer is being used. If it is not a temp file-based one a warning is issued and the 'bbox_inches' argument is dropped if it is present (see [1]). Please review and comment. :) Best regards, Max [1] https://github.com/maxalbert/matplotlib/commit/fe44357d04fd708c616e88e386bb06100c12aaca -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
P.S.: As an aside, when I run ffmpeg on my machine it issues a deprecation warning and suggests to use avconv instead. Is it worth converting animation.py from ffmpeg to avconv, too? The command line arguments should be virtually identicaly (as far as I know - I only use it very occasionally, though). Cheers, Max -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
2012/12/16 Thomas Kluyver : > On 15 December 2012 23:38, Damon McDougall > wrote: >> >> Maybe the best thing is to host the binaries on Sourceforge. > > > Having recently tried to do it, Sourceforge tries really hard to avoid > giving you a direct link that can repeatably be used to download a file > automatically, i.e. without a browser. In the case I was after it for, I > ended up downloading the file (a PyWin32 binary) with a browser, and storing > it on the CI server that I wanted to install it. I haven't followed this thread in detail, so not sure if it's really relevant: I agree that it's quite messy, but it's definitely possible to find stable download links for automated downloads from sourceforge. I sometimes need this because I use a ports-like system for installing certain packages from source on top of my regular Ubuntu system, and it does work quite well. So if this is what's keeping people from Sourceforge then there are definitely workarounds (give me a shout if you need more specific information; I'm likely to have very sporadic internet access over the next few weeks though, so replies may take a while). However, I also think Sourceforge's interface is really ugly so if there are better alternatives then that's great. :) Cheers, Max -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib's new default colormap
Hi all, I had a discussion with Phil Elson about this last weekend during the Bloomberg Open Source Day. I don't consider myself an expert on colormaps by any means, but I started digging into them a while ago when I was looking for a way of generating a perceptually linear *cyclic* colormap in order to represent phase angle values. (I've been meaning to discuss this issue on this list for a while but will do so in a different thread once I get around to tidying up my results so far.) Phil encouraged me to reply to this thread because he said that even non-expert views would be very welcome, so here you go. Basically, I agree with most of what Nathaniel Smith suggested in his email from November 21. I'm going to comment on some of his points inline below and will finally suggest a way of designing a new colormap at the end. Nathaniel Smith wrote: > it should be a sequential colormap [...] Agreed. > it should be perceptually uniform Agreed. > There's lots of research on how to measure perceptual distance -- > a colleague and I happen to have recently implemented a > state-of-the-art model of this for another project, in case anyone > wants to play with it [3]. I haven't had time to check this out in detail yet, but it looks pretty interesting and will certainly be very useful to assess the quality of any suggestions. However, can this help to actually *design* a new colormap? The answer might be hidden in the referenced paper [Luo2006], but I haven't read it yet. > or just using good-old-L*a*b* is a reasonable quick-and-dirty approximation. Can you elaborate how "dirty" you think using L*a*b* would be? (See my suggestion for finding a new colormap below.) >- it should have a perceptually uniform luminance ramp, i.e. if you > convert to greyscale it should still be uniform. Agreed. What's unclear to me is how large this luminance ramp should be. We certainly can't go all the way to full luminance because this won't be visible on a white background. This probably needs experimenting (again see below). > - it should also have some kind of variation in hue, because > hue variation is a really helpful additional cue to perception, > having two cues is better than one, and there's no reason > not to do it. Agreed. > - the hue variation should be chosen to produce reasonable results > even for viewers with the more common types of colorblindness. > (Which rules out things like red-to-green.) Agreed. Are you aware of any simple ways of avoiding the most common issues? Are there any blog posts or papers on designing colormaps that are suitable for colorblind people? > And, for bonus points, it would be nice to choose a hue ramp that > still works if you throw away the luminance variation, because then we > could use the version with varying luminance for 2d plots, and the > version with just hue variation for 3d plots. (In 3d plots you really > want to reserve the luminance channel for lighting/shading, because > your brain is *really* good at extracting 3d shape from luminance > variation. If the 3d surface itself has massively varying luminance > then this screws up the ability to see shape.) Just out of interest, is there currently an easy way in matplotlib of producing a 3d plot where luminance is used for lighting/shading as you suggest? Now the question is: how do we actually *design* a colormap with these requirements? Leon Krischer's notebook [1] looks totally awesome, but if I understand correctly the optimisation he uses "only" takes care of linearising the luminance value, but this does not necessarily guarantee that the hue values are also linear, right? It also feels somewhat clumsy to me to start out with a colormap that's "wrong" (w.r.t. our requirements above) and then "fix" it. However, the notebook looks like a great guidance for finding suitable candidates and assessing their quality. It appears to me that a simple yet effective way of coming up with a good colormap would be to pick two points in the L*a*b* color space that can be represented by RGB values, connect them by a line and use the interpolated values for the resulting colormap. Since L*a*b* space is (close to) perceptually linear, this would pretty much guarantee all the requirements above. What's missing is an easy way of doing this. I'm envisaging a simply GUI which allows the user to easily pick two points in L*a*b* space, generates a colormap from them as described above and also generates a few sample plots to evaluate the quality of the colormap (along the lines of [1] or the numerous blog posts linked to in the discussion). I am close to having a prototype for such a GUI which should allow to do this relatively painlessly. I'll try to finish it up over the weekend and will post here once it's ready. Btw, if anyone has suggestions for sample datasets that can help in assessing the quality of colormaps they would be much appreciated. Any comments or clarifications of points that I misunderstood are very wel
Re: [matplotlib-devel] Matplotlib's new default colormap
Happy new year everyone! Apologies for the long silence. I was snowed in with work before Christmas and then mostly cut off from the internet for the past two weeks. Fortunately, I had a chance over the holidays to flesh out the GUI which I mentioned in my previous email. You can find it here: https://github.com/maxalbert/colormap-selector Basically, it allows you to pick the start/end color of a colormap from two cross sections in CIELab space and interpolates those colors linearly (see the README file for more details). Currently there is one scatterplot to illustrate the resulting colormap but it can be trivially extended to show more interesting sample plots. There are still a few things missing that I'd like to add but at least it's in a state where it can be used and I'd be grateful for feedback, especially with regard to the colormaps generated with it (I do have some opinions myself but it would be interesting to hear others' first). Regarding our ongoing discussion, I had a very useful chat with two colleagues before Christmas which spurred more thoughts. But I guess it's best to discuss them in a separate email when I'm less tired. ;) Best wishes, Max -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib's new default colormap
Hi Federico, Thanks for trying it out and for the feedback! Indeed, I started out writing a simple IPython notebook along the lines you suggested, with just a couple of sliders and plots, but it quickly became too slow and unwieldy for quick explorations, hence the slightly more elaborate GUI. I agree that the reason for the 3D plot on the right may not be obvious at the moment. Personally, I find it useful to get a feel for what the representable colors in CIELab space (and the cross sections for L=const) look like, but when simply using a linear interpolation between two colors (as I'm doing at the moment) it may not be needed to visualise it in 3D. The reason I added it is that while playing around with the GUI I got the impression that my initial suggestion of using a simple linear interpolation between two colors may not result in the best-looking colormaps (this is confirmed by Nathaniel's reply). I'm currently toying with the option to use curved interpolations, and for thee it would be very useful IMHO to see what they look like in 3D. Btw, I have refactored my code a bit and it should be easy to write a simpler UI (e.g. in an IPython notebook) which doesn't need the other dependencies (also, I could drop the wxpython dependency because some conflict with Vispy which I had experienced seems to have disappeared). If you like, feel free to give it a shot to write a UI the way you imagine it. It's always good to have more options for exploration. :) Best wishes, Max 2015-01-08 17:44 GMT+00:00 Federico Ariza : > Nice job. > > I find your GUI a little bit confusing (new to colormap stuff) but I > like the idea, basically I find it overkill, I would replace the gui > by a plot and a couple of slider widgets something simpler to > integrate without new dependencies. > Do you really need the third 3d plot on the right? > > On Mon, Jan 5, 2015 at 9:37 PM, Maximilian Albert > wrote: > > Happy new year everyone! > > > > Apologies for the long silence. I was snowed in with work before > Christmas > > and then mostly cut off from the internet for the past two weeks. > > Fortunately, I had a chance over the holidays to flesh out the GUI which > I > > mentioned in my previous email. You can find it here: > > > >https://github.com/maxalbert/colormap-selector > > > > Basically, it allows you to pick the start/end color of a colormap from > two > > cross sections in CIELab space and interpolates those colors linearly > (see > > the README file for more details). Currently there is one scatterplot to > > illustrate the resulting colormap but it can be trivially extended to > show > > more interesting sample plots. There are still a few things missing that > I'd > > like to add but at least it's in a state where it can be used and I'd be > > grateful for feedback, especially with regard to the colormaps generated > > with it (I do have some opinions myself but it would be interesting to > hear > > others' first). > > > > Regarding our ongoing discussion, I had a very useful chat with two > > colleagues before Christmas which spurred more thoughts. But I guess it's > > best to discuss them in a separate email when I'm less tired. ;) > > > > Best wishes, > > Max > > > > > -- > > Dive into the World of Parallel Programming! The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is > your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take > a > > look and join the conversation now. http://goparallel.sourceforge.net > > ___ > > Matplotlib-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > -- > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? > > -- Antonio Alducin -- > -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib style gallery
Hi Tony, This is awesome. Great work! I was wondering, is there an easy way to cycle through all available styles for a given plot? For instance, clicking on the top left plot displays a maximized image of the "bmh" style. It would be great if one could press arrow-down (say) to cycle through the other styles "dark_background", "fivethirtyeight", etc. for a quick comparison. Cheers, Max 2015-01-06 4:42 GMT+00:00 Tony Yu : > I've been playing around with learning Javascript lately. As part of the > process, I created a Flask app to build a gallery for matplotlib style > sheets: > > https://github.com/tonysyu/matplotlib-style-gallery > > If you run that locally, you can actually input styles, either with a URL > to a *.mplstyle file or with matplotlibrc commands. Here's a static version > without the custom inputs: > > http://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html > > Ideally, I'd get this into a form that could be submitted as a PR for the > matplotlib website, but I'll need a bit more spare time to learn some more > web development (sessions, client storage, etc). > > Cheers! > -Tony > > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] trisurf plots with independent color data
Hi Byron, This is a bit of a workaround, but you can specify facecolors explicitly by creating a triangulation of your surface explicitly and creating a Poly3DCollection with these facecolors. I'm attaching an example below which is a modified version of the plot_trisurf demo [1] in the matplotlib documentation. It showcases both random colors and a smooth gradient (the latter in the line that's commented out). I would have thought that it should be possible to pass an argument like "facecolors" to plot_trisurf directly, since the documentation [2] states that "other arguments are passed on to Poly3DCollection". However, I couldn't get this to work quickly. Maybe someone else knows how? Best regards, Max [1] http://matplotlib.org/examples/mplot3d/trisurf3d_demo.html [2] http://matplotlib.org/mpl_toolkits/mplot3d/api.html from mpl_toolkits.mplot3d import Axes3D from matplotlib import cm import matplotlib.pyplot as plt import numpy as np from matplotlib.tri import Triangulation from mpl_toolkits.mplot3d.art3d import Poly3DCollection n_angles = 36 n_radii = 8 # An array of radii # Does not include radius r=0, this is to eliminate duplicate points radii = np.linspace(0.125, 1.0, n_radii) # An array of angles angles = np.linspace(0, 2*np.pi, n_angles, endpoint=False) # Repeat all angles for each radius angles = np.repeat(angles[...,np.newaxis], n_radii, axis=1) # Convert polar (radii, angles) coords to cartesian (x, y) coords # (0, 0) is added here. There are no duplicate points in the (x, y) plane x = np.append(0, (radii*np.cos(angles)).flatten()) y = np.append(0, (radii*np.sin(angles)).flatten()) # Pringle surface z = np.sin(-x*y) tri = Triangulation(x, y) # NOTE: This assumes that there is a nice projection of the surface into the x/y-plane! triangle_vertices = np.array([np.array([[x[T[0]], y[T[0]], z[T[0]]], [x[T[1]], y[T[1]], z[T[1]]], [x[T[2]], y[T[2]], z[T[2) for T in tri.triangles]) midpoints = np.average(triangle_vertices, axis=1) def find_color_for_point(pt): x, y, z = pt col = [(y+1)/2, (1-y)/2, 0] return col #facecolors = [find_color_for_point(pt) for pt in midpoints] # smooth gradient facecolors = [np.random.random(3) for pt in midpoints] # random colors coll = Poly3DCollection(triangle_vertices, facecolors=facecolors, edgecolors='black') fig = plt.figure() ax = fig.gca(projection='3d') ax.add_collection(coll) ax.set_xlim(-1, 1) ax.set_ylim(-1, 1) ax.set_zlim(-1, 1) ax.elev = 50 plt.show() -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
