From ben.v.root at gmail.com Tue Feb 9 11:52:47 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Tue, 9 Feb 2016 11:52:47 -0500 Subject: [Matplotlib-devel] Response to architecture query Message-ID: Excerpt response to a private query about matplotlib's architecture. Some has asked me to post it as a possible addition to development docs. All of matplotlib started off as pure python. As time went on, it was re-worked into a backend/frontend design. The frontend is mostly in python, with critical portions, such as path and vector handling implemented in C++. We are also heavily reliant upon NumPy and use its C-API in those C++ parts. We also call out to various other libraries such as libfreetype to perform our font-handling. The frontend is also a bit of a misnomer, because it isn't really at the front, as most people are familiar with the pyplot interface, which sits on top of the frontend. The backends are what allows us to output the figures to the many different "devices" (filetypes, GUI toolkits, etc.). Most are implemented in python using the respective GUI toolkit's python bindings. The Tk backend, oddly enough, is implemented in C/C++ (don't ask me why, I haven't a clue), and the macosx backend is implemented in Obj-C. The AGG backend is implemented in C++. PDF and PS backends are implemented in python as well. AGG is critically important to matplotlib's functionality. Not only does it serve as the default headless backend, and is often mixed with the GUI backends (TkAgg, Qt4Agg, etc.) to produce consistent results across all platforms, it also serves as the basis for our image-handling architecture. This is a very broad-brush overview of the matplotlib architecture. It isn't a simple layered system, unfortunately, but we do have some critical portions off-loaded to C/C++ or NumPy. Probably some of the most difficult-to-understand portions of the codebase isn't those parts, though. It is the figure/axes/axis relationships for defining properties at the right time (lots of multiple-inheritance confusion) as well as the figure/canvas/manager relationships for interactivity. Cheers! Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Tue Feb 9 15:50:14 2016 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 9 Feb 2016 10:50:14 -1000 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: <56BA5106.8050101@hawaii.edu> On 2016/02/09 6:52 AM, Benjamin Root wrote: > The Tk backend, oddly enough, is implemented in C/C++ (don't ask me why, > I haven't a clue) Only a rather small part of it. And there is a similar C++ component for the GTKagg backend. Eric From efiring at hawaii.edu Tue Feb 9 15:54:49 2016 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 9 Feb 2016 10:54:49 -1000 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: <56BA5219.1040207@hawaii.edu> On 2016/02/09 6:52 AM, Benjamin Root wrote: > It is the figure/axes/axis relationships for defining properties at the > right time (lots of multiple-inheritance confusion) as well as the > figure/canvas/manager relationships for interactivity. I don't think multiple inheritance is such a problem in the mpl codebase, but I find that circular references and long chains of indirection can make it difficult to figure out what is going on. Eric From ben.v.root at gmail.com Tue Feb 9 16:02:03 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Tue, 9 Feb 2016 16:02:03 -0500 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: <56BA5219.1040207@hawaii.edu> References: <56BA5219.1040207@hawaii.edu> Message-ID: On Tue, Feb 9, 2016 at 3:54 PM, Eric Firing wrote: > I don't think multiple inheritance is such a problem in the mpl codebase, > but I find that circular references and long chains of indirection can make > it difficult to figure out what is going on. What I have found confusing as heck is the initialization chain for an axes with a non-default transform. The indirection and multiple inheritance both confounded my ability to understand exactly what was getting initialized when and how. It is the main reason why mplot3d still doesn't operate on top of the transforms stack, preventing me from implementing the log scale feature. > Only a rather small part of it. And there is a similar C++ component for the GTKagg backend. Ah, I forgot about that thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue Feb 9 17:27:13 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Tue, 9 Feb 2016 14:27:13 -0800 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: On Tue, Feb 9, 2016 at 8:52 AM, Benjamin Root wrote: > as well as the figure/canvas/manager relationships for interactivity. > this is a big one -- I tried to debug the wxAgg backend once, and it was simply littered with calls to render the screen -- and it was next to impossible to figure out when rendering was actually supposed to happen. I suspect class were simply added all over the place until it seemed to work. I can image other back-end suffer from the same issues. -CHB -- 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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Tue Feb 9 17:37:59 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Tue, 9 Feb 2016 17:37:59 -0500 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: Funny story... in the WxAgg section of my book, the original draft had the phrase "... add a call to `canvas.draw()` here because sometimes Wx needs a kick in the butt.". The editors made me change that... Ben Root On Tue, Feb 9, 2016 at 5:27 PM, Chris Barker wrote: > On Tue, Feb 9, 2016 at 8:52 AM, Benjamin Root > wrote: > >> as well as the figure/canvas/manager relationships for interactivity. >> > > this is a big one -- I tried to debug the wxAgg backend once, and it was > simply littered with calls to render the screen -- and it was next to > impossible to figure out when rendering was actually supposed to happen. I > suspect class were simply added all over the place until it seemed to work. > > I can image other back-end suffer from the same issues. > > > > > -CHB > > -- > > 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 > > Chris.Barker at noaa.gov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Wed Feb 10 01:22:08 2016 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Tue, 9 Feb 2016 22:22:08 -0800 Subject: [Matplotlib-devel] matplotlib limitations and design flaws Message-ID: Dear matplotlib developers (and users): I've expanded my web page "Python Limitations and Design Flaws" to include a good-size section on matplotlib (item number 3). The URL is as follows: http://phillipmfeldman.org/Python/Python_Limitations.html All feedback other than flames is welcome! Phillip -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Wed Feb 10 01:26:42 2016 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 9 Feb 2016 22:26:42 -0800 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: Message-ID: Pull requests are welcome! On Tue, Feb 9, 2016 at 10:22 PM, Phillip Feldman wrote: > Dear matplotlib developers (and users): > > I've expanded my web page "Python Limitations and Design Flaws" to include a > good-size section on matplotlib (item number 3). The URL is as follows: > > http://phillipmfeldman.org/Python/Python_Limitations.html > > All feedback other than flames is welcome! > > Phillip > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger at calpoly.edu and ellisonbg at gmail.com From efiring at hawaii.edu Wed Feb 10 02:29:56 2016 From: efiring at hawaii.edu (Eric Firing) Date: Tue, 9 Feb 2016 21:29:56 -1000 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: Message-ID: <56BAE6F4.5000203@hawaii.edu> On 2016/02/09 8:22 PM, Phillip Feldman wrote: > Dear matplotlib developers (and users): > > I've expanded my web page "Python Limitations and Design Flaws" to > include a good-size section on matplotlib (item number 3). The URL is > as follows: > > http://phillipmfeldman.org/Python/Python_Limitations.html > > All feedback other than flames is welcome! Regarding the polar plot, you are correct that there is an odd situation where angles are input in radians and labeled in degrees, but I think your description is incorrect. The inconsistency is entirely with the azimuth. The radial labels are labeling the radial coordinate, which has whatever dimensions are appropriate for the data at hand, unlike the azimuth, which is dimensionless. The radial coordinate is correctly labeled with the numbers you supplied. Regarding the figure margin default: first, this presently applies only to the figure on screen, not to figures written to a file; and second, as soon as we get 2.0 out, the default will be for the margin to be white in both cases. Regarding the "Plot titles are by default jammed against...", I don't think this is true for the full set of defaults, so I don't know what is leading you to this conclusion; but a genuine weakness is that we lack a layout engine, so tweaking of the sort you suggest is indeed needed all too often. Regarding the positional arguments to contour and contourf: yes, this is an unfortunate result of the initial design of the pylab interface to be close to Matlab, so as to make it easy for Matlab users to switch. Regarding your first point, "lack of uniformity among the interfaces": I think all of the developers would agree that this is a problem. It arose from matplotlib's organic growth, and we are gradually trying to address it. Regarding your very first point, "Block Comments", I agree that it would be nice to be able to use C-style /* and */, for example, but I find the lack to be a very minor point. My workaround is to indent the block and insert the line "if False:" above it. Eric > > Phillip > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From ben.v.root at gmail.com Wed Feb 10 10:09:10 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Wed, 10 Feb 2016 10:09:10 -0500 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: <56BAE6F4.5000203@hawaii.edu> References: <56BAE6F4.5000203@hawaii.edu> Message-ID: If I feel the need to have a block comment, I have learned that that usually means: 1) My logic is too complicated and needs to be cleaned up or broken up into smaller chuncks 2) That the comment might be better as a docstring And if I need to temporarily "comment out" a chunk of code, triple quoting works great. On Wed, Feb 10, 2016 at 2:29 AM, Eric Firing wrote: > On 2016/02/09 8:22 PM, Phillip Feldman wrote: > >> Dear matplotlib developers (and users): >> >> I've expanded my web page "Python Limitations and Design Flaws" to >> include a good-size section on matplotlib (item number 3). The URL is >> as follows: >> >> http://phillipmfeldman.org/Python/Python_Limitations.html >> >> All feedback other than flames is welcome! >> > > Regarding the polar plot, you are correct that there is an odd situation > where angles are input in radians and labeled in degrees, but I think your > description is incorrect. The inconsistency is entirely with the azimuth. > The radial labels are labeling the radial coordinate, which has whatever > dimensions are appropriate for the data at hand, unlike the azimuth, which > is dimensionless. The radial coordinate is correctly labeled with the > numbers you supplied. > > Regarding the figure margin default: first, this presently applies only to > the figure on screen, not to figures written to a file; and second, as soon > as we get 2.0 out, the default will be for the margin to be white in both > cases. > > Regarding the "Plot titles are by default jammed against...", I don't > think this is true for the full set of defaults, so I don't know what is > leading you to this conclusion; but a genuine weakness is that we lack a > layout engine, so tweaking of the sort you suggest is indeed needed all too > often. > > Regarding the positional arguments to contour and contourf: yes, this is > an unfortunate result of the initial design of the pylab interface to be > close to Matlab, so as to make it easy for Matlab users to switch. > > Regarding your first point, "lack of uniformity among the interfaces": I > think all of the developers would agree that this is a problem. It arose > from matplotlib's organic growth, and we are gradually trying to address it. > > Regarding your very first point, "Block Comments", I agree that it would > be nice to be able to use C-style /* and */, for example, but I find the > lack to be a very minor point. My workaround is to indent the block and > insert the line "if False:" above it. > > Eric > > > >> Phillip >> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmhobson at gmail.com Wed Feb 10 11:03:19 2016 From: pmhobson at gmail.com (Paul Hobson) Date: Wed, 10 Feb 2016 08:03:19 -0800 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: On Wed, Feb 10, 2016 at 7:09 AM, Benjamin Root wrote: > If I feel the need to have a block comment, I have learned that that > usually means: > 1) My logic is too complicated and needs to be cleaned up or broken up > into smaller chuncks > 2) That the comment might be better as a docstring > > And if I need to temporarily "comment out" a chunk of code, triple quoting > works great. > To add to that, thanks to modern text editors, languages don't need block comments any more. Ctrl + / should comment out a chunk of text on most editors that I've used (Save for e.g., vim). -p -------------- next part -------------- An HTML attachment was scrubbed... URL: From joferkington at gmail.com Wed Feb 10 11:41:19 2016 From: joferkington at gmail.com (Joe Kington) Date: Wed, 10 Feb 2016 10:41:19 -0600 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: > Ctrl + / should comment out a chunk of text on most editors that I've > used (Save for e.g., vim). > And it's pretty trivial to set up in vim (note that you'd tupically customize comment marker on a per-language basis through an autocmd function). This maps commenting out a block to "-" and uncommenting to "_": " Clear all comment markers (one rule for all languages) map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//:nohlsearch "Insert comment markers (assumes # unless overridden) map - :s/^/#/:nohlsearch There are also smarter options through various plugins, as well. At any rate, block commenting isn't something I've ever missed or felt was a limitation in any way, though that's just my $0.02. Cheers, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmay31 at gmail.com Wed Feb 10 12:12:20 2016 From: rmay31 at gmail.com (Ryan May) Date: Wed, 10 Feb 2016 10:12:20 -0700 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: A point in favor of not using block comments is that it is *much* harder to exclude block commented code from greps/regex. If you comment every line, that makes excluding those lines trivial. Ryan On Wed, Feb 10, 2016 at 9:41 AM, Joe Kington wrote: > > Ctrl + / should comment out a chunk of text on most editors that I've >> used (Save for e.g., vim). >> > > And it's pretty trivial to set up in vim (note that you'd tupically > customize comment marker on a per-language basis through an autocmd > function). This maps commenting out a block to "-" and uncommenting to "_": > > " Clear all comment markers (one rule for all languages) > map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//:nohlsearch > "Insert comment markers (assumes # unless overridden) > map - :s/^/#/:nohlsearch > > There are also smarter options through various plugins, as well. > > At any rate, block commenting isn't something I've ever missed or felt was > a limitation in any way, though that's just my $0.02. > > Cheers, > -Joe > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Wed Feb 10 14:32:39 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 10 Feb 2016 11:32:39 -0800 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: On Tue, Feb 9, 2016 at 2:37 PM, Benjamin Root wrote: > Funny story... in the WxAgg section of my book, the original draft had the > phrase "... add a call to `canvas.draw()` here because sometimes Wx needs a > kick in the butt.". The editors made me change that... > darn -- you should have snuck that back in ..... -CHB > > Ben Root > > > On Tue, Feb 9, 2016 at 5:27 PM, Chris Barker > wrote: > >> On Tue, Feb 9, 2016 at 8:52 AM, Benjamin Root >> wrote: >> >>> as well as the figure/canvas/manager relationships for interactivity. >>> >> >> this is a big one -- I tried to debug the wxAgg backend once, and it was >> simply littered with calls to render the screen -- and it was next to >> impossible to figure out when rendering was actually supposed to happen. I >> suspect class were simply added all over the place until it seemed to work. >> >> I can image other back-end suffer from the same issues. >> >> >> >> >> -CHB >> >> -- >> >> 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 >> >> Chris.Barker at noaa.gov >> > > -- 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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroettboom at continuum.io Wed Feb 10 23:48:50 2016 From: mdroettboom at continuum.io (Michael Droettboom) Date: Wed, 10 Feb 2016 23:48:50 -0500 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: Anyone who is interested in matplotlib?s architecture may be interested in a referred paper John and I wrote about it a few years ago (which is still mostly current): http://www.aosabook.org/en/matplotlib.html On Tue, Feb 9, 2016 at 11:52 AM, Benjamin Root wrote: Excerpt response to a private query about matplotlib's architecture. Some > has asked me to post it as a possible addition to development docs. > > > All of matplotlib started off as pure python. As time went on, it was > re-worked into a backend/frontend design. The frontend is mostly in python, > with critical portions, such as path and vector handling implemented in > C++. We are also heavily reliant upon NumPy and use its C-API in those C++ > parts. > I wouldn?t say heavily reliant ? it?s actually deliberately loosely coupled. All of the Numpy usage is isolated to one file (numpy_cpp.h), such that it can be replaced to use the new Python buffer protocol and memoryviews once we?ve dropped support for Python 2.6 (which we?ve done, we just haven?t gotten around to using the buffer protocol yet). All that is just to have an abstract way of passing large binary arrays between Python and C++. Numpy isn?t used from the C++ side for anything another than passing buffers across the language barrier. We also call out to various other libraries such as libfreetype to perform > our font-handling. The frontend is also a bit of a misnomer, because it > isn't really at the front, as most people are familiar with the pyplot > interface, which sits on top of the frontend. > We don?t really use the term ?frontend? in the code base anyway. We usually refer to the ?Object-Oriented API? and the ?pyplot API?. > The backends are what allows us to output the figures to the many > different "devices" (filetypes, GUI toolkits, etc.). Most are implemented > in python using the respective GUI toolkit's python bindings. The Tk > backend, oddly enough, is implemented in C/C++ (don't ask me why, I haven't > a clue), > This is because Tkinter does not have an API to pass a binary image buffer from Python to be displayed on the screen. We therefore had to write a very small extension to Tk to do that. Same is true of the Gtk 2 backend. The other more modern toolkits all have this API built-in, so we don?t have to provide it ourselves. and the macosx backend is implemented in Obj-C. The AGG backend is > implemented in C++. PDF and PS backends are implemented in python as well. > > AGG is critically important to matplotlib's functionality. Not only does > it serve as the default headless backend, and is often mixed with the GUI > backends (TkAgg, Qt4Agg, etc.) to produce consistent results across all > platforms, it also serves as the basis for our image-handling architecture. > Just to elaborate on this: matplotlib really has two types of backends: rendering backends and GUI backends. The rendering backends actually perform the drawing either by rasterizing or outputting to a vector filetype. These include Agg (which rasterizes), Pdf, Ps, Svg and Cairo. The GUI backends create windows, copy a rendered buffer to the screen, and provide toolbars and interaction etc. These include TkAgg, WxAgg, QtAgg, GtkAgg etc. There are also some hybrid backends that do both, such as the Mac OSX backend and the mostly deprecated Gdk and Wx backends. > This is a very broad-brush overview of the matplotlib architecture. It > isn't a simple layered system, unfortunately, but we do have some critical > portions off-loaded to C/C++ or NumPy. Probably some of the most > difficult-to-understand portions of the codebase isn't those parts, though. > It is the figure/axes/axis relationships for defining properties at the > right time (lots of multiple-inheritance confusion) > We don?t use a lot of multiple inheritance, and when we do, it?s usually just as a mixin pattern. as well as the figure/canvas/manager relationships for interactivity. > These are indeed a bit tricky to understand, but are fairly well-documented in backend_base.py Cheers, Mike > > Cheers! > Ben Root > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > ? -- Michael Droettboom Continuum Analytics -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroettboom at continuum.io Wed Feb 10 23:52:43 2016 From: mdroettboom at continuum.io (Michael Droettboom) Date: Wed, 10 Feb 2016 23:52:43 -0500 Subject: [Matplotlib-devel] Response to architecture query In-Reply-To: References: Message-ID: On Tue, Feb 9, 2016 at 5:27 PM, Chris Barker wrote: > On Tue, Feb 9, 2016 at 8:52 AM, Benjamin Root > wrote: > >> as well as the figure/canvas/manager relationships for interactivity. >> > > this is a big one -- I tried to debug the wxAgg backend once, and it was > simply littered with calls to render the screen -- and it was next to > impossible to figure out when rendering was actually supposed to happen. > The relationship between the backend classes is documented in `backend_base.py`. The interaction is essentially: 1) The GUI framework receives an event to redraw the window 2) This triggers the `paint` callback method 3) This calls the figure's draw method which renders the figure into an image buffer 4) The image buffer is copied to the window's image buffer 5) The GUI framework through layers of abstraction we don't have to concern ourselves with paints the window's image buffer to the screen > I suspect class were simply added all over the place until it seemed to > work. > The backend classes are actually some of the better-reasoned parts of the code base. For more information, see http://www.aosabook.org/en/matplotlib.html > > I can image other back-end suffer from the same issues. > > > > > -CHB > > -- > > 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 > > Chris.Barker at noaa.gov > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -- Michael Droettboom Continuum Analytics -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Mon Feb 15 02:19:57 2016 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Sun, 14 Feb 2016 23:19:57 -0800 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: I will correct my discussion of the polar plot example. I'll add something to the discussion of block comments. Re. Ryan's point that it is hard to exclude block commented code from greps/regex: This is equally true of doc strings, and no one is suggesting that we stop using these. Is there any plan to incorporate a layout engine into matplotlib? Phillip P.S. I want to thank everyone for the thoughtful responses. On Wed, Feb 10, 2016 at 9:12 AM, Ryan May wrote: > A point in favor of not using block comments is that it is *much* harder > to exclude block commented code from greps/regex. If you comment every > line, that makes excluding those lines trivial. > > Ryan > > On Wed, Feb 10, 2016 at 9:41 AM, Joe Kington > wrote: > >> >> Ctrl + / should comment out a chunk of text on most editors that I've >>> used (Save for e.g., vim). >>> >> >> And it's pretty trivial to set up in vim (note that you'd tupically >> customize comment marker on a per-language basis through an autocmd >> function). This maps commenting out a block to "-" and uncommenting to "_": >> >> " Clear all comment markers (one rule for all languages) >> map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//:nohlsearch >> "Insert comment markers (assumes # unless overridden) >> map - :s/^/#/:nohlsearch >> >> There are also smarter options through various plugins, as well. >> >> At any rate, block commenting isn't something I've ever missed or felt >> was a limitation in any way, though that's just my $0.02. >> >> Cheers, >> -Joe >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > > > -- > Ryan May > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Feb 15 10:43:55 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 15 Feb 2016 15:43:55 +0000 Subject: [Matplotlib-devel] [Matplotlib-users] paletted PNG backend In-Reply-To: References: Message-ID: Jesper, That is a cool application! I am not sure doing this directly in Agg would be the best place (as I am not sure how to conceptually combine anti-aliasing + compositing + color pallet). I think a better place to extend would be the png writer to directly export a palleted png ( https://github.com/matplotlib/matplotlib/blob/master/src/_png.cpp#L123) from the Agg RBGA buffer. You might also be interested in https://github.com/matplotlib/matplotlib/pull/5389 where Mike did some work to sort out which png settings are fastest. Tom PS The mailing list has moved to matplotlib-devel at python.org please re-subscribe and send future emails there. On Mon, Feb 15, 2016 at 3:19 AM Jesper Larsen wrote: > Hi Matplotlib users, > > We are using Matplotlib for a web service which makes PNG images on the > fly for presentation on a map (web site using the web service is here: > https://ifm-beta.fcoo.dk) > > Performance and image size are two major concerns for us. We therefore > save the resulting RGBA PNG to a buffer and afterwards use Pillow (PIL) to > convert it to a P PNG (paletted PNG) to reduce the image size dramatically. > > This procedure does however use a significant amount of our total > processing time per image. I would therefore be interested in extending > e.g. the AGG backend to produce paletted PNGs directly. I am of course > aware that this might not be useful for many others since one would have to > provide some extra information when rendering with this backend (possibly > output palette and quantizing method). But on the other hand it might be > useful for others doing web services using matplotlib. > > My questions are: > > 1) Is it possible to extend the AGG backend for this and how? > > 2) Is it better to make a separate Pillow based backend for this (Pillow > is probably not as fast as AGG)? > > Best regards, > Jesper > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Feb 15 11:47:03 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 15 Feb 2016 16:47:03 +0000 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: See https://github.com/matplotlib/matplotlib/issues/1109 The consensus seems to be that we should use https://github.com/nucleic/kiwi for solving the linear constraint problem, someone just needs to sort out how to automatically generate the constraint equations from a `Figure` object. The sticking points are going to be dealing with text (which will require a (partial?) 2-pass approach) and how what the user-facing API for tuning the constraints will be. This might be a good GSoC project? Tom On Mon, Feb 15, 2016 at 2:20 AM Phillip Feldman wrote: > I will correct my discussion of the polar plot example. > > I'll add something to the discussion of block comments. Re. Ryan's point > that it is hard to exclude block commented code from greps/regex: This is > equally true of doc strings, and no one is suggesting that we stop using > these. > > Is there any plan to incorporate a layout engine into matplotlib? > > Phillip > > P.S. I want to thank everyone for the thoughtful responses. > > On Wed, Feb 10, 2016 at 9:12 AM, Ryan May wrote: > >> A point in favor of not using block comments is that it is *much* harder >> to exclude block commented code from greps/regex. If you comment every >> line, that makes excluding those lines trivial. >> >> Ryan >> >> On Wed, Feb 10, 2016 at 9:41 AM, Joe Kington >> wrote: >> >>> >>> Ctrl + / should comment out a chunk of text on most editors that I've >>>> used (Save for e.g., vim). >>>> >>> >>> And it's pretty trivial to set up in vim (note that you'd tupically >>> customize comment marker on a per-language basis through an autocmd >>> function). This maps commenting out a block to "-" and uncommenting to "_": >>> >>> " Clear all comment markers (one rule for all languages) >>> map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//:nohlsearch >>> "Insert comment markers (assumes # unless overridden) >>> map - :s/^/#/:nohlsearch >>> >>> There are also smarter options through various plugins, as well. >>> >>> At any rate, block commenting isn't something I've ever missed or felt >>> was a limitation in any way, though that's just my $0.02. >>> >>> Cheers, >>> -Joe >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >>> >> >> >> -- >> Ryan May >> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Mon Feb 15 12:52:17 2016 From: efiring at hawaii.edu (Eric Firing) Date: Mon, 15 Feb 2016 07:52:17 -1000 Subject: [Matplotlib-devel] [Matplotlib-users] paletted PNG backend In-Reply-To: References: Message-ID: <56C21051.9030400@hawaii.edu> I wonder whether we can take advantage of this: https://pngquant.org/. Eric On 2016/02/15 5:43 AM, Thomas Caswell wrote: > Jesper, > > That is a cool application! > > I am not sure doing this directly in Agg would be the best place (as I > am not sure how to conceptually combine anti-aliasing + compositing + > color pallet). I think a better place to extend would be the png writer > to directly export a palleted png > (https://github.com/matplotlib/matplotlib/blob/master/src/_png.cpp#L123) > from the Agg RBGA buffer. > > You might also be interested in > https://github.com/matplotlib/matplotlib/pull/5389 where Mike did some > work to sort out which png settings are fastest. > > Tom > > PS The mailing list has moved to matplotlib-devel at python.org > please re-subscribe and send > future emails there. > > On Mon, Feb 15, 2016 at 3:19 AM Jesper Larsen > wrote: > > Hi Matplotlib users, > > We are using Matplotlib for a web service which makes PNG images on > the fly for presentation on a map (web site using the web service is > here: https://ifm-beta.fcoo.dk) > > Performance and image size are two major concerns for us. We > therefore save the resulting RGBA PNG to a buffer and afterwards use > Pillow (PIL) to convert it to a P PNG (paletted PNG) to reduce the > image size dramatically. > > This procedure does however use a significant amount of our total > processing time per image. I would therefore be interested in > extending e.g. the AGG backend to produce paletted PNGs directly. I > am of course aware that this might not be useful for many others > since one would have to provide some extra information when > rendering with this backend (possibly output palette and quantizing > method). But on the other hand it might be useful for others doing > web services using matplotlib. > > My questions are: > > 1) Is it possible to extend the AGG backend for this and how? > > 2) Is it better to make a separate Pillow based backend for this > (Pillow is probably not as fast as AGG)? > > Best regards, > Jesper > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ > Matplotlib-users mailing list > Matplotlib-users at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From rmay31 at gmail.com Mon Feb 15 21:24:49 2016 From: rmay31 at gmail.com (Ryan May) Date: Mon, 15 Feb 2016 19:24:49 -0700 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: On Mon, Feb 15, 2016 at 12:19 AM, Phillip Feldman < phillip.m.feldman at gmail.com> wrote: > I'll add something to the discussion of block comments. Re. Ryan's point > that it is hard to exclude block commented code from greps/regex: This is > equally true of doc strings, and no one is suggesting that we stop using > these. > > I was only debunking your own specific point about block comments: "A consequence is that there is no good mechanism for temporarily deactivating a large block of code?one must either laboriously comment out each line, or simply delete the block." So for commenting out blocks of code, block comments suck because using block comments means there's no way to exclude the "temporarily" disabled code. It's generally much less often that I'm frustrated by my ability to exclude lines from docstrings in a grep. Given that even Gedit has a plugin for mass commenting lines, I see no problem with the lack of block comments. In fact, when I'm doing C++, I exclusively use the single line '//' rather than the C style '/* */'. So for me, lack of block comments is a *feature* of Python (since you don't end up with two ways to do comments, either). To each their own style...but comments are really one of your 10 biggest gripes about Python? REALLY? Ryan -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Tue Feb 16 00:18:59 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 16 Feb 2016 05:18:59 +0000 Subject: [Matplotlib-devel] cycler v.0.10.0 released Message-ID: Folks, I am happy to announce the next release of Cycler. This will become the minimal version for the upcoming mpl v2.0 release. http://matplotlib.org/cycler/ Feature release for `cycler`. This release includes a number of new features: - `Cycler` objecst learned to generate an `itertools.cycle` by calling them, a-la a generator. - `Cycler` objects learned to change the name of a key via the new `.change_key(old_key, new_key)` method. - `Cycler` objects learned how to compare each other and determine if they are equal or not (`==`). - `Cycler` objects learned how to join another `Cycler` to be concatenated into a singel longer `Cycler` via `concat` method of function. `A.concat(B)` or `concat(A, B)`. - The `cycler` factory function learned to construct a complex `Cycler` from iterables provided as keyword arguments. - `Cycler` objects learn do show their insides with the `by_key` method which returns a dictionary of lists (instead of an iterable of dictionaries). Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From jks at iki.fi Tue Feb 16 06:20:51 2016 From: jks at iki.fi (=?iso-8859-1?Q?Jouni_K=2E_Sepp=E4nen?=) Date: Tue, 16 Feb 2016 13:20:51 +0200 Subject: [Matplotlib-devel] matplotlib limitations and design flaws References: <56BAE6F4.5000203@hawaii.edu> Message-ID: Benjamin Root writes: > And if I need to temporarily "comment out" a chunk of code, triple quoting > works great. You can also insert an "if 0:" indented between your normal indentation levels, and end the block with "if 1:" unless you wanted to comment out to the end of the natural block. -- Jouni K. Sepp?nen http://www.iki.fi/jks From mdroettboom at continuum.io Tue Feb 16 09:29:01 2016 From: mdroettboom at continuum.io (Michael Droettboom) Date: Tue, 16 Feb 2016 09:29:01 -0500 Subject: [Matplotlib-devel] GSoC: Call for mentors Message-ID: Calling all developers: matplotlib plans to participate in Google Summer of Code this year under the Numfocus organization. We'd love your help as mentors. The time committment is generally one weekly check-in meeting with your student, as well as extra time at the beginning and end of the summer. It is a great way to multiply our work over the summer and find new contributors long term. I have proposed an initial list of topics here: https://github.com/numfocus/gsoc/pull/72 If you'd like to volunteer to be a mentor for any of these projects or propose your own, please let me know or file a pull request. Mike -- Michael Droettboom Continuum Analytics -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Tue Feb 16 10:57:56 2016 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Tue, 16 Feb 2016 07:57:56 -0800 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: OK. "if 0:" is a reasonable solution. I will remove the block comment issue. On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen wrote: > Benjamin Root writes: > > > And if I need to temporarily "comment out" a chunk of code, triple > quoting > > works great. > > You can also insert an "if 0:" indented between your normal indentation > levels, and end the block with "if 1:" unless you wanted to comment out > to the end of the natural block. > > -- > Jouni K. Sepp?nen > http://www.iki.fi/jks > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip.m.feldman at gmail.com Tue Feb 16 11:48:28 2016 From: phillip.m.feldman at gmail.com (Phillip Feldman) Date: Tue, 16 Feb 2016 08:48:28 -0800 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: The downside of "if 0:" is that no editor will syntax color this as a comment. On Tue, Feb 16, 2016 at 7:57 AM, Phillip Feldman < phillip.m.feldman at gmail.com> wrote: > OK. "if 0:" is a reasonable solution. I will remove the block comment > issue. > > On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen wrote: > >> Benjamin Root writes: >> >> > And if I need to temporarily "comment out" a chunk of code, triple >> quoting >> > works great. >> >> You can also insert an "if 0:" indented between your normal indentation >> levels, and end the block with "if 1:" unless you wanted to comment out >> to the end of the natural block. >> >> -- >> Jouni K. Sepp?nen >> http://www.iki.fi/jks >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Tue Feb 16 11:53:27 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Tue, 16 Feb 2016 11:53:27 -0500 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: All the more reason why I utilize triple quoting for "commenting out blocks". It may not be syntax-colored for comments, but it is colored obviously differently than code. Another reason not to like /* ... */ for commenting out blocks of code. That is often used for multi-line comments anyway. So, if you have multi-line comments in the code block that you need to comment out, then just doing /* ... */ around that isn't trivial. At least with triple quoting, I can alternate between triple double-quotes and triple single-quotes. On Tue, Feb 16, 2016 at 11:48 AM, Phillip Feldman < phillip.m.feldman at gmail.com> wrote: > The downside of "if 0:" is that no editor will syntax color this as a > comment. > > On Tue, Feb 16, 2016 at 7:57 AM, Phillip Feldman < > phillip.m.feldman at gmail.com> wrote: > >> OK. "if 0:" is a reasonable solution. I will remove the block comment >> issue. >> >> On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen wrote: >> >>> Benjamin Root writes: >>> >>> > And if I need to temporarily "comment out" a chunk of code, triple >>> quoting >>> > works great. >>> >>> You can also insert an "if 0:" indented between your normal indentation >>> levels, and end the block with "if 1:" unless you wanted to comment out >>> to the end of the natural block. >>> >>> -- >>> Jouni K. Sepp?nen >>> http://www.iki.fi/jks >>> >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmay31 at gmail.com Tue Feb 16 12:12:50 2016 From: rmay31 at gmail.com (Ryan May) Date: Tue, 16 Feb 2016 10:12:50 -0700 Subject: [Matplotlib-devel] matplotlib limitations and design flaws In-Reply-To: References: <56BAE6F4.5000203@hawaii.edu> Message-ID: The plus side of `if 0:` is that when it ends up committed to your code base (it shouldn't, but it happens), you can at least be sure that no syntax errors creep in. Ryan On Tue, Feb 16, 2016 at 9:53 AM, Benjamin Root wrote: > All the more reason why I utilize triple quoting for "commenting out > blocks". It may not be syntax-colored for comments, but it is colored > obviously differently than code. > > Another reason not to like /* ... */ for commenting out blocks of code. > That is often used for multi-line comments anyway. So, if you have > multi-line comments in the code block that you need to comment out, then > just doing /* ... */ around that isn't trivial. At least with triple > quoting, I can alternate between triple double-quotes and triple > single-quotes. > > > On Tue, Feb 16, 2016 at 11:48 AM, Phillip Feldman < > phillip.m.feldman at gmail.com> wrote: > >> The downside of "if 0:" is that no editor will syntax color this as a >> comment. >> >> On Tue, Feb 16, 2016 at 7:57 AM, Phillip Feldman < >> phillip.m.feldman at gmail.com> wrote: >> >>> OK. "if 0:" is a reasonable solution. I will remove the block comment >>> issue. >>> >>> On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen wrote: >>> >>>> Benjamin Root writes: >>>> >>>> > And if I need to temporarily "comment out" a chunk of code, triple >>>> quoting >>>> > works great. >>>> >>>> You can also insert an "if 0:" indented between your normal indentation >>>> levels, and end the block with "if 1:" unless you wanted to comment out >>>> to the end of the natural block. >>>> >>>> -- >>>> Jouni K. Sepp?nen >>>> http://www.iki.fi/jks >>>> >>>> _______________________________________________ >>>> Matplotlib-devel mailing list >>>> Matplotlib-devel at python.org >>>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>>> >>> >>> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> >> > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Wed Feb 17 13:23:07 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 17 Feb 2016 10:23:07 -0800 Subject: [Matplotlib-devel] [Matplotlib-users] paletted PNG backend In-Reply-To: References: Message-ID: > On Mon, Feb 15, 2016 at 3:19 AM Jesper Larsen > wrote: > >> We are using Matplotlib for a web service which makes PNG images on the >> fly for presentation on a map (web site using the web service is here: >> https://ifm-beta.fcoo.dk) >> >> Performance and image size are two major concerns for us. We therefore >> save the resulting RGBA PNG to a buffer and afterwards use Pillow (PIL) to >> convert it to a P PNG (paletted PNG) to reduce the image size dramatically. >> > We have similar issues, though not with MPL -- in fact one reason we are not using MPL is because we want highly optimized rendering -- all the features MPL provides do add overhead... And doing experiments with various rendering engines (PIL, AGG, SKIA, GD) with found that they all have pretty darn similar performance, but that performance scales pretty much with how many bytes you are pushing -- i.e. larger images take longer to render, and 8 bits per pixel is faster than 32 bits per pixel (by pretty much a factor of four, if I recall). So while you are now taking a lot of time converting, you might also get faster rendering in the first place if you use 8bpp rendering. But, as Thomas suggested, AGG is pretty much all about anti-aliasing and that requires more than 255 colors.... So: the "right" way to solve this problem is to use a non-anti-aliasing, 8bpp rendering lib. You could make a new back-end that uses that instead of AGG. ONE of the core MPLS devs (I can't remember who) suggested that MPL could use a maybe-not-the-best-quality-but-fast back end last year at SciPy, so maybe you'll get some help if you want to do it. Also, a non-anti-aliasing back-end would be nice for things like contours where you can get anti-aliasing artifacts where adjacent polygons are supposed to line up exactly. I suggest the libgd rendering lib: https://github.com/libgd/libgd It's not seeing a massive amount of development, but that's because it's been around forever and is pretty darn robust and stable. It's also got an ancient, semi-ugly C API, but we can deal with that :-) If you want to make a MP back end with it, I suggest you start with my Cython-based python wrapper: https://github.com/NOAA-ORR-ERD/py_gd It's not terribly complete, but provides the core functionality for rendering 8 bit images, and numpy interactivity -- i.e. passing coordinates of large polygons as a numpy array, and passing the raw image data in and out as a numpy array. I've also got conda packages for libgd and py_gd in our channel here: https://conda.anaconda.org/noaa-orr-erd The recipes for those are here: https://github.com/NOAA-ORR-ERD/orr-conda-recipes Honestly, AGG has been pretty integral to MPL from the beginning (Or near beginning), so I'm not sure how hard it would be to drop in a new renderer, but I'd be glad to help. 2) Is it better to make a separate Pillow based backend for this (Pillow is >> probably not as fast as AGG)? >> > NOTE: we looked at using PIL for our rendering, and it was kind-of-sort of fast enough, but the rendering code, and python calls to it is all hand-written C, so it looked a lot harder to extend and optimize performance for. With py_gd, we can direct calls to the C lib form numpy arrays directly, and write time-sensitive loops in cython where there are speed bottlenecks. One issue that will take a bit of effort is colormaps -- IIUC, MPL pretty much assumes 32 bit (or 24 bit anyway) color. With 8bpp, colormaps have to be limited to 255 colors, and, in practice, you probably want to save a few "pure" colors for rendering text and the axes, etc: transparent, white, black -- a few others? I think you could get a fine colormap with, say 245 colors, saving 10 for other uses, but then you could only have one colormap in use at a time. So there may be some working around MPL's colormap code for this.... -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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.webmail at gmail.com Wed Feb 17 16:52:00 2016 From: jesper.webmail at gmail.com (Jesper Larsen) Date: Wed, 17 Feb 2016 22:52:00 +0100 Subject: [Matplotlib-devel] [Matplotlib-users] paletted PNG backend In-Reply-To: References: Message-ID: Hi Thomas Thanks for your reply. The pull request by mdboom actually led me to find an undocumented option in Pillow to set the compression level (we now use compress_level=7). This reduced the cost of producing the paletted PNG very much with very little effort. We are however still interested in improving the performance further. And the information that you have provided is definitely useful for this Best regards, Jesper 2016-02-15 16:43 GMT+01:00 Thomas Caswell : > Jesper, > > That is a cool application! > > I am not sure doing this directly in Agg would be the best place (as I am > not sure how to conceptually combine anti-aliasing + compositing + color > pallet). I think a better place to extend would be the png writer to > directly export a palleted png ( > https://github.com/matplotlib/matplotlib/blob/master/src/_png.cpp#L123) > from the Agg RBGA buffer. > > You might also be interested in > https://github.com/matplotlib/matplotlib/pull/5389 where Mike did some > work to sort out which png settings are fastest. > > Tom > > PS The mailing list has moved to matplotlib-devel at python.org please > re-subscribe and send future emails there. > > On Mon, Feb 15, 2016 at 3:19 AM Jesper Larsen > wrote: > >> Hi Matplotlib users, >> >> We are using Matplotlib for a web service which makes PNG images on the >> fly for presentation on a map (web site using the web service is here: >> https://ifm-beta.fcoo.dk) >> >> Performance and image size are two major concerns for us. We therefore >> save the resulting RGBA PNG to a buffer and afterwards use Pillow (PIL) to >> convert it to a P PNG (paletted PNG) to reduce the image size dramatically. >> >> This procedure does however use a significant amount of our total >> processing time per image. I would therefore be interested in extending >> e.g. the AGG backend to produce paletted PNGs directly. I am of course >> aware that this might not be useful for many others since one would have to >> provide some extra information when rendering with this backend (possibly >> output palette and quantizing method). But on the other hand it might be >> useful for others doing web services using matplotlib. >> >> My questions are: >> >> 1) Is it possible to extend the AGG backend for this and how? >> >> 2) Is it better to make a separate Pillow based backend for this (Pillow >> is probably not as fast as AGG)? >> >> Best regards, >> Jesper >> >> >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.webmail at gmail.com Wed Feb 17 16:57:57 2016 From: jesper.webmail at gmail.com (Jesper Larsen) Date: Wed, 17 Feb 2016 22:57:57 +0100 Subject: [Matplotlib-devel] [Matplotlib-users] paletted PNG backend In-Reply-To: References: Message-ID: Hi Chris gd seems like a great candidate for 8-bit rendering (which is what we want). And thanks for the insights into PIL. I will look more into the links you provided. Best regards, Jesper 2016-02-17 19:23 GMT+01:00 Chris Barker : > > On Mon, Feb 15, 2016 at 3:19 AM Jesper Larsen >> wrote: >> >>> We are using Matplotlib for a web service which makes PNG images on the >>> fly for presentation on a map (web site using the web service is here: >>> https://ifm-beta.fcoo.dk) >>> >>> Performance and image size are two major concerns for us. We therefore >>> save the resulting RGBA PNG to a buffer and afterwards use Pillow (PIL) to >>> convert it to a P PNG (paletted PNG) to reduce the image size dramatically. >>> >> > We have similar issues, though not with MPL -- in fact one reason we are > not using MPL is because we want highly optimized rendering -- all the > features MPL provides do add overhead... > > And doing experiments with various rendering engines (PIL, AGG, SKIA, GD) > with found that they all have pretty darn similar performance, but that > performance scales pretty much with how many bytes you are pushing -- i.e. > larger images take longer to render, and 8 bits per pixel is faster than 32 > bits per pixel (by pretty much a factor of four, if I recall). > > So while you are now taking a lot of time converting, you might also get > faster rendering in the first place if you use 8bpp rendering. > > But, as Thomas suggested, AGG is pretty much all about anti-aliasing and > that requires more than 255 colors.... > > So: the "right" way to solve this problem is to use a non-anti-aliasing, > 8bpp rendering lib. You could make a new back-end that uses that instead of > AGG. ONE of the core MPLS devs (I can't remember who) suggested that MPL > could use a maybe-not-the-best-quality-but-fast back end last year at > SciPy, so maybe you'll get some help if you want to do it. > > Also, a non-anti-aliasing back-end would be nice for things like contours > where you can get anti-aliasing artifacts where adjacent polygons are > supposed to line up exactly. > > I suggest the libgd rendering lib: > > https://github.com/libgd/libgd > > It's not seeing a massive amount of development, but that's because it's > been around forever and is pretty darn robust and stable. It's also got an > ancient, semi-ugly C API, but we can deal with that :-) > > If you want to make a MP back end with it, I suggest you start with my > Cython-based python wrapper: > > https://github.com/NOAA-ORR-ERD/py_gd > > It's not terribly complete, but provides the core functionality for > rendering 8 bit images, and numpy interactivity -- i.e. passing coordinates > of large polygons as a numpy array, and passing the raw image data in and > out as a numpy array. > > I've also got conda packages for libgd and py_gd in our channel here: > > https://conda.anaconda.org/noaa-orr-erd > > The recipes for those are here: > > https://github.com/NOAA-ORR-ERD/orr-conda-recipes > > Honestly, AGG has been pretty integral to MPL from the beginning (Or near > beginning), so I'm not sure how hard it would be to drop in a new renderer, > but I'd be glad to help. > > 2) Is it better to make a separate Pillow based backend for this (Pillow >>> is probably not as fast as AGG)? >>> >> > NOTE: we looked at using PIL for our rendering, and it was kind-of-sort of > fast enough, but the rendering code, and python calls to it is all > hand-written C, so it looked a lot harder to extend and optimize > performance for. > > With py_gd, we can direct calls to the C lib form numpy arrays directly, > and write time-sensitive loops in cython where there are speed bottlenecks. > > One issue that will take a bit of effort is colormaps -- IIUC, MPL pretty > much assumes 32 bit (or 24 bit anyway) color. With 8bpp, colormaps have to > be limited to 255 colors, and, in practice, you probably want to save a few > "pure" colors for rendering text and the axes, etc: transparent, white, > black -- a few others? > > I think you could get a fine colormap with, say 245 colors, saving 10 for > other uses, but then you could only have one colormap in use at a time. So > there may be some working around MPL's colormap code for this.... > > -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 > > Chris.Barker at noaa.gov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Sat Feb 20 14:54:23 2016 From: efiring at hawaii.edu (Eric Firing) Date: Sat, 20 Feb 2016 09:54:23 -1000 Subject: [Matplotlib-devel] PR testing is broken? Message-ID: <56C8C46F.60300@hawaii.edu> I submitted a PR to master, and to my surprise, neither Travis nor Appveyor started up. Is this a github glitch, or is something broken on our side? Eric From steven.silvester at gmail.com Sat Feb 20 15:33:41 2016 From: steven.silvester at gmail.com (Steven Silvester) Date: Sat, 20 Feb 2016 20:33:41 +0000 (UTC) Subject: [Matplotlib-devel] PR testing is broken? In-Reply-To: <56C8C46F.60300@hawaii.edu> References: <56C8C46F.60300@hawaii.edu> Message-ID: <696A853E9E292AF5.50C7BBD3-570E-42F0-A3D5-7E46BFA15A5A@mail.outlook.com> I've been seeing this all week with Jupyter repos. ?The solution has been to close/reopen. Regards, Steve Sent from Outlook Mobile On Sat, Feb 20, 2016 at 11:54 AM -0800, "Eric Firing" wrote: I submitted a PR to master, and to my surprise, neither Travis nor Appveyor started up. Is this a github glitch, or is something broken on our side? Eric _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel at python.org https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Sat Feb 20 16:02:07 2016 From: efiring at hawaii.edu (Eric Firing) Date: Sat, 20 Feb 2016 11:02:07 -1000 Subject: [Matplotlib-devel] PR testing is broken? In-Reply-To: <696A853E9E292AF5.50C7BBD3-570E-42F0-A3D5-7E46BFA15A5A@mail.outlook.com> References: <56C8C46F.60300@hawaii.edu> <696A853E9E292AF5.50C7BBD3-570E-42F0-A3D5-7E46BFA15A5A@mail.outlook.com> Message-ID: <56C8D44F.4000903@hawaii.edu> Steve, Thanks, it worked! Eric On 2016/02/20 10:33 AM, Steven Silvester wrote: > I've been seeing this all week with Jupyter repos. The solution has > been to close/reopen. > > Regards, > > Steve > > Sent from Outlook Mobile > > > > > On Sat, Feb 20, 2016 at 11:54 AM -0800, "Eric Firing" > > wrote: > > I submitted a PR to master, and to my surprise, neither Travis nor > Appveyor started up. Is this a github glitch, or is something broken on > our side? > > Eric > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > From chris.barker at noaa.gov Mon Feb 22 17:27:34 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Mon, 22 Feb 2016 14:27:34 -0800 Subject: [Matplotlib-devel] wxMPL status? Message-ID: Hi all, Anyone know what's up with wxMPL? It looks like Ken hasn't updated in soe time, and it doesn't work with recent MPLs: from matplotlib.axes import _process_plot_var_args ImportError: cannot import name _process_plot_var_args We had a discussion about this a good while back: https://sourceforge.net/p/matplotlib/mailman/message/29770257/ anything ever come of that??? -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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Tue Feb 23 17:53:26 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Tue, 23 Feb 2016 14:53:26 -0800 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: On Mon, Feb 22, 2016 at 4:37 PM, Carlo Segre wrote: > If I get some time I hope to add the patches. > That would be great -- we should make a gitHub project for it -- would you like to do that, or should I? or... On Tue, Feb 23, 2016 at 2:23 PM, Matt Newville wrote: > Development (https://github.com/newville/wxmplot) isn't fast, but it is > not dead either. > > My recollection was that there was a lot of overlap in functionality, > between wxmplot and wxmpl. > > What uses of wxmpl would need to be ported and/or translated (or some > combination) to wxmplot to fit your needs? > Boy, I have no idea! Back in teh day, I decided that wxMPL fit my needs a bit better, but I can't recall why...IT is lighter weight, but I don't know that the extra weight is a problem at all... So our next step is going to be to take a look at wxmplot, and if it fits the use case at hand, great! if not I guess we'll figure out if it's easier to patch wxmplot of wxmpl to work for us. Stay tuned... But: I also have to say that the lack of wxPython (and matplotib+wx > backend) for Python3 is a major concern. If matplotlib's wx backend > supported Phoenix, I'd be more inclined to work on this. As it is, there > is not much evidence that investing significant time in wxPython-based > libraries is a good use of time. > Any idea what it would take for MPL to support Phoenix? Honestly, I haven't given Phoenix a real try at all yet. I"ve got a handful of small apps (and one biggish one) that are wx based, but not in active enough development to want to deal with porting to py2 or Phoenix... So, while I'm sympathetic and willing to help some, I'm more concerned > about the very sad state of wxPython. > yeah -- the irony is that Robin has been working on PySide for the last while.... but while slow, wxPython still seems to have a good community, and Phoenix does appear to be pretty close to operational....IT jsut needs some prodding along, I suppose. For my part, we are doing a lot more with Web apps, which I why I've had little time for wx lately.... Thanks, -CHB -- 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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Wed Feb 24 10:26:50 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Wed, 24 Feb 2016 10:26:50 -0500 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: On Tue, Feb 23, 2016 at 5:53 PM, Chris Barker wrote: > But: I also have to say that the lack of wxPython (and matplotib+wx >> backend) for Python3 is a major concern. If matplotlib's wx backend >> supported Phoenix, I'd be more inclined to work on this. As it is, there >> is not much evidence that investing significant time in wxPython-based >> libraries is a good use of time. >> > > Any idea what it would take for MPL to support Phoenix? Honestly, I > haven't given Phoenix a real try at all yet. I"ve got a handful of small > apps (and one biggish one) that are wx based, but not in active enough > development to want to deal with porting to py2 or Phoenix... > Uhm, Phoenix should be supported: https://github.com/matplotlib/matplotlib/pulls?utf8=%E2%9C%93&q=is%3Apr+phoenix -- at least, experimentally given that at the time of these PRs, phoenix wasn't finalized. Ben Root -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Wed Feb 24 11:27:08 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 24 Feb 2016 08:27:08 -0800 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: On Wed, Feb 24, 2016 at 7:26 AM, Benjamin Root wrote: > Uhm, Phoenix should be supported: > https://github.com/matplotlib/matplotlib/pulls?utf8=%E2%9C%93&q=is%3Apr+phoenix > -- at least, experimentally given that at the time of these PRs, phoenix > wasn't finalized. > Awesome! I'll need to give it a try some day... -- 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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Thu Feb 25 12:49:07 2016 From: chris.barker at noaa.gov (Chris Barker) Date: Thu, 25 Feb 2016 09:49:07 -0800 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: Matt et al, WE probably shoudld jsut got to wxmplot -- but in the meantime, I created a gitHub project for a fork of wxmpl: https://github.com/NOAA-ORR-ERD/wxmpl I've fixed the immediate mpl import issue, but now there are issues with a newer wxPython -- at least with the demos. Hopefully I'll get to those later today. Carlo, let me know if you want write permissions on that repo -- or want to set it up yourself somewhere else.. -CHB On Thu, Feb 25, 2016 at 5:44 AM, Matt Newville wrote: > HI Chris, > > > On Tue, Feb 23, 2016 at 4:53 PM, Chris Barker > wrote: > >> On Mon, Feb 22, 2016 at 4:37 PM, Carlo Segre wrote: >> >>> If I get some time I hope to add the patches. >>> >> >> That would be great -- we should make a gitHub project for it -- would >> you like to do that, or should I? >> >> or... >> >> >> > On Tue, Feb 23, 2016 at 2:23 PM, Matt Newville > > wrote: >> >> >>> Development (https://github.com/newville/wxmplot) isn't fast, but it is >>> not dead either. >>> >>> My recollection was that there was a lot of overlap in functionality, >>> between wxmplot and wxmpl. >>> >> >> >>> What uses of wxmpl would need to be ported and/or translated (or some >>> combination) to wxmplot to fit your needs? >>> >> >> Boy, I have no idea! Back in teh day, I decided that wxMPL fit my needs a >> bit better, but I can't recall why...IT is lighter weight, but I don't know >> that the extra weight is a problem at all... >> >> So our next step is going to be to take a look at wxmplot, and if it fits >> the use case at hand, great! if not I guess we'll figure out if it's easier >> to patch wxmplot of wxmpl to work for us. >> >> Stay tuned... >> > > OK. I think a transition from wxmpl to wxmplot might not be hard. If > there is anything that's missing in wxmplot that would make that transition > easier, let's add it. > > >> But: I also have to say that the lack of wxPython (and matplotib+wx >>> backend) for Python3 is a major concern. If matplotlib's wx backend >>> supported Phoenix, I'd be more inclined to work on this. As it is, there >>> is not much evidence that investing significant time in wxPython-based >>> libraries is a good use of time. >>> >> >> Any idea what it would take for MPL to support Phoenix? Honestly, I >> haven't given Phoenix a real try at all yet. I"ve got a handful of small >> apps (and one biggish one) that are wx based, but not in active enough >> development to want to deal with porting to py2 or Phoenix... >> >> So, while I'm sympathetic and willing to help some, I'm more concerned >>> about the very sad state of wxPython. >>> >> >> yeah -- the irony is that Robin has been working on PySide for the last >> while.... >> >> but while slow, wxPython still seems to have a good community, and >> Phoenix does appear to be pretty close to operational....IT jsut needs some >> prodding along, I suppose. >> >> > Actually, Benjamin Root is correct, and I should correct my earlier > remarks. > > Using matplotlib 1.5.1 and wxPython Phoenix 3.0.3.dev1839+4ecd949 works > well, and I've verified that almost all of the wxmplot examples work > without any modification at all. I've only tested with Python 2.7 > (Python 2.7.11 from Anaconda 2.4.1 on Mac OS X to be precise). There are > a lot of differences between Phoenix and Classic, so wxmplot will need some > small modifications and version-checking code for everything to work. > There will no doubt be changes need for Python3, but I suspect not too > many. > > This is really, really good news! Thanks very much matplotlib-dev team! > > For my part, we are doing a lot more with Web apps, which I why I've had >> little time for wx lately.... >> > > Yeah, that definitely has appeal. For most of the data collection, > visualization, and analysis applications I support, web interfaces just > don't give as intimate and immediate an experience as a desktop GUI. Both > are needed. > > --Matt > > -- 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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Feb 29 09:36:01 2016 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 29 Feb 2016 14:36:01 +0000 Subject: [Matplotlib-devel] Comments on backports Message-ID: Folks, When doing backports please include the branch you backported the commit to (I have run across several places where I have _not_ done this and it is a bit annoying to sort out after the fact). A quick guide to how to backport (which should go in the docs): git remote update git checkout target_branch git merge --ff-only matplotlib/target_branch git cherry-pick -m TARGET_SHA gitk # to look at it # local tests? (use your judgement) git push DANGER target_branch # leave a comment on PR noting sha of the resulting commit # from the cherry-pick + branch it was moved to here matplotlib is a read-only remote to the matplotlib/matplotlib repo and DANGER in a read/write remote to the matplotlib/matplotlib repo. These commands work on git 2.7.1. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Mon Feb 29 11:13:54 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Mon, 29 Feb 2016 08:13:54 -0800 Subject: [Matplotlib-devel] Comments on backports In-Reply-To: References: Message-ID: <10E68BBF-DEA9-473D-AAC5-8F58A0218238@gmail.com> Hey Thomas, > On Feb 29, 2016, at 06:36, Thomas Caswell wrote: > > Folks, > > When doing backports please include the branch you backported the commit to (I have run across several places where I have _not_ done this and it is a bit annoying to sort out after the fact). > > A quick guide to how to backport (which should go in the docs): > > git remote update > git checkout target_branch > git merge --ff-only matplotlib/target_branch > git cherry-pick -m TARGET_SHA > gitk # to look at it > # local tests? (use your judgement) > git push DANGER target_branch > # leave a comment on PR noting sha of the resulting commit > # from the cherry-pick + branch it was moved to We have an IPython script (that can need some love) that can help with that: https://github.com/ipython/ipython/blob/master/tools/backport_pr.py It should be able to auto guess which PR to merge based on milestone, if that can be of help. -- M > > here matplotlib is a read-only remote to the matplotlib/matplotlib repo and DANGER in a read/write remote to the matplotlib/matplotlib repo. > > These commands work on git 2.7.1. > > Tom > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam+matplotlib at phyks.me Mon Feb 29 12:03:57 2016 From: spam+matplotlib at phyks.me (Phyks) Date: Mon, 29 Feb 2016 10:03:57 -0700 (MST) Subject: [Matplotlib-devel] Changing rcParams locally, on the fly Message-ID: <1456765437491-46813.post@n5.nabble.com> Hi, Is there a way to change locally the rcParams, for a specific figure after it has been created? I know about the rcParams setting (for global settings) and the with statement construction, but this requires to be done before the figure was created, and I need to change the settings on an already existing figure (in particular color cycler). Thanks -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Changing-rcParams-locally-on-the-fly-tp46813.html Sent from the matplotlib - devel mailing list archive at Nabble.com. From ben.v.root at gmail.com Mon Feb 29 12:31:21 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 29 Feb 2016 12:31:21 -0500 Subject: [Matplotlib-devel] Changing rcParams locally, on the fly In-Reply-To: <1456765437491-46813.post@n5.nabble.com> References: <1456765437491-46813.post@n5.nabble.com> Message-ID: There is the context manager approach, but it must be utilized prior to axes creation. For the most part, any usage of the rcParams happen at creation time of the relevant artist. So, while you could update the color cycle prior to creating an axes but after the figure creation, changing the default figure size would be useless at that point since the figure is already made. There might be some push in the future to defer rcParam evaluation closer to draw time (traitlet integration), but I wouldn't bet on it happening any time soon, and it probably wouldn't do what you need in any case. Ben Root On Mon, Feb 29, 2016 at 12:03 PM, Phyks wrote: > Hi, > > Is there a way to change locally the rcParams, for a specific figure after > it has been created? > > I know about the rcParams setting (for global settings) and the with > statement construction, but this requires to be done before the figure was > created, and I need to change the settings on an already existing figure > (in > particular color cycler). > > Thanks > > > > -- > View this message in context: > http://matplotlib.1069221.n5.nabble.com/Changing-rcParams-locally-on-the-fly-tp46813.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.v.root at gmail.com Mon Feb 29 12:33:28 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 29 Feb 2016 12:33:28 -0500 Subject: [Matplotlib-devel] Changing rcParams locally, on the fly In-Reply-To: References: <1456765437491-46813.post@n5.nabble.com> Message-ID: I should also note, that it is possible to change the color cycle after an axes is created (although, now it is called the prop_cycle), using ax.set_prop_cycle(). Keep in mind that any plots that have already been made are unaffected by changing the property cycle because they have already had their properties assigned. On Mon, Feb 29, 2016 at 12:31 PM, Benjamin Root wrote: > There is the context manager approach, but it must be utilized prior to > axes creation. For the most part, any usage of the rcParams happen at > creation time of the relevant artist. So, while you could update the color > cycle prior to creating an axes but after the figure creation, changing the > default figure size would be useless at that point since the figure is > already made. > > There might be some push in the future to defer rcParam evaluation closer > to draw time (traitlet integration), but I wouldn't bet on it happening any > time soon, and it probably wouldn't do what you need in any case. > > Ben Root > > > On Mon, Feb 29, 2016 at 12:03 PM, Phyks wrote: > >> Hi, >> >> Is there a way to change locally the rcParams, for a specific figure after >> it has been created? >> >> I know about the rcParams setting (for global settings) and the with >> statement construction, but this requires to be done before the figure was >> created, and I need to change the settings on an already existing figure >> (in >> particular color cycler). >> >> Thanks >> >> >> >> -- >> View this message in context: >> http://matplotlib.1069221.n5.nabble.com/Changing-rcParams-locally-on-the-fly-tp46813.html >> Sent from the matplotlib - devel mailing list archive at Nabble.com. >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam+matplotlib at phyks.me Mon Feb 29 17:57:56 2016 From: spam+matplotlib at phyks.me (Phyks) Date: Mon, 29 Feb 2016 23:57:56 +0100 Subject: [Matplotlib-devel] Changing rcParams locally, on the fly In-Reply-To: References: <1456765437491-46813.post@n5.nabble.com> Message-ID: <56D4CCF4.9060703@phyks.me> Ok, I was not expecting matplotlib to work this way. I was actually thinking it was storing the drawing commands in some buffer, and was actually doing the render when needed. For my use case, I think I should better write a buffer on top of matplotlib and only call it in the end, when I am actually drawing the graph. Thanks Le 29/02/2016 18:33, Benjamin Root a ?crit : > I should also note, that it is possible to change the color cycle after an > axes is created (although, now it is called the prop_cycle), using > ax.set_prop_cycle(). Keep in mind that any plots that have already been > made are unaffected by changing the property cycle because they have > already had their properties assigned. > > On Mon, Feb 29, 2016 at 12:31 PM, Benjamin Root > wrote: > >> There is the context manager approach, but it must be utilized prior to >> axes creation. For the most part, any usage of the rcParams happen at >> creation time of the relevant artist. So, while you could update the color >> cycle prior to creating an axes but after the figure creation, changing the >> default figure size would be useless at that point since the figure is >> already made. >> >> There might be some push in the future to defer rcParam evaluation closer >> to draw time (traitlet integration), but I wouldn't bet on it happening any >> time soon, and it probably wouldn't do what you need in any case. >> >> Ben Root >> >> >> On Mon, Feb 29, 2016 at 12:03 PM, Phyks wrote: >> >>> Hi, >>> >>> Is there a way to change locally the rcParams, for a specific figure after >>> it has been created? >>> >>> I know about the rcParams setting (for global settings) and the with >>> statement construction, but this requires to be done before the figure was >>> created, and I need to change the settings on an already existing figure >>> (in >>> particular color cycler). >>> >>> Thanks >>> >>> >>> >>> -- >>> View this message in context: >>> http://matplotlib.1069221.n5.nabble.com/Changing-rcParams-locally-on-the-fly-tp46813.html >>> Sent from the matplotlib - devel mailing list archive at Nabble.com. >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> >> > From segre at iit.edu Mon Feb 22 19:42:07 2016 From: segre at iit.edu (Carlo Segre) Date: Tue, 23 Feb 2016 00:42:07 -0000 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: Hi Chris: i have some things to do on it but Ken McIvor has left IIT some time ago and I have not had a lot of time for software development. If I get some time I hope to add the patches. Carlo On Mon, 22 Feb 2016, Chris Barker wrote: > Hi all, > > Anyone know what's up with wxMPL? It looks like Ken hasn't updated in soe > time, and it doesn't work with recent MPLs: > > from matplotlib.axes import _process_plot_var_args > ImportError: cannot import name _process_plot_var_args > > We had a discussion about this a good while back: > > https://sourceforge.net/p/matplotlib/mailman/message/29770257/ > > anything ever come of that??? > > -Chris > > -- Carlo U. Segre -- Duchossois Leadership Professor of Physics Director, Center for Synchrotron Radiation Research and Instrumentation Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 segre at iit.edu http://phys.iit.edu/~segre segre at debian.org From newville at cars.uchicago.edu Tue Feb 23 17:23:40 2016 From: newville at cars.uchicago.edu (Matt Newville) Date: Tue, 23 Feb 2016 16:23:40 -0600 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: HI Chris, Carlo, All, On Mon, Feb 22, 2016 at 4:27 PM, Chris Barker wrote: > Hi all, > > Anyone know what's up with wxMPL? It looks like Ken hasn't updated in soe > time, and it doesn't work with recent MPLs: > > from matplotlib.axes import _process_plot_var_args > ImportError: cannot import name _process_plot_var_args > > We had a discussion about this a good while back: > > https://sourceforge.net/p/matplotlib/mailman/message/29770257/ > > anything ever come of that??? > > I guess not -- I haven't looked at this in a long time. I am still maintaining wxmplot, and using it for quite a few apps, and I know at least a few other people are using it too. Development ( https://github.com/newville/wxmplot) isn't fast, but it is not dead either. My recollection was that there was a lot of overlap in functionality, between wxmplot and wxmpl. For example, I believe both have a PlotPanel class, derived from wx.Panel, and that although the initialization arguments and methods names were pretty different, much of the real functionality was similar. What uses of wxmpl would need to be ported and/or translated (or some combination) to wxmplot to fit your needs? But: I also have to say that the lack of wxPython (and matplotib+wx backend) for Python3 is a major concern. If matplotlib's wx backend supported Phoenix, I'd be more inclined to work on this. As it is, there is not much evidence that investing significant time in wxPython-based libraries is a good use of time. If something like wxmplot.PlotPanel and ImagePanel (especially wrt giving end users a configuration panel to adjust the plot / image) existed in PyQt, I would seriously consider switching many of my GUI apps away from wxPython right now. To be clear, II have ~25kLOC of wxPython code and half a dozen non-trivial apps that I use at my lab daily. So, while I'm sympathetic and willing to help some, I'm more concerned about the very sad state of wxPython. If someone approached me about "porting wxmplot to PyQt" (and replace the truly horrible matplotlib defaults) I would be much more inclined to say yes. --Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From newville at cars.uchicago.edu Thu Feb 25 08:44:32 2016 From: newville at cars.uchicago.edu (Matt Newville) Date: Thu, 25 Feb 2016 07:44:32 -0600 Subject: [Matplotlib-devel] wxMPL status? In-Reply-To: References: Message-ID: HI Chris, On Tue, Feb 23, 2016 at 4:53 PM, Chris Barker wrote: > On Mon, Feb 22, 2016 at 4:37 PM, Carlo Segre wrote: > >> If I get some time I hope to add the patches. >> > > That would be great -- we should make a gitHub project for it -- would you > like to do that, or should I? > > or... > > > On Tue, Feb 23, 2016 at 2:23 PM, Matt Newville > wrote: > > >> Development (https://github.com/newville/wxmplot) isn't fast, but it is >> not dead either. >> >> My recollection was that there was a lot of overlap in functionality, >> between wxmplot and wxmpl. >> > > >> What uses of wxmpl would need to be ported and/or translated (or some >> combination) to wxmplot to fit your needs? >> > > Boy, I have no idea! Back in teh day, I decided that wxMPL fit my needs a > bit better, but I can't recall why...IT is lighter weight, but I don't know > that the extra weight is a problem at all... > > So our next step is going to be to take a look at wxmplot, and if it fits > the use case at hand, great! if not I guess we'll figure out if it's easier > to patch wxmplot of wxmpl to work for us. > > Stay tuned... > OK. I think a transition from wxmpl to wxmplot might not be hard. If there is anything that's missing in wxmplot that would make that transition easier, let's add it. > But: I also have to say that the lack of wxPython (and matplotib+wx >> backend) for Python3 is a major concern. If matplotlib's wx backend >> supported Phoenix, I'd be more inclined to work on this. As it is, there >> is not much evidence that investing significant time in wxPython-based >> libraries is a good use of time. >> > > Any idea what it would take for MPL to support Phoenix? Honestly, I > haven't given Phoenix a real try at all yet. I"ve got a handful of small > apps (and one biggish one) that are wx based, but not in active enough > development to want to deal with porting to py2 or Phoenix... > > So, while I'm sympathetic and willing to help some, I'm more concerned >> about the very sad state of wxPython. >> > > yeah -- the irony is that Robin has been working on PySide for the last > while.... > > but while slow, wxPython still seems to have a good community, and Phoenix > does appear to be pretty close to operational....IT jsut needs some > prodding along, I suppose. > > Actually, Benjamin Root is correct, and I should correct my earlier remarks. Using matplotlib 1.5.1 and wxPython Phoenix 3.0.3.dev1839+4ecd949 works well, and I've verified that almost all of the wxmplot examples work without any modification at all. I've only tested with Python 2.7 (Python 2.7.11 from Anaconda 2.4.1 on Mac OS X to be precise). There are a lot of differences between Phoenix and Classic, so wxmplot will need some small modifications and version-checking code for everything to work. There will no doubt be changes need for Python3, but I suspect not too many. This is really, really good news! Thanks very much matplotlib-dev team! For my part, we are doing a lot more with Web apps, which I why I've had > little time for wx lately.... > Yeah, that definitely has appeal. For most of the data collection, visualization, and analysis applications I support, web interfaces just don't give as intimate and immediate an experience as a desktop GUI. Both are needed. --Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas at phyks.me Mon Feb 29 12:50:51 2016 From: lucas at phyks.me (Lucas Verney) Date: Mon, 29 Feb 2016 18:50:51 +0100 Subject: [Matplotlib-devel] Changing rcParams locally, on the fly In-Reply-To: References: <1456765437491-46813.post@n5.nabble.com> Message-ID: <56D484FB.4020702@phyks.me> Ok, I was not expecting matplotlib to work this way. I was actually thinking it was storing the drawing commands in some buffer, and was actually doing the render when needed. For my use case, I think I should better write a buffer on top of matplotlib and only call it in the end, when I am actually drawing the graph. Thanks Le 29/02/2016 18:33, Benjamin Root a ?crit : > I should also note, that it is possible to change the color cycle after an > axes is created (although, now it is called the prop_cycle), using > ax.set_prop_cycle(). Keep in mind that any plots that have already been > made are unaffected by changing the property cycle because they have > already had their properties assigned. > > On Mon, Feb 29, 2016 at 12:31 PM, Benjamin Root > wrote: > >> There is the context manager approach, but it must be utilized prior to >> axes creation. For the most part, any usage of the rcParams happen at >> creation time of the relevant artist. So, while you could update the color >> cycle prior to creating an axes but after the figure creation, changing the >> default figure size would be useless at that point since the figure is >> already made. >> >> There might be some push in the future to defer rcParam evaluation closer >> to draw time (traitlet integration), but I wouldn't bet on it happening any >> time soon, and it probably wouldn't do what you need in any case. >> >> Ben Root >> >> >> On Mon, Feb 29, 2016 at 12:03 PM, Phyks wrote: >> >>> Hi, >>> >>> Is there a way to change locally the rcParams, for a specific figure after >>> it has been created? >>> >>> I know about the rcParams setting (for global settings) and the with >>> statement construction, but this requires to be done before the figure was >>> created, and I need to change the settings on an already existing figure >>> (in >>> particular color cycler). >>> >>> Thanks >>> >>> >>> >>> -- >>> View this message in context: >>> http://matplotlib.1069221.n5.nabble.com/Changing-rcParams-locally-on-the-fly-tp46813.html >>> Sent from the matplotlib - devel mailing list archive at Nabble.com. >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Matplotlib-devel at python.org >>> https://mail.python.org/mailman/listinfo/matplotlib-devel >>> >> >> >