matplotlib-devel Mailing List for matplotlib (Page 2)

On Wed, Nov 17, 2010 at 4:54 PM, Kynn Jones <ky...@gm...> wrote:
> On Wed, Nov 17, 2010 at 3:52 PM, Michael Droettboom <md...@st...>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 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
>>
>
> I'd read that before (that's where I learned the little I know about
> backends).
>
> Still, I don't see how one does (3). Here's an example problem:
>
> 1. generate (without bringing up a GUI window!) two different graphics
> objects, each corresponding to a unit circle;
> 2. perform a random translation/scaling transformation on each of the two
> circles;
> 3. combine the two circles into a single graphic object (so that they have
> a common coordinate system);
> 4. finally, display the resulting object.
>
>
>
As far as I can tell, steps 1-3 cannot be done before choosing (and locking
> in) a specific backend. If this backend is a GUI one (or at least the
> MacOSX one), then just carrying out (1) will cause a window to pop up.
>
>
As already covered above, the macosx backend is the only one to do this, and
it is a bug. Therefore, while backend has to be chosen at load-time, this
is not an issue, as it is not used until later.
To do what you want, you might want to take a look at these:
http://matplotlib.sourceforge.net/users/path_tutorial.html
http://matplotlib.sourceforge.net/users/artists.html
And maybe some stuff in the examples library. Matplotlib makes extensive
use of various artist objects, and collections of those objects to represent
the components of the figure to be plotted. So, you could create Circle
patch objects and others (before you make a call to figure()), and then add
them to an axes when ready.
As an additional note, if you are having difficulty compiling for MacOS X,
why not just ask for help with that?
Ben Root

--- On Wed, 11/17/10, Kynn Jones <ky...@gm...> 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.
 

On Wed, Nov 17, 2010 at 3:52 PM, Michael Droettboom <md...@st...> 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 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
>
I'd read that before (that's where I learned the little I know about
backends).
Still, I don't see how one does (3). Here's an example problem:
1. generate (without bringing up a GUI window!) two different graphics
objects, each corresponding to a unit circle;
2. perform a random translation/scaling transformation on each of the two
circles;
3. combine the two circles into a single graphic object (so that they have a
common coordinate system);
4. finally, display the resulting object.
As far as I can tell, steps 1-3 cannot be done before choosing (and locking
in) a specific backend. If this backend is a GUI one (or at least the
MacOSX one), then just carrying out (1) will cause a window to pop up.
~kj

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

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

On Tue, Nov 16, 2010 at 5:20 PM, J P <jp...@gm...> 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

Hi again,
I'll try to keep my messages in plain text from now on. I kept working
on some more speed improvements for plot_surface functions and have
included the diff that has those extra changes.
Here are the main extra changes:
1. vectorized the code in _shade_colors when inputting a grid of
colors by moving to an already vectorized to_rgba_array() function,
using the vectorized Normalize class, and using numpy to multiply the
two. Also, making the result be a numpy array stops set_face_color()
function from redundantly calling to_rgba on each individual item
again. This improvement speeds up the mplot3d example surface3d_demo3
by about 3x on my machine.
2. I preallocated the space for the two vectors that will be crossed
for each area of points to make the normals and do a vectorized
np.cross() afterwards instead. Shaves off a bit more time.
3. Made the functions that select points not include multiples of the
corners of the rectangle of points (if that makes any sense). Not a
huge savings, but still worthwhile I feel.
I think that I'm done with working on these functions now. I hope that
these changes are amenable. Let me know if there are concerns.
Justin Peel
---------- Forwarded message ----------
From: J P <jp...@gm...>
Date: Tue, Nov 16, 2010 at 4:20 PM
Subject: plot_surface patch
To: Mat...@li...
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

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

