matplotlib-devel Mailing List for matplotlib (Page 3)

Joey Wilson wrote:
> I would like to be able to save the figures from 
> matplotlib in an editable form, without flattening down to an image 
> file. 
> Now, I understand that resources are limited, so I would be willing to 
> raise some money to get this feature added to Matplotlib. 
I think to do this right, you'd need to completely re-design MPL to be 
based on a more declarative structure: i.e. you'd define what the 
objects were in a figure, and MPL would generate the figure from the 
declaration -- much like how an drawing is generated from SVG. Maybe 
it's not as big a re-factor I think it is, but it seems that MPL is 
built to be used from a scripting interface instead: a series of 
commands that builds the figure.
Honestly, for your purposes, I don't know that there is much difference. 
I suppose what you are looking for a is a way to get a script that you 
could edit and re-run, but have it generated from a figure 
automatically, the figure itself could have been generated by a 
different script (intermeshed with computational code), or an 
interactive session, or....
That would be pretty cool, but I think a bit of re-factoring of your 
process would make it pretty easy to edit and re-run your scripts anyway.
> I 
> would really like to completely replace Matlab with Python,Scipy, and 
> Matplotlib.
How does Matlab handle this? In my Matlab days, I wrote scripts that 
generated my figures, and when I needed to change them, I edited the 
scripts and re-ran them -- exactly the workflow we're suggesting for 
Python/MPL. But that was 10 years ago...
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

