Re: [matplotlib-devel] plot_surface patch
On Tue, Nov 16, 2010 at 5:20 PM, J P wrote: > Hi all, here's my first patch for matplotlib. Someone noticed at Stack > Overflow that the plot_surface function in mplot3d wasn't especially fast > for a lot of points (and small rstrides/cstrides) and using shading and a > single color. I found some parts of the code that weren't vectorized. These > are my changes so far. > > Summary of changes: > 1. Changed from double looping over aranges to using xrange > 2. Made the normalization of the normals and their dot product with the > vector [-1,-1,0.5] to find the shading a vectorized operation. > 3. Changed a list comprehension which calculated the colors using an > iterative approach to using the already built-in vectorization of the > Normalization class and using the np.outer function. The result is a numpy > array rather than a list which actually speeds up things down the line. > 4. removed the corners array from plot_surface which wasn't ever used or > returned. It didn't really slow things down, but I'm thinking that it is > cruft. > > For change number two, I made a separate function that generates the > shades, but feel free to move that around if you prefer.. or maybe it should > be a function that begins with a _ because it shouldn't be used externally. > These changes give varying levels of speed improvement depending on the > number of points and the rstrides/cstrides arguments. With larger numbers of > points and small rstrides/cstrides, these changes can more than halve the > running time. I have found no difference in output after my changes. > > I know there is more work to be done within the plot_surface function and > I'll submit more changes soon. > > Justin > > Justin, Thank you for your efforts to improve the performance of mplot3d. I will take a look at the patches you have submitted and test them out. What I am probably going to do is break down the patches into smaller pieces and incorporate them piece-by-piece. I tried refactoring plot_surface once before to mixed results. The key feature I was trying to gain was compatibility with masked arrays. I wanted to duplicate the behavior of contourf and pcolor where masked out portions of the surface would not be created. I managed to get it to work for that particular use-case, but I broke a bunch of other use-cases along the way. I am curious to see if your patches make this easier/harder to do. Thank you for your efforts and thank you for using matplotlib! Ben Root -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] How to decouple non-GUI stuff from the GUI?
Hi. I am finding that matplotlib does not allow me to decouple certain
actions from the GUI as much as I'd like.
For example, I have not been able to do any of the following tasks. Some of
these tasks are certainly artificial, but they all succinctly illustrate
some of the problems I've been running into when doing more realistic stuff.
1. *without bringing up any GUI window*, generate a list of all the
filetypes available to a specific matplotlib installation for saving
graphics (e.g. .ps, .svg, .pdf, .png, etc.);
2. switch back-and-forth between sending graphics objects for display to the
GUI and sending them for saving to any of the available filetypes (as
defined in (1));
3. (by far the most important one) *without activating any backend*, create
a graphics object (I explain what I mean by this below).
To clarify what I mean by (3), the best I can do is to give an example from
Mathematica. In Mathematica, a Graphics object does not need to be
displayed. It can be defined as a collection of Graphics primitives,
without ever displaying it in the GUI. One such definition would be
something like
In[1]:= g = Graphics[Line[{{1., 2.}, {2., 3.}, {3., 5.}}]];
This is what I mean in (3) by creating a graphics object without displaying
it (in the GUI). From a design perspective, this makes a lot of sense,
since a Graphics object, as an idea, is entirely independent of whatever
mean one chooses to display it. I want my code to reflect this conceptual
independence.
Regarding task (2), to make it more concrete, consider this (also
artificial) exercise: write a script that iterates over all filetypes
identified in (1); at each iteration, generate some random graphic (e.g. of
the sort shown here
http://matplotlib.sourceforge.net/examples/api/patch_collection.html),
display it on the GUI, and save it as a file of the type corresponding to
the iteration.
I would very much appreciate some hints/guidance on how to solve them.
As I noted, by far the most important of these tasks is (3). From looking
into the matplotlib source code, it looks to me impossible to do this with
standard matplotlib functions. But I am very much of a noob with mpl, so I
still hope there's a way.
In the worst case scenario (i.e. (3) can't be done directly using standard
mpl functions), then the only solution that I can think of would involve
implementing a separate layer of abstract graphics objects, distinct from
mpl's. This layer would then delegate to mpl the task of displaying the
graphics objects whenever the user requests it. Any suggestions on how best
to do this would be much appreciated. In particular, I'd like to know what
would be the right place to insert this new graphics object layer into the
matplotlib objects stack. I think it would be best to make this connection
at a level deeper than the axes object, but I'm not quite sure how to do
this.
Thanks in advance!
kj
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
On 11/17/2010 03:41 PM, Kynn Jones wrote:
Hi. I am finding that matplotlib does not allow me to decouple
certain actions from the GUI as much as I'd like.
For example, I have not been able to do any of the following tasks.
Some of these tasks are certainly artificial, but they all succinctly
illustrate some of the problems I've been running into when doing more
realistic stuff.
1. /without bringing up any GUI window/,
Set the backend to a non-GUI backend, such as agg, pdf, ps, svg or cairo
by setting the 'backend' rcParam in matplotlibrc, or doing:
import matplotlib
matplotlib.use("Agg") # Must be the first call after importing matplotlib
generate a list of all the filetypes available to a specific
matplotlib installation for saving graphics (e.g. .ps, .svg, .pdf,
.png, etc.);
From a figure object:
figure.canvas.get_supported_filetypes()
returns a dictionary of supported file extensions, with mapping to more
detailed descriptions of each.
2. switch back-and-forth between sending graphics objects for display
to the GUI and sending them for saving to any of the available
filetypes (as defined in (1));
Once set to any of the GUI backends, you can use "show()" and
"savefig()" interchangeably.
3. (by far the most important one) /without activating any
backend/, create a graphics object (I explain what I mean by this below).
To clarify what I mean by (3), the best I can do is to give an example
from Mathematica. In Mathematica, a Graphics object does not need to
be displayed. It can be defined as a collection of Graphics
primitives, without ever displaying it in the GUI. One such
definition would be something like
In[1]:= g = Graphics[Line[{{1., 2.}, {2., 3.}, {3., 5.}}]];
This is what I mean in (3) by creating a graphics object without
displaying it (in the GUI). From a design perspective, this makes a
lot of sense, since a Graphics object, as an idea, is entirely
independent of whatever mean one chooses to display it. I want my
code to reflect this conceptual independence.
Regarding task (2), to make it more concrete, consider this (also
artificial) exercise: write a script that iterates over all filetypes
identified in (1); at each iteration, generate some random graphic
(e.g. of the sort shown here
http://matplotlib.sourceforge.net/examples/api/patch_collection.html),
display it on the GUI, and save it as a file of the type corresponding
to the iteration.
I would very much appreciate some hints/guidance on how to solve them.
As I noted, by far the most important of these tasks is (3). From
looking into the matplotlib source code, it looks to me impossible to
do this with standard matplotlib functions. But I am very much of a
noob with mpl, so I still hope there's a way.
In the worst case scenario (i.e. (3) can't be done directly using
standard mpl functions), then the only solution that I can think of
would involve implementing a separate layer of abstract graphics
objects, distinct from mpl's. This layer would then delegate to mpl
the task of displaying the graphics objects whenever the user requests
it. Any suggestions on how best to do this would be much appreciated.
In particular, I'd like to know what would be the right place to
insert this new graphics object layer into the matplotlib objects
stack. I think it would be best to make this connection at a level
deeper than the axes object, but I'm not quite sure how to do this.
I think you'll find matplotlib works exactly as you want. I think you
might find this part of the documentation useful:
http://matplotlib.sourceforge.net/faq/installing_faq.html#backends
Mike
Thanks in advance!
kj
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
On Wed, Nov 17, 2010 at 3:52 PM, Michael Droettboom wrote:
> On 11/17/2010 03:41 PM, Kynn Jones wrote:
>
> Hi. I am finding that matplotlib does not allow me to decouple certain
> actions from the GUI as much as I'd like.
>
> For example, I have not been able to do any of the following tasks. Some
> of these tasks are certainly artificial, but they all succinctly
> illustrate some of the problems I've been running into when doing more
> realistic stuff.
>
> 1. *without bringing up any GUI window*,
>
> Set the backend to a non-GUI backend, such as agg, pdf, ps, svg or cairo by
> setting the 'backend' rcParam in matplotlibrc, or doing:
>
> import matplotlib
> matplotlib.use("Agg") # Must be the first call after importing matplotlib
>
>generate a list of all the filetypes available to a specific matplotlib
> installation for saving graphics (e.g. .ps, .svg, .pdf, .png, etc.);
>
> >From a figure object:
>
>figure.canvas.get_supported_filetypes()
>
> returns a dictionary of supported file extensions, with mapping to more
> detailed descriptions of each.
>
Yes, but this solves the problem only for the non-GUI backends. It does not
work for GUI backends, or at least for the MacOSX backend, which is the only
graphics backend that I've managed to get to work (despite of, literally,
days trying unsuccessfully to install other ones). With this GUI backend,
as far as I know, generating a figure object (even an empty one), causes the
window to pop up.
That's the point of this task: to illustrate that even something like
getting a list of supported files, which does not require any graphical
output, is nonetheless tightly coupled with displaying the GUI. As far as I
can tell, there's simply no way to get these filetypes for GUI backends
without bringing up a window. (I'm assuming here that the MacOSX backend is
representative in this respect.)
By the same token, it is not possible to iterate over all the possible
backends within the same script to find the filetypes they support, because
the call to matplotlib.use(BACKEND) must happen before one imports
matplotlib.pyplot, which is required to generate the figure.canvas to
interrogate for possible filetypes. This is another illustration of what I
refer to a tight coupling with the GUI.
> 2. switch back-and-forth between sending graphics objects for display to
> the GUI and sending them for saving to any of the available filetypes (as
> defined in (1));
>
> Once set to any of the GUI backends, you can use "show()" and "savefig()"
> interchangeably.
>
Yes, but only for the filetypes associated with that backend; once the GUI
backend is chosen, it blocks any other backend (even a non-GUI one) from
loading. I'd argue that this is another example of tight coupling with the
GUI, because there's no reason why making a choice of GUI should restrict
the filetypes that can be saved. The problems of displaying a graphic and
saving a file are completely orthogonal. Picking a solution for one should
have no impact at all on what one chooses for the other.
> 3. (by far the most important one) *without activating any backend*, create
> a graphics object (I explain what I mean by this below).
>
> To clarify what I mean by (3), the best I can do is to give an example
> from Mathematica. In Mathematica, a Graphics object does not need to be
> displayed. It can be defined as a collection of Graphics primitives,
> without ever displaying it in the GUI. One such definition would be
> something like
>
> In[1]:= g = Graphics[Line[{{1., 2.}, {2., 3.}, {3., 5.}}]];
>
> This is what I mean in (3) by creating a graphics object without
> displaying it (in the GUI). From a design perspective, this makes a lot of
> sense, since a Graphics object, as an idea, is entirely independent of
> whatever mean one chooses to display it. I want my code to reflect this
> conceptual independence.
>
> Regarding task (2), to make it more concrete, consider this (also
> artificial) exercise: write a script that iterates over all filetypes
> identified in (1); at each iteration, generate some random graphic (e.g. of
> the sort shown here
> http://matplotlib.sourceforge.net/examples/api/patch_collection.html),
> display it on the GUI, and save it as a file of the type corresponding to
> the iteration.
>
> I would very much appreciate some hints/guidance on how to solve them.
>
> As I noted, by far the most important of these tasks is (3). From
> looking into the matplotlib source code, it looks to me impossible to do
> this with standard matplotlib functions. But I am very much of a noob with
> mpl, so I still hope there's a way.
>
> In the worst case scenario (i.e. (3) can't be done directly using
> standard mpl functions), then the only solution that I can think of would
> involve implementing a separate layer of abstract graphics objects, distinct
> from mpl's. This layer would then delegate to mpl the task of displaying
> the graphics objects whenever the user requ
Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
--- On Wed, 11/17/10, Kynn Jones wrote:
>From a figure object:
figure.canvas.get_supported_filetypes()
returns a dictionary of supported file extensions, with mapping to more
detailed descriptions of each.
Yes,
but this solves the problem only for the non-GUI backends. It does not
work for GUI backends, or at least for the MacOSX backend, which is the
only graphics backend that I've managed to get to work (despite of,
literally, days trying unsuccessfully to install other ones).
Works for me:
>>> import matplotlib
>>> matplotlib.use("MacOSX")
>>> from pylab import *
>>> f = figure()
>>> f.canvas.get_supported_filetypes()
{'svgz': 'Scalable Vector Graphics', 'ps': 'Postscript', 'emf': 'Enhanced
Metafile', 'gif': 'Graphics Interchange Format', 'svg': 'Scalable Vector
Graphics', 'eps': 'Encapsulated Postscript', 'jpeg': 'JPEG', 'raw': 'Raw RGBA
bitmap', 'bmp': 'Windows bitmap', 'jpg': 'JPEG', 'rgba': 'Raw RGBA bitmap',
'tiff': 'Tagged Image Format File', 'pdf': 'Portable Document Format', 'tif':
'Tagged Image Format File', 'png': 'Portable Network Graphics'}
>>>
This does pop up a window though.
You should be able to use the non-interactive mode to do this without popping
up a window. However, the non-interactive mode was never implemented for this
backend. At least as I understood it, originally the main purpose of the
non-interactive mode was to speed up drawing. In the MacOSX backend,
interactive drawing was always equally fast as non-interactive drawing
(nowadays this is also true for the other backends; at least I have not seen
any examples of the contrary), which is why non-interactive drawing was not
implemented in the MacOSX backend.
In principle the non-interactive mode can also be implemented in this backend.
If that would solve your problem, could you open a bug report for it?
--Michiel.
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
On Wed, Nov 17, 2010 at 4:54 PM, Kynn Jones wrote:
> On Wed, Nov 17, 2010 at 3:52 PM, Michael Droettboom wrote:
>
>> On 11/17/2010 03:41 PM, Kynn Jones wrote:
>>
>> Hi. I am finding that matplotlib does not allow me to decouple certain
>> actions from the GUI as much as I'd like.
>>
>> For example, I have not been able to do any of the following tasks.
>> Some of these tasks are certainly artificial, but they all succinctly
>> illustrate some of the problems I've been running into when doing more
>> realistic stuff.
>>
>> 1. *without bringing up any GUI window*,
>>
>> Set the backend to a non-GUI backend, such as agg, pdf, ps, svg or cairo
>> by setting the 'backend' rcParam in matplotlibrc, or doing:
>>
>> import matplotlib
>> matplotlib.use("Agg") # Must be the first call after importing
>> matplotlib
>>
>>generate a list of all the filetypes available to a specific
>> matplotlib installation for saving graphics (e.g. .ps, .svg, .pdf, .png,
>> etc.);
>>
>> >From a figure object:
>>
>>figure.canvas.get_supported_filetypes()
>>
>> returns a dictionary of supported file extensions, with mapping to more
>> detailed descriptions of each.
>>
>
> Yes, but this solves the problem only for the non-GUI backends. It does
> not work for GUI backends, or at least for the MacOSX backend, which is the
> only graphics backend that I've managed to get to work (despite of,
> literally, days trying unsuccessfully to install other ones). With this GUI
> backend, as far as I know, generating a figure object (even an empty one),
> causes the window to pop up.
>
>
Actually, the macosx backend is alone in this matter. This behavior was
recently reported and is a bug. The other backends do not pop up a window
unless interactive mode is turned on.
> That's the point of this task: to illustrate that even something like
> getting a list of supported files, which does not require any graphical
> output, is nonetheless tightly coupled with displaying the GUI. As far as I
> can tell, there's simply no way to get these filetypes for GUI backends
> without bringing up a window. (I'm assuming here that the MacOSX backend is
> representative in this respect.)
>
>
By the same token, it is not possible to iterate over all the possible
> backends within the same script to find the filetypes they support, because
> the call to matplotlib.use(BACKEND) must happen before one imports
> matplotlib.pyplot, which is required to generate the figure.canvas to
> interrogate for possible filetypes. This is another illustration of what I
> refer to a tight coupling with the GUI.
>
There is a switch_backends function in pyplot, but it is experimental and
tricky:
http://matplotlib.sourceforge.net/api/pyplot_api.html?highlight=switch_backend#matplotlib.pyplot.switch_backend
I have not checked, but maybe that get_supported_filetypes() could be made
intto a static function? That could address your complaint in that regard
because an instance of the backend does not need to be made.
> 2. switch back-and-forth between sending graphics objects for display to
>> the GUI and sending them for saving to any of the available filetypes (as
>> defined in (1));
>>
>> Once set to any of the GUI backends, you can use "show()" and "savefig()"
>> interchangeably.
>>
>
> Yes, but only for the filetypes associated with that backend; once the GUI
> backend is chosen, it blocks any other backend (even a non-GUI one) from
> loading. I'd argue that this is another example of tight coupling with the
> GUI, because there's no reason why making a choice of GUI should restrict
> the filetypes that can be saved. The problems of displaying a graphic and
> saving a file are completely orthogonal. Picking a solution for one should
> have no impact at all on what one chooses for the other.
>
I would argue that it is because no one has asked for this feature before.
Necessity is the mother of all inventions. We have a very basic
switch_backends function, but maybe you could help us make it better?
The reason for the different backends having different supported filetypes
is that some of the backends are speciality backends ("pdf", for example)
and obviously only supports the pdf file type. In some other situations,
the saving of the figure data is off-loaded to convenience functions in the
various gui toolkits. The main reason for this is that those gui's provide
the proper clipping and other rendering tricks needed for proper production
of the images. I am not as familiar with exactly what happens in the
backends, but as far as I know, the available file formats are the same
across all the major gui backends and Agg. It is only the specialty
backends that this is not the case.
If you find a discrepency, it is probably a bug and should be reported as
such.
3. (by far the most important one) *without activating any backend*, create
>> a graphics object (I explain what I mean by this below).
>>
>> To clarify what I mean by (3), the best I c
Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?
> As an additional note, if you are having difficulty compiling for > MacOS X, why not just ask for help with that? yup -- there are some issues with which Tk is used by tkInter, but wx should be easy -- how have you tried to install? -Chris -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