On Sun, Nov 14, 2010 at 7:25 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi,
>
> I just committed a simple change that disables pstoeps in ps backend
> when "xpdf" distiller is used. Without this, output bbox was incorrect
> with "xpdf" distiller and usetex=False.
>
> Getting the correct bbox with the ps backend is very tricky, and it'll
> be appreciated if others help me test this.
>
> Here is a simple test script (this needs to be run with most recent
> svn version of matplotlib, and you need to able to use ustex=True!).
> It will produce 6 eps files. Please check if any of the eps files have
> incorrect bbox. And report which file has wrong bbox and your setup :
> your OS, gs version number (output from "gs -v"), pdftops version
> number (output from "pdftops -v"). It will be also good if you report
> your setup even when everything is okay.
>
> Regards,
>
> -JJ
>
> import matplotlib.pyplot as plt
>
> plt.plot([1,2])
>
> for distiller in ["False", "xpdf", "ghostscript"]:
> for usetex in ["True", "False"]:
> plt.rcParams["ps.usedistiller"]=distiller
> plt.rcParams["text.usetex"]=usetex
>
> plt.savefig("test_bbox_%s_%s.eps" % (distiller, usetex))
>
>
Evince shows a few of the eps files weirdly:
test_bbox_ghostscript_False.eps comes out as 8.5x11 inch while the other
come out as 8x6 inches.
test_bbox_xpdf_False.eps is the correct size, but the graph was placed as if
it was centered on a 8.5x11 page, thereby cutting off the bottom half of the
graph.
The system:
Fedora 13
pdftops 0.12.4
ghostscript 8.71
evince 2.30.3 (using libspectre 0.2.4)
I will try out my Ubuntu system tonight.
Ben Root

Hi,
I just committed a simple change that disables pstoeps in ps backend
when "xpdf" distiller is used. Without this, output bbox was incorrect
with "xpdf" distiller and usetex=False.
Getting the correct bbox with the ps backend is very tricky, and it'll
be appreciated if others help me test this.
Here is a simple test script (this needs to be run with most recent
svn version of matplotlib, and you need to able to use ustex=True!).
It will produce 6 eps files. Please check if any of the eps files have
incorrect bbox. And report which file has wrong bbox and your setup :
your OS, gs version number (output from "gs -v"), pdftops version
number (output from "pdftops -v"). It will be also good if you report
your setup even when everything is okay.
Regards,
-JJ
import matplotlib.pyplot as plt
plt.plot([1,2])
for distiller in ["False", "xpdf", "ghostscript"]:
 for usetex in ["True", "False"]:
 plt.rcParams["ps.usedistiller"]=distiller
 plt.rcParams["text.usetex"]=usetex
 plt.savefig("test_bbox_%s_%s.eps" % (distiller, usetex))