On Thu, Dec 17, 2009 at 5:03 PM, Andrew Straw <str...@as...> wrote:
> It's not clear to me if this proposal lets one specify any arbitrary affine
> transformation. Does it?
I believe it does. 3 coordinates will define 6 equations where we have
6 unknowns of the affine matrix.
The question is how user want to specify the transform.
The extended extent keyword would be useful for the cases like the
pseudo-perspective projection that you mentioned. But, it will not be
very convenient for the cases like simple rotation.
>
> In general -- very nice. Thanks.
>
> In specific, I think the way you have already implemented things is
> sufficient. I think if a user can write a little helper function (as in your
> demo) to avoid a dumbed-down API being part of MPL, that would be best.
> Anyone specifying their own affine transform is probably going to want a
> pretty precise level of control, anyway. (Of course if your extent keyword
> proposal is already a general purpose API, then please ignore this comment.)
I, personally, don't like the idea that user needs to define his/her
own transform to rotate/skew the image. Rotation and skew seems more
like properties of the image, rather than the transform.
Anyhow, unless others step in, I may leave it as is (partially because
I don't have much use case for rotated/skewed images for now). And, I
hope someone implement similar affine transform for other backends.
For the backends that requires resampling (agg, etc.), it might be
better if the affine transform is taken care during the resampling
(i.e., in the Image.draw method) rather than to be delegated to the
backends.
Regards,
-JJ
>
> -Andrew
>

Jae-Joon Lee wrote:
> What I have in my mind is to extend the "extent" keyword of the imshow
> and make it optionally take a tuple of 6 numbers, which are (x1,
> x_lrc, x2, y1, y_lrc, y2).
> x1, x2, y1, y2 are same as the original "extent", and the (x_lrc,
> y_lrc) represent the coordinate of the lower-right corner of the
> image.
> 
It's not clear to me if this proposal lets one specify any arbitrary 
affine transformation. Does it?
> Any thought?
> 
In general -- very nice. Thanks.
In specific, I think the way you have already implemented things is 
sufficient. I think if a user can write a little helper function (as in 
your demo) to avoid a dumbed-down API being part of MPL, that would be 
best. Anyone specifying their own affine transform is probably going to 
want a pretty precise level of control, anyway. (Of course if your 
extent keyword proposal is already a general purpose API, then please 
ignore this comment.)
-Andrew

I change the api to support an arbitrary affine transform. The current api is
 def draw_image(self, gc, x, y, im, dx=None, dy=None, transform=None):
dx, dy is the width and height of the image, i.e.,
The 4 edge points of the image will be
 (x, y), (x+dx, y), (x+dx, y+dy), (x, y+dy) after transformed by *transform*.
And if transform involves rotation or skew, the image should also be
rotated and skewed.
Attached is a small example to utilized this functionality.
Note that it only works with the ps-backend.
I personally don't have much use case for rotated or skewed images.
So, it would be great if others can suggest some user-space api.
What I have in my mind is to extend the "extent" keyword of the imshow
and make it optionally take a tuple of 6 numbers, which are (x1,
x_lrc, x2, y1, y_lrc, y2).
x1, x2, y1, y2 are same as the original "extent", and the (x_lrc,
y_lrc) represent the coordinate of the lower-right corner of the
image.
So, the imshow in the attached example will become somthing like
im = plt.imshow(Z, interpolation='nearest', cmap=cm.jet,
 origin='lower', extent=[-2, 3, 4, -3, -2, 2])
And, the transformation will be calculated internally by the Image class.
Any thought?
-JJ
On Wed, Dec 16, 2009 at 3:41 PM, Andrew Straw <str...@as...> wrote:
> Jae-Joon Lee wrote:
>>
>> On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen <jk...@ik...> wrote:
>>
>>>
>>> While the backend API is being changed, would it be similarly easy to
>>> support arbitrary affine transformations? It would make the API more
>>> symmetric, since many other draw_* methods take an affine
>>> transformation, and I guess at least the PS and PDF backends could
>>> easily support this.
>>>
>>>
>>
>> Yes, supporting arbitrary affine transform would not be difficult. On
>> the other hand, I'm not sure if that feature is practically useful,
>> assuming that other rasterizing backend won't implement it. I'll think
>> about it.
>
> I second the notion that affine transformations on images would be useful.
> There are a lot of things one can do with this, such as make
> pseudo-perspective projections of texture-mapped rectangles. This is exactly
> one of the things that I routinely do in Inkscape.
>
> I'm reasonably sure Cairo supports arbitrary affine transformations when
> drawing image data -- I don't know about Agg.
>
> -Andrew
>

On Wed, Dec 16, 2009 at 4:45 PM, Joey Wilson <dou...@gm...> wrote:
> Let me say why I think this feature is so essential. Anyone who is in
> research or academia knows that figures often need to be edited when a
> publication comes back from peer review. It's already happened to me many
> times, and I've learned that I absolutely have to save my figures for later
> editing to save myself a lot of time. Some people have argued that a script
> that generates the plots/figures should be saved, and that if you need to
> edit the figure, just re-run the script. The problem with this argument is
> that scientific plots often take hours, days, or even weeks of computation
> to generate. For example, generating a bit-error-rate curve in
> communications takes days. Therefore, always re-running from a script is
> just not practical.
Ignoring the issue of having saved matplotlib figures, I'd argue you
should separate the parts of the code that do computation from those
that do plotting into separate scripts. Is there anything keeping you
from saving all of the results from the computation into (for
instance) a NetCDF file? Then the plotting script can just read in
the file and do the plotting. This is exactly how my workflow is set
up. I'd be happy to address any concerns you see with doing things
this way.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

2009年12月16日 Joey Wilson <dou...@gm...>:
> Does anyone know the status of development for Matplotlib persistent figure
> saving? I would like to be able to save the figures from matplotlib in an
> editable form, without flattening down to an image file. The closest thing
> to this right now is the SVG output, but a native mpl format would be
> better. I need to be able to save the figure, so that later it can be
> loaded, edited, and re-saved. I know that this topic has been somewhat
> discussed in the past, but I believe it is desperately needed, so I thought
> I would bring it back up.
> Let me say why I think this feature is so essential. Anyone who is in
> research or academia knows that figures often need to be edited when a
> publication comes back from peer review. It's already happened to me many
> times, and I've learned that I absolutely have to save my figures for later
> editing to save myself a lot of time. Some people have argued that a script
> that generates the plots/figures should be saved, and that if you need to
> edit the figure, just re-run the script. The problem with this argument is
> that scientific plots often take hours, days, or even weeks of computation
> to generate. For example, generating a bit-error-rate curve in
> communications takes days. Therefore, always re-running from a script is
> just not practical.
> Now, I understand that resources are limited, so I would be willing to raise
> some money to get this feature added to Matplotlib. It's desperately needed
> by myself and many others in the community. I would really like to
> completely replace Matlab with Python,Scipy, and Matplotlib. MPL is an
> excellent tool, and it could be even more useful/professional with the
> addition of a figure save feature.
> Any thoughts?
Leaving entirely aside any question of persistence, do you find
matplotlib plots to be modifiable in the ways you want? I find for
anything beyond minor changes of axes, I end up rerunning my plotting
command anyway - for example, I suppose it's possible to change a line
on an existing plot from red to black, but I just rerun the plotting
command. What about adding/removing error bars? changing the number of
bins, range, or starting position of your histogram? plotting the
square root instead of the logarithm of the image values? removing
bogus data points (or adding back in points you I previously removed)?
It seems to me that all of these things require me to keep the
original data around.
Since that's the case, I usually generate my plots in one of two ways:
either I just write a script that runs the calculation and generates
the plot, or I write one script to generate the data and save it to
disk, and another to plot the data from disk. This is sometimes mildly
annoying when a script is just a bit slow, but not enough to warrant
saving the data to disk. In those cases if I must I can run the script
under ipython and modify the plot, then save out the modifications to
a script.
Now, if you want a very-low-effort way to save your data to disk, I
agree that would be valuable to have, but there are, in ascending
order of complexity and power, the native numpy data format, pyfits,
and pytables/pyhdf.
Anne

Does anyone know the status of development for Matplotlib persistent figure
saving? I would like to be able to save the figures from matplotlib in an
editable form, without flattening down to an image file. The closest thing
to this right now is the SVG output, but a native mpl format would be
better. I need to be able to save the figure, so that later it can be
loaded, edited, and re-saved. I know that this topic has been somewhat
discussed in the past, but I believe it is desperately needed, so I thought
I would bring it back up.
Let me say why I think this feature is so essential. Anyone who is in
research or academia knows that figures often need to be edited when a
publication comes back from peer review. It's already happened to me many
times, and I've learned that I absolutely have to save my figures for later
editing to save myself a lot of time. Some people have argued that a script
that generates the plots/figures should be saved, and that if you need to
edit the figure, just re-run the script. The problem with this argument is
that scientific plots often take hours, days, or even weeks of computation
to generate. For example, generating a bit-error-rate curve in
communications takes days. Therefore, always re-running from a script is
just not practical.
Now, I understand that resources are limited, so I would be willing to raise
some money to get this feature added to Matplotlib. It's desperately needed
by myself and many others in the community. I would really like to
completely replace Matlab with Python,Scipy, and Matplotlib. MPL is an
excellent tool, and it could be even more useful/professional with the
addition of a figure save feature.
Any thoughts?
-Joey Wilson
span.ece.utah.edu/joey-wilson

Jae-Joon Lee wrote:
> On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> 
>> While the backend API is being changed, would it be similarly easy to
>> support arbitrary affine transformations? It would make the API more
>> symmetric, since many other draw_* methods take an affine
>> transformation, and I guess at least the PS and PDF backends could
>> easily support this.
>>
>> 
>
> Yes, supporting arbitrary affine transform would not be difficult. On
> the other hand, I'm not sure if that feature is practically useful,
> assuming that other rasterizing backend won't implement it. I'll think
> about it.
I second the notion that affine transformations on images would be 
useful. There are a lot of things one can do with this, such as make 
pseudo-perspective projections of texture-mapped rectangles. This is 
exactly one of the things that I routinely do in Inkscape.
I'm reasonably sure Cairo supports arbitrary affine transformations when 
drawing image data -- I don't know about Agg.
-Andrew

On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen <jk...@ik...> wrote:
> Jae-Joon Lee <lee...@gm...> writes:
>
>> While extending this to other backend such as pdf and svg should be
>> straight forward, I want to hear how others think about the overall
>> approach, e.g., api change and such. The current approach is to
>> minimize change in backends.
>
> While the backend API is being changed, would it be similarly easy to
> support arbitrary affine transformations? It would make the API more
> symmetric, since many other draw_* methods take an affine
> transformation, and I guess at least the PS and PDF backends could
> easily support this.
>
Yes, supporting arbitrary affine transform would not be difficult. On
the other hand, I'm not sure if that feature is practically useful,
assuming that other rasterizing backend won't implement it. I'll think
about it.
>> * If there are multiple images (and the ps backend is used), the
>> images are resampled as they are compositted into a single image.
>
> The Figure.draw method already has some logic for not compositing
> multiple images:
>
>    if len(self.images)<=1 or not_composite or \
>        not allequal([im.origin for im in self.images]):
>
> I suppose this could also include a check for whether all images have
> the same transformation. Anyway, I'm not quite sure what the win from
> compositing is for a vector backend.
One benefit of compositing would be an indirect support of alpha
compositing in the ps backend, although it is not clear this is
practically useful. Checking whether compositing is required seems not
very straight forward to me. We may try to sort out images that needs
to be composited and those does not. Anyhow, I am personally happy
with the current behavior so I may leave it as is, and let others take
it if they want.
>
>> * The current solution forces not to resample whenever
>> interpolation=="nearest", I think this is generally good behavior.
>> However, on the highly extreme case of very high resolution of image
>> (e.g., image dpi > 1000 ?), it might be better if the image is
>> resampled (i.e., downsampled).
>
> This sounds like it would make sense for naive users but could get very
> annoying for somebody who really does want high resolution (e.g. for
> zooming in in a viewer application).
What I meant was the case when the dpi of the image painted on the
canvas is much higher than the dpi of the canvas itself (I mean the
dpi of the typical postscript output device). Anyhow, I guess the
current behavior is good enough, and it seems more reasonable to let
users do the down-sampling explicitly if they want.
Regards,
-JJ
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Jae-Joon Lee <lee...@gm...> writes:
> While extending this to other backend such as pdf and svg should be
> straight forward, I want to hear how others think about the overall
> approach, e.g., api change and such. The current approach is to
> minimize change in backends.
While the backend API is being changed, would it be similarly easy to
support arbitrary affine transformations? It would make the API more
symmetric, since many other draw_* methods take an affine
transformation, and I guess at least the PS and PDF backends could
easily support this.
> * If there are multiple images (and the ps backend is used), the
> images are resampled as they are compositted into a single image.
The Figure.draw method already has some logic for not compositing
multiple images:
 if len(self.images)<=1 or not_composite or \
 not allequal([im.origin for im in self.images]):
I suppose this could also include a check for whether all images have
the same transformation. Anyway, I'm not quite sure what the win from
compositing is for a vector backend.
> * The current solution forces not to resample whenever
> interpolation=="nearest", I think this is generally good behavior.
> However, on the highly extreme case of very high resolution of image
> (e.g., image dpi > 1000 ?), it might be better if the image is
> resampled (i.e., downsampled).
This sounds like it would make sense for naive users but could get very
annoying for somebody who really does want high resolution (e.g. for
zooming in in a viewer application).
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Packt is offering a free copy of Sandro Tosi's new book "Matplotlib
for Python Developers" to matplotlib developers, and has generously
offered to donate 2% of book sales to the mpl project.
If you are an svn committer and would like a copy of the book, send me
your name and shipping address offlist and I will pass it on to the
publisher.
http://www.amazon.com/Matplotlib-Python-Developers-Sandro-Tosi/dp/1847197906/ref=sr_1_1?ie=UTF8&s=books&qid=1260986058&sr=8-1
JDH

A patch that enables drawing image in ps backend without resampling is
committed in r8035.
So, please test it if you're interested.
The raw image is to be used only when interpolation=="nearest" and
there is only one image.
While extending this to other backend such as pdf and svg should be
straight forward, I want to hear how others think about the overall
approach, e.g., api change and such. The current approach is to
minimize change in backends.
There are a few minor issues, whose solution is not clear to me.
* If there are multiple images (and the ps backend is used), the
images are resampled as they are compositted into a single image.
* The current solution forces not to resample whenever
interpolation=="nearest", I think this is generally good behavior.
However, on the highly extreme case of very high resolution of image
(e.g., image dpi > 1000 ?), it might be better if the image is
resampled (i.e., downsampled).
One option would be to introduce a new "resample" keyword in the
imshow command (which will become the attribute of the images).
Regards,
-JJ

On Tue, Dec 15, 2009 at 9:57 AM, Andrew Straw <str...@as...> wrote:
>
>  notch_max = med + 1.57*iq/np.sqrt(row)
>  notch_min = med - 1.57*iq/np.sqrt(row)
>
> Is this code actually calculating a meaningful value? If so, what?
>
>From the statistics ignoramus in the room, so take this with a grain
of salt... I'd write that code as
notch_max = med + (iq/2) * (pi/np.sqrt(row))
and it makes more sense. The notch limits are an estimate of the
interval of the median, which is (one-half, for each up/down) the
q3-q1 range times a normalization factor which is pi/sqrt(n), where
n==row=len(d). The 1/sqrt(n) makes some sense, as it's the usual
statistical error normalization factor. The multiplication by pi, I'm
not so sure, and I can't find that exact formula in any quick stats
reference, but I'm sure someone who actually knows stats can point out
where it comes from.
Note that the code below does:
 if notch_max > q3:
 notch_max = q3
 if notch_min < q1:
 notch_min = q1
though matlab explicitly states in:
http://www.mathworks.com/access/helpdesk/help/toolbox/stats/boxplot.html
that
"""
Interval endpoints are the extremes of the notches or the centers of
the triangular markers. When the sample size is small, notches may
extend beyond the end of the box.
"""
So it seems to me that the more principled thing to do would be to
leave those notch markers outside the box if they land there, because
that's a warning of the robustness of the estimation. Clipping them to
q1/q3 is effectively hiding a problem...
cheers,
f

Hi,
I've been reading about box plots and examining the source code for 
boxplot() lately. While there doesn't seem to be a convention about what 
the notch specifies, I can't find any justification (or text describing) 
what exactly the MPL notch is. The source code is:
 # get median and quartiles
 q1, med, q3 = mlab.prctile(d,[25,50,75])
 iq = q3 - q1
 notch_max = med + 1.57*iq/np.sqrt(row)
 notch_min = med - 1.57*iq/np.sqrt(row)
Is this code actually calculating a meaningful value? If so, what?
The original commit was r1098, which doesn't offer a useful comment 
either (only "aaplied several sf patches" ... looking through the SF bug 
tracker, I couldn't find anything relevant from before the commit date 
of 2005年03月28日).

The following (uncommitted) test currently fails. The reason is that 
mlab.prctile(x,50) doesn't handle even length sequences according to the 
numpy and wikipedia convention for the definition of median. Do we agree 
that it should pass?
Not only would I commit the test, but I also have a fix to make it pass, 
derived from scipy.stats.scoreatpercentile().
This would affect boxplot, if not more.
def test_prctile():
 # test odd lengths
 x=[1,2,3]
 assert mlab.prctile(x,50)==np.median(x)
 # test even lengths
 x=[1,2,3,4]
 assert mlab.prctile(x,50)==np.median(x)
 # derived from email sent by jason-sage to MPL-user on 20090914
 ob1=[1,1,2,2,1,2,4,3,2,2,2,3,4,5,6,7,8,9,7,6,4,5,5]
 p = [75]
 expected = [5.5]
 # test vectorized
 actual = mlab.prctile(ob1,p)
 assert np.allclose( expected, actual )
 # test scalar
 for pi, expectedi in zip(p,expected):
 actuali = mlab.prctile(ob1,pi)
 assert np.allclose( expectedi, actuali )

==========================
Announcing EuroScipy 2010
==========================
---------------------------------------------------
The 3rd European meeting on Python in Science
---------------------------------------------------
**Paris, Ecole Normale Supérieure, July 8-11 2010**
We are happy to announce the 3rd EuroScipy meeting, in Paris, July 2010.
The EuroSciPy meeting is a cross-disciplinary gathering focused on the
use and development of the Python language in scientific research.
This event strives to bring together both users and developers of
scientific tools, as well as academic research and state of the art
industry.
Important dates
==================
====================================== ===================================
**Registration opens** Sunday March 29 
**Paper submission deadline** Sunday May 9 
**Program announced** Sunday May 22 
**Tutorials tracks** Thursday July 8 - Friday July 9
**Conference track** Saturday July 10 - Sunday July 11 
====================================== ===================================
Tutorial
=========
There will be two tutorial tracks at the conference, an introductory one,
to bring up to speed with the Python language as a scientific tool, and
an advanced track, during which experts of the field will lecture on
specific advanced topics such as advanced use of numpy, scientific
visualization, software engineering...
Main conference topics
========================
We will be soliciting talks on the follow topics:
- Presentations of scientific tools and libraries using the
 Python language, including but not limited to:
 - Vector and array manipulation
 - Parallel computing
 - Scientific visualization
 - Scientific data flow and persistence
 
 - Algorithms implemented or exposed in Python
 - Web applications and portals for science and engineering
- Reports on the use of Python in scientific achievements or ongoing 
 projects.
- General-purpose Python tools that can be of special interest to the
 scientific community.
Keynote Speaker: Hans Petter Langtangen 
==========================================
We are excited to welcome Hans Petter Langtangen as our keynote speaker.
- Director of scientific computing and bio-medical research at Simula
 labs, Oslo
- Author of the famous book Python scripting for computational science
 http://www.springer.com/math/cse/book/978-3-540-73915-9
-- 
 
Gaël Varoquaux, conference co-chair
Nicolas Chauvat, conference co-chair
 
Program committee
.................
Romain Brette (ENS Paris, DEC)
Mike Müller (Python Academy)
Christophe Pradal (CIRAD/INRIA, DigiPlantes team)
Pierre Raybault (CEA, DAM)
Jarrod Millman (UC Berkeley, Helen Wills NeuroScience institute)

Jae-Joon Lee wrote:
> The recent zorder-related changes broke the some of the rasterization
> feature, and I just committed a fix. In doing so, I replaced
> 
> dsu.sort(key=lambda x: x[0])
> 
> to
> 
> dsu.sort(key=itemgetter(0))
> 
> which I think is slightly faster (although speed is not much of concern here).
> 
Jae-Joon,
Thanks for pointing that out. I didn't even know about itemgetter; I 
have never paid any attention to the operator module.
Eric

Jae-Joon Lee wrote:
> The recent zorder-related changes broke the some of the rasterization
> feature, and I just committed a fix.
Thanks Jae-Joon.
Is it easy to turn this into a test so that it never unintentionally 
crops up again?
Thanks,
Andrew

The recent zorder-related changes broke the some of the rasterization
feature, and I just committed a fix. In doing so, I replaced
 dsu.sort(key=lambda x: x[0])
to
 dsu.sort(key=itemgetter(0))
which I think is slightly faster (although speed is not much of concern here).
Regards,
-JJ
On Tue, Dec 1, 2009 at 11:17 PM, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
>> On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <ef...@ha...> wrote:
>>> This is easy to fix by using the key kwarg (added in python 2.4) of the
>>> sort method, because python uses a stable sort. It looks like it only
>>> needs to be fixed in Axes.draw, because Figure.draw has never paid any
>>> attention to zorder anyway. I'll do it now.
>>
>> It does now in svn HEAD -- I just added this yesterday.
>
> Yes, I saw that after I sent the first message, so I stabilized the sort
> in Figure.draw also.
>
> Eric
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

How are you doing now?
Hey, Dear;
 How are you doing these days.
I would Like to introduce you a shop.
There, you can find thousands of goods.Visit it, you will can find a great thing for your Christams Party.
 You can spend some time to visit it and.
Merry Christams!
http://www.uggby.com/ 
To view Lincoln's profile or write on his Wall, follow this link: >>http://www.uggby.com/
Believe in them.
Want to control which emails you receive from Facebook? Go to: http://www.uggby.com/
work time:0:00--12:00 12:00--24.00 Copyright ? 2009 www.uggby.com all rights reserved chian shop 
 		 	 		 
_________________________________________________________________
Windows Live Hotmail is faster and more secure than ever.
http://www.microsoft.com/windows/windowslive/hotmail_bl1/hotmail_bl1.aspx?ocid=PID23879::T:WLMTAGL:ON:WL:en-ww:WM_IMHM_1:092009 

Hi,
Thanks for reporting this bug, I fixed it in svn. In the maintenance
branch as well, so it will appear in next releases.
Regards,
Reinier
On Thu, Nov 19, 2009 at 4:14 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Nov 19, 2009 at 6:02 AM, Ensitof <ens...@gm...> wrote:
>>
>> I got the same problem and posted my question in this forum
>> http://www.developpez.net/forums/d836964/autres-langages/python-zope/calcul-scientifique/matplotlib-scatter3d-colorisation-fonction-z/
>> (here) a few days ago... My question receives a lot of visits but no
>> reaction however I think it may be an important information for people
>> wanting to use matplotlib efficiently. Please let me know if you can find
>> anything about it :confused: Even if everything works perfect with 2D
>> scatter I can't solve this issue with scatter3D. Knowing that's it's a bug
>> should already be a nice answer...
>>
>
> Please file a bug on the tracker and I will assign it to Reinier
>
> http://sourceforge.net/tracker/?atid=560720&group_id=80706&func=browse
>
> Thanks,
> JDH
>
-- 
Reinier Heeres
Tel: +31 6 10852639

I updated to the newest release of OS X---10.6.2---last night and I've been getting a weird windowing error for certain backends. 
I'm able to reproduce the error with the following: run a simple plot script (which calls plt.show) from the terminal. Close the figure. The problem is:
* tkagg: window closes, but it doesn't return control to the terminal (i.e. terminal hangs).
* macosx: axis is cleared from the figure window, but the window (w/o axis) remains and terminal hangs.
* qt4agg: works fine.
Alternatively, I can run the script from ipython. In this case, tkagg and qt4agg work as normal. The macosx backend hangs, the window does not close, and control is not returned to ipython.
In all cases, the plot shows up fine (it just doesn't always close properly). Running the script with python -vv doesn't help: All the debug code it prints stops before plt.show is called. I wish I could provide more debug output, but I'm not sure how.
Any ideas?
-Tony
PS. To add another piece to the mystery, I've been having problems running plot scripts from my text editor (Textmate): python hangs **before** plotting. I've traced the hang to a call to matplotlib.backends.pylab_setup.new_figure_manager, but I really don't understand where exactly hangs. Again: this only happens when running from Textmate, and started happening about a week ago (following a Textmate update). My guess is that this is a Textmate-related issue, but I thought I'd mention it in case these two issues combined suggest a more fundamental problem with my python install.

Christopher Barker wrote:
> The diskimage is usually built for the python binary supplied by 
> python.org -- that is what the message means by the "system version". I 
> tried to submit a patch to change that message a year or two ago, but I 
> guess it never got applied -- maybe I'll try again.
I took a look at the source for the latest bdist_mpkg -- it looks like 
it should now give a message like:
"This package requires MacPython to be installed"
though It's all a bit complicated -- did whoever built the dmg use the 
latest bdist_mpkg?
But maybe should still do:
> A note to developers/distributors:
> 
> Robin Dunn figured out a way to install a binary wxPython that will work 
> with both the Apple and the python.org binaries. What it does it put it 
> in /usr/local, and then put a pth file in both of the pythons so that it 
> can be found. A bit of a hack, but it works, and I've never heard anyone 
> have a problem with it.
> 
> Perhaps we should do the same thing with MPL -- I'm sure he'd be glad to 
> share his scripts for building it.
-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
Chr...@no...

John Hunter wrote:
> On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <ef...@ha...> wrote:
>> This is easy to fix by using the key kwarg (added in python 2.4) of the
>> sort method, because python uses a stable sort. It looks like it only
>> needs to be fixed in Axes.draw, because Figure.draw has never paid any
>> attention to zorder anyway. I'll do it now.
> 
> It does now in svn HEAD -- I just added this yesterday.
Yes, I saw that after I sent the first message, so I stabilized the sort 
 in Figure.draw also.
Eric

On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing <ef...@ha...> wrote:
> This is easy to fix by using the key kwarg (added in python 2.4) of the
> sort method, because python uses a stable sort. It looks like it only
> needs to be fixed in Axes.draw, because Figure.draw has never paid any
> attention to zorder anyway. I'll do it now.
It does now in svn HEAD -- I just added this yesterday.
JDH