On 11/11/2010 11:28 AM, Kynn Jones wrote:
> Same thing:
>
> >>> import cairo
> >>> print cairo.version
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'version'
It looks like you have a strangely broken pycairo installation, then.
Eric
>
> kj
>
>
> On Thu, Nov 11, 2010 at 3:09 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 11/11/2010 09:54 AM, Kynn Jones wrote:
> > On my system, the following 3-line script
> >
> > *import matplotlib
> > matplotlib.use('Cairo')
> > import matplotlib.pyplot as plt
> > *
> > fails with the error:
> >
> > * File "<path-to-mpl-egg>/matplotlib/backends/backend_cairo.py", line
> > 34, in <module>
> > if cairo.version_info < _version_required:
> > AttributeError: 'module' object has no attribute 'version_info'
> > *
> > It's easy to see that the bug is in
> matplotlib.backends.backend_cairo;
> > here's the part of the code that produces the error:
> >
> > *try:
> > import cairo
> > except ImportError:
> > raise ImportError("Cairo backend requires that pycairo is
> installed.")
> >
> > _version_required = (1,2,0)
> > if cairo.version_info < _version_required:
> > raise ImportError ("Pycairo %d.%d.%d is installed\n"
> > "Pycairo %d.%d.%d or later is required"
> > % (cairo.version_info + _version_required))
> > *
> > Indeed, the cairo module has no version_info attribute:
> >
> > *% python
> > Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
> > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
> >> >> import cairo
> >> >> cairo.version_info
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > AttributeError: 'module' object has no attribute 'version_info'
> > *
>
> Strange. Looking at the source of 1.8.10 from the py2cairo git repo, I
> see version_info as well as version being included in the module via
> cairomodule.c.
>
> > (FWIW, the version of pycairo I have installed is 1.8.10 .)
>
> What happens if you do:
>
> import cairo
> print cairo.version
>
>
> Eric
>
> >
> > So matplotlib.backends.backend_cairo needs some other way to
> determine
> > the version number for the cairo module, but I don't understand this
> > module sufficiently well to provide a patch for this bug.
> >
> > ~kj
> >
>

Same thing:
>>> import cairo
>>> print cairo.version
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version'
kj
On Thu, Nov 11, 2010 at 3:09 PM, Eric Firing <ef...@ha...> wrote:
> On 11/11/2010 09:54 AM, Kynn Jones wrote:
> > On my system, the following 3-line script
> >
> > *import matplotlib
> > matplotlib.use('Cairo')
> > import matplotlib.pyplot as plt
> > *
> > fails with the error:
> >
> > * File "<path-to-mpl-egg>/matplotlib/backends/backend_cairo.py", line
> > 34, in <module>
> > if cairo.version_info < _version_required:
> > AttributeError: 'module' object has no attribute 'version_info'
> > *
> > It's easy to see that the bug is in matplotlib.backends.backend_cairo;
> > here's the part of the code that produces the error:
> >
> > *try:
> > import cairo
> > except ImportError:
> > raise ImportError("Cairo backend requires that pycairo is installed.")
> >
> > _version_required = (1,2,0)
> > if cairo.version_info < _version_required:
> > raise ImportError ("Pycairo %d.%d.%d is installed\n"
> > "Pycairo %d.%d.%d or later is required"
> > % (cairo.version_info + _version_required))
> > *
> > Indeed, the cairo module has no version_info attribute:
> >
> > *% python
> > Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
> > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
> >> >> import cairo
> >> >> cairo.version_info
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > AttributeError: 'module' object has no attribute 'version_info'
> > *
>
> Strange. Looking at the source of 1.8.10 from the py2cairo git repo, I
> see version_info as well as version being included in the module via
> cairomodule.c.
>
> > (FWIW, the version of pycairo I have installed is 1.8.10 .)
>
> What happens if you do:
>
> import cairo
> print cairo.version
>
>
> Eric
>
> >
> > So matplotlib.backends.backend_cairo needs some other way to determine
> > the version number for the cairo module, but I don't understand this
> > module sufficiently well to provide a patch for this bug.
> >
> > ~kj
> >
>
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 11/11/2010 09:54 AM, Kynn Jones wrote:
> On my system, the following 3-line script
>
> *import matplotlib
> matplotlib.use('Cairo')
> import matplotlib.pyplot as plt
> *
> fails with the error:
>
> * File "<path-to-mpl-egg>/matplotlib/backends/backend_cairo.py", line
> 34, in <module>
> if cairo.version_info < _version_required:
> AttributeError: 'module' object has no attribute 'version_info'
> *
> It's easy to see that the bug is in matplotlib.backends.backend_cairo;
> here's the part of the code that produces the error:
>
> *try:
> import cairo
> except ImportError:
> raise ImportError("Cairo backend requires that pycairo is installed.")
>
> _version_required = (1,2,0)
> if cairo.version_info < _version_required:
> raise ImportError ("Pycairo %d.%d.%d is installed\n"
> "Pycairo %d.%d.%d or later is required"
> % (cairo.version_info + _version_required))
> *
> Indeed, the cairo module has no version_info attribute:
>
> *% python
> Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
> [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
>> >> import cairo
>> >> cairo.version_info
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'version_info'
> *
Strange. Looking at the source of 1.8.10 from the py2cairo git repo, I 
see version_info as well as version being included in the module via 
cairomodule.c.
> (FWIW, the version of pycairo I have installed is 1.8.10 .)
What happens if you do:
import cairo
print cairo.version
Eric
>
> So matplotlib.backends.backend_cairo needs some other way to determine
> the version number for the cairo module, but I don't understand this
> module sufficiently well to provide a patch for this bug.
>
> ~kj
>

On my system, the following 3-line script
*import matplotlib
matplotlib.use('Cairo')
import matplotlib.pyplot as plt
*
fails with the error:
* File "<path-to-mpl-egg>/matplotlib/backends/backend_cairo.py", line 34,
in <module>
 if cairo.version_info < _version_required:
AttributeError: 'module' object has no attribute 'version_info'
*
It's easy to see that the bug is in matplotlib.backends.backend_cairo;
here's the part of the code that produces the error:
*try:
 import cairo
except ImportError:
 raise ImportError("Cairo backend requires that pycairo is installed.")
_version_required = (1,2,0)
if cairo.version_info < _version_required:
 raise ImportError ("Pycairo %d.%d.%d is installed\n"
 "Pycairo %d.%d.%d or later is required"
 % (cairo.version_info + _version_required))
*
Indeed, the cairo module has no version_info attribute:
*% python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
>>> import cairo
>>> cairo.version_info
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'version_info'
*
(FWIW, the version of pycairo I have installed is 1.8.10 .)
So matplotlib.backends.backend_cairo needs some other way to determine the
version number for the cairo module, but I don't understand this module
sufficiently well to provide a patch for this bug.
~kj

On Wed, Nov 10, 2010 at 10:09 PM, Benjamin Root <ben...@ou...> wrote:
> FYI,
>
> I was just looking through the package list for the newly released RHEL 6.
> matplotlib version 0.99.1.2 has been included, along with numpy 1.3 and
> python 2.6.5. I did not see scipy and ipython, however.
>
> Congrats for fiinally getting included in RHEL
Thanks for letting us know -- frankly I'm astonished it took this
long. We've been in debian for years. I'm even more surprised by the
omission of ipython and scipy -- both of these packages have been in
debian for at least 7 years, i think. I guess it's true what they
say: the enterprise moves slowly!
JDH

FYI,
I was just looking through the package list for the newly released RHEL 6.
matplotlib version 0.99.1.2 has been included, along with numpy 1.3 and
python 2.6.5. I did not see scipy and ipython, however.
Congrats for fiinally getting included in RHEL!
Ben Root

On Tue, Nov 9, 2010 at 9:20 PM, John Hunter <jd...@gm...> wrote:
> Thanks for testing Ben -- I'm seeing some of these artifacts too, eg
> on examples/animation/subplots.py. I may be transposing a row/col
> argument somewhere, which is easy to do. Also, I'll have to dig into
> the animations.py code a little more to make sure it is doing the
> copy_from_bbox background after each draw event so that everything is
> properly sized. Since these examples worked fine before my changes,
> though, it is pretty clear where the culprit is :-)
Just because animations.py worked before doesn't mean it wasn't
broken. :) Sequencing of copy_from_bbox with draw_events was one of
the pain points for me and something I want to make easier to get
right from a general Figure() standpoint, which would also address
problems with the macosx backend. (Could be a few months before I can
get back to that level of developing though.) So I wouldn't be
surprised if you revealed I'm doing something wrong in this case.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Nov 9, 2010 at 7:57 PM, Benjamin Root <ben...@ou...> wrote:
> I gave your latest patch a try and I noticed something odd while doing the
> animation examples. I don't know if this is a result of my special desktop
> configuration. I am using Ubuntu Netbook Remix, which uses Maxiumus to
> automatically maximize all windows that open (including matplotlib figure
> windows).
>
> When running some of the animations (not all of them), the chart is
> distorted and remains so after un-maximizing. I have included some
> screenshots to show what I mean. This isn't the first time that Maximus has
> caused issues for me, because it does break many developers' assumptions
> about their program windows. I am not sure if the problem is limited to
> just Maximus, or if anybody else can reproduce my manually maximizing their
> windows.
Thanks for testing Ben -- I'm seeing some of these artifacts too, eg
on examples/animation/subplots.py. I may be transposing a row/col
argument somewhere, which is easy to do. Also, I'll have to dig into
the animations.py code a little more to make sure it is doing the
copy_from_bbox background after each draw event so that everything is
properly sized. Since these examples worked fine before my changes,
though, it is pretty clear where the culprit is :-)
JDH

On Tue, Nov 9, 2010 at 3:48 PM, Eric Firing <ef...@ha...> wrote:
> On 11/09/2010 11:03 AM, John Hunter wrote:
> Based on a very superficial look, I suspect we could eliminate
> pixbuf_get_pixels_array by using the function
> http://www.pygtk.org/docs/pygtk/class-gdkpixbuf.html#function-gdk--pixbuf-new-from-data.
Nice find -- this does the trick. I was able to plug it into gdk
draw_image and draw_mathtext fairly painlessly. I've now removed all
the gtk compile time dependencies in the attached patch against svn
HEAD. Because this is a major change, I'm going to hold off
committing it to give you all a change to review and test, and I'll
test some more on a different platform when I get home. But on
solaris python2.4, I have animations with blitting in gtkagg, images
and mathtext in GTK/GDK, so this is looking pretty good so far (all of
this was segfaulting before)
Because build_gtk and build_gtkagg are no longer config options, there
is a small change in the logic in how the default backend gets set.
Now gtkagg will be set as the default backend if check_for_gtk returns
True. We may want to change this, since tkagg is a little friendlier
across shells.
JDH

On 11/09/2010 11:03 AM, John Hunter wrote:
> On Tue, Nov 9, 2010 at 2:25 PM, John Hunter<jd...@gm...> wrote:
>
>
> I'm going to proceed with removing _gtkagg.cpp in the trunk, and I
> think we should consider disabling default builds of _backend_gdk.c
> (they could be enabled by a config option if we can't find a python
> replacement for pixbuf_get_pixels_array)
>
John,
Based on a very superficial look, I suspect we could eliminate 
pixbuf_get_pixels_array by using the function 
http://www.pygtk.org/docs/pygtk/class-gdkpixbuf.html#function-gdk--pixbuf-new-from-data.
Eric

On Tue, Nov 9, 2010 at 2:25 PM, John Hunter <jd...@gm...> wrote:
> Attached also is the example code I am using to test. Strangely, the
> agg buffer seems to be updating internally but the gtk window is only
> updating when I hover my mouse over it, and then only once until I
> activate another window and then re-hover over the mpl animation
> window.
OK, this was an example of how writing the email for help solves the
problem. As soon as I described the strange updating behavior, it
triggered my memory about the expose event code in backend_gtk and
when I took a look at that I realized I need to draw to the window and
not the pixbuf as we do in _render_figure. The revised diff is
attached.
So this email now is a patch review request, and importantly, can we
get rid of all gtk extension code? There is now no need for
_gtkagg.cpp, and the only other piece is src/_backend_gdk.c which
provides pixbuf_get_pixels_array. If we could get rid of this, which
is used for images and mathtext in the GDK backend, it would be a big
win for compilation and distribution. Ideally, I would like to not
compile anything against a GUI, but so far we haven't been able to
figure out a way around TkAgg. But removing GTK compile time
dependencies would be a good start.
If you are familiar with agg and/or gtk/gdk internals, please take a
look at my updated patch. I am not double buffering as we are in
_render_figure, which seems appropriate for animation. I am actually
a little confused about why we need so many buffers in the main draw
pipeline -- we have the agg buffer, the gtk pixbuf, the gdk pixmap,
and the gdk window. Does anyone recall why we don't render directly
from the pixbuf to the window here? My guess is that it is to handle
the expose event in backend_gtk efficiently, but we should be able to
do this from the pixbuf directly to the window.... Or perhaps I'm
missing something.
I'm going to proceed with removing _gtkagg.cpp in the trunk, and I
think we should consider disabling default builds of _backend_gdk.c
(they could be enabled by a config option if we can't find a python
replacement for pixbuf_get_pixels_array)
JDH

We are getting seg faults on our Solaris platform at work when we use
the blit API in GTKAgg. This has been going on for a while, and I
don't know if it is in our pygtk version, or what. The line that is
causing the crash is in src/_gtkagg.cpp
 GdkDrawable *drawable = GDK_DRAWABLE(py_drawable->obj);
But rather than spend any more time trying to track that down, I
decided to try and remove the gtk extension code entirely, which would
be a great help for building mpl and distributing binaries. I feel
like I am close, but something is still not clicking (at least on my
platform).
I'm attaching an svn diff in case anyone has some ideas -- basically,
it removes the use of agg_to_gtk_drawable in
backend_gtkagg.FigureCanvasGTKAgg.blit and replaces it with gdk
pixmap/pixbuffer calls. If anyone has any ideas, please let me know.
Attached also is the example code I am using to test. Strangely, the
agg buffer seems to be updating internally but the gtk window is only
updating when I hover my mouse over it, and then only once until I
activate another window and then re-hover over the mpl animation
window.
Thanks for any help!
JDH

Hello developers,
I'm seeing what appears to be a bug when plotting bars next to each
other without edges. In pdf output, you can see that there is a tiny
gap in between each bar, which renders as one pixel wide no matter how
far I zoom in. It's also visible in interactive or png output:
http://www.dumpt.com/img/viewer.php?file=mc0wf07aksrzqs1h8j5k.png
You can generate the above by running a slightly modified demo:
-------------------------------------------
#!/usr/bin/env python
# a stacked bar plot with errorbars
import numpy as np
import matplotlib.pyplot as plt
N = 5
menMeans = (20, 35, 30, 35, 27)
womenMeans = (25, 32, 34, 20, 25)
menStd = (2, 3, 4, 1, 2)
womenStd = (3, 5, 2, 3, 3)
ind = np.arange(N) # the x locations for the groups
width = 1.0 # CHANGED from 0.35 in the demo
# CHANGED: adding linewidth=0 to these calls
p1 = plt.bar(ind, menMeans, width, color='r', yerr=womenStd, linewidth=0)
p2 = plt.bar(ind, womenMeans, width, color='y', linewidth=0,
 bottom=menMeans, yerr=menStd)
plt.ylabel('Scores')
plt.title('Scores by group and gender')
plt.xticks(ind+width/2., ('G1', 'G2', 'G3', 'G4', 'G5') )
plt.yticks(np.arange(0,81,10))
plt.legend( (p1[0], p2[0]), ('Men', 'Women') )
plt.show()
-------------------------------------------
Any thoughts on why there's always a tiny gap between bars?
Thanks,
Jeff
|| Jeff Klukas
|| Physics Lecturer, University of Wisconsin -- Whitewater
|| Research Assistant, University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://hep.wisc.edu/~jklukas/

On 11/08/2010 09:38 PM, Benjamin Root wrote:
>
> Thanks, that seems to do the trick. What is it that one can do anyway
> with this pan/zoom mode? All I seem to be able to do is move the
> labeling for the radial distance.
Right mouse button zooms the radial axis, analogously to how the right 
mouse button zooms axes in a rectilinear plot.
Mike

Hi,
On Mon, Nov 8, 2010 at 7:06 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett <mat...@gm...> wrote:
...
>> and so on. I mean, the ability to keep the code context across the
>> page, both in the ..plot: and ..testcode:: and even >>> directives, so
>> I can build up my tutorial examples on top of the previous results.
>> That step would make it the perfect tool for the tutorials that I have
>> ready to port - and I am sure - many others.
>>
>> Is that already possible? If not, how easy would it be? It if isn't
>> easy, can y'all give me some pointers as to how to get there?
>
> This is a useful feature I've wanted myself. I just contributed a
> change to the plot directive in svn to support this using two new
> options :context: and :nofigs:, and updated the sampledoc tutorial.
> The relevant bit from the tutorial is in the link below:
>
> http://matplotlib.sourceforge.net/sampledoc/extensions.html#inserting-matplotlib-plots
>
> Also, we have a really useful ipython directive that is stateful by
> default, and includes many options for suppressing input blocks,
> doctesting on output blocks, saving figures, and more. It is included
> in the ipython src tree. My original proposal is at
> http://matplotlib.sourceforge.net/ipymode/_build/html/proposal.html,
> which I've implemented with minor changes. A real world working
> example from some lecture notes I prepared recently is attached as
> convolution.rst, and some notes are below. I need to get this added
> to the sampledoc tutorial....
Thanks for extensions, and the pointer to the ipython directive, I had
only half remembered it, but it does look very well designed for what
I had in mind.
For the first time for a few years, I'm looking forward to writing
some tutorials...
See you,
Matthew