matplotlib-devel Mailing List for matplotlib (Page 4)

On Sun, Jul 18, 2010 at 12:05 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva <js...@fc...> wrote:
>
>> On 07/18/2010 04:58 AM, H Mike Duan wrote:
>> > Hi,
>> >
>> > There seems to be a problem in how 3D surfaces and lines are rendered
>> > in mplot3d. The following is a simple script that plots a yellow
>> > sphere, a blue wireframe on the surface of the sphere, and a red
>> > wireframe outside the sphere. The semi-transparent yellow sphere is
>> > rendered beautifully. The blue wireframe can only be seen with certain
>> > viewing angles. The red wireframe is seen all the time, but its part
>> > that is supposedly behind the sphere appears in front of the sphere.
>> > Did I do something wrong or is it a bug of mplot3d? I am using
>> > matplotlib 1.0.0 on Mac OS X 10.6. Thanks!
>> >
>> > -Mike
>>
>> Additionally the presented example (after adding a plt.show()) will give
>> the appended traceback if the sphere is panned around. That won't happen
>> if the line
>>
>> ax = fig.gca(projection='3d')
>>
>> is replaced with:
>>
>> ax = Axes3D(fig)
>>
>> Latest mpl svn (r8565), OS: Debian testing.
>>
>> Regards,
>> João Luís
>>
>>
>>
>> Traceback (most recent call last):
>>   File
>>
>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py",
>> line 253, in button_release_event
>>     FigureCanvasBase.button_release_event(self, x, y, event.button,
>> guiEvent=event)
>>   File
>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>> line 1603, in button_release_event
>>     self.callbacks.process(s, event)
>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
>> line 262, in process
>>     proxy(*args, **kwargs)
>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
>> line 188, in __call__
>>     return mtd(*args, **kwargs)
>>   File
>> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
>> line 2575, in release_pan
>>     a.end_pan()
>>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py",
>> line 2788, in end_pan
>>     del self._pan_start
>> AttributeError: _pan_start
>>
>>
>>
> Joao,
>
> Yes, there is a known issue with objects not properly rendering when viewed
> at certain angles.  How to go about solving this seems to be a difficult one
> to figure out.
>
> Also, thanks for pointing out the difference between calling gca() and
> creating the Axes3D object directly.  I am not sure exactly why there would
> be a difference, but I will look into it right away.
>
> Ben Root
>

Ok, it appears that the .add_subplot() or .gca() approach to creating 3D
axes appears to be adding the axes twice to the figure's canvas.  Therefore,
while the callback to press_pan() is connected only once, the function loops
over all the axes in the figure, and connecting end_pan() twice.

The end_pan() function deletes _pan_start, so the second subsequent call is
trying to delete something that doesn't exist, thereby causing the
traceback.

So, now the question remains, why is the Axes3D object added twice to the
figure?

Ben Root


>
>
>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

On Sun, Jul 18, 2010 at 8:56 AM, João Luís Silva <js...@fc...> wrote:

> On 07/18/2010 04:58 AM, H Mike Duan wrote:
> > Hi,
> >
> > There seems to be a problem in how 3D surfaces and lines are rendered
> > in mplot3d. The following is a simple script that plots a yellow
> > sphere, a blue wireframe on the surface of the sphere, and a red
> > wireframe outside the sphere. The semi-transparent yellow sphere is
> > rendered beautifully. The blue wireframe can only be seen with certain
> > viewing angles. The red wireframe is seen all the time, but its part
> > that is supposedly behind the sphere appears in front of the sphere.
> > Did I do something wrong or is it a bug of mplot3d? I am using
> > matplotlib 1.0.0 on Mac OS X 10.6. Thanks!
> >
> > -Mike
>
> Additionally the presented example (after adding a plt.show()) will give
> the appended traceback if the sphere is panned around. That won't happen
> if the line
>
> ax = fig.gca(projection='3d')
>
> is replaced with:
>
> ax = Axes3D(fig)
>
> Latest mpl svn (r8565), OS: Debian testing.
>
> Regards,
> João Luís
>
>
>
> Traceback (most recent call last):
>   File
>
> "/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py",
> line 253, in button_release_event
>     FigureCanvasBase.button_release_event(self, x, y, event.button,
> guiEvent=event)
>   File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
> line 1603, in button_release_event
>     self.callbacks.process(s, event)
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
> line 262, in process
>     proxy(*args, **kwargs)
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py",
> line 188, in __call__
>     return mtd(*args, **kwargs)
>   File
> "/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py",
> line 2575, in release_pan
>     a.end_pan()
>   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py",
> line 2788, in end_pan
>     del self._pan_start
> AttributeError: _pan_start
>
>
>
Joao,

Yes, there is a known issue with objects not properly rendering when viewed
at certain angles.  How to go about solving this seems to be a difficult one
to figure out.

Also, thanks for pointing out the difference between calling gca() and
creating the Axes3D object directly.  I am not sure exactly why there would
be a difference, but I will look into it right away.

Ben Root



>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 07/18/2010 04:58 AM, H Mike Duan wrote:
> Hi,
>
> There seems to be a problem in how 3D surfaces and lines are rendered
> in mplot3d. The following is a simple script that plots a yellow
> sphere, a blue wireframe on the surface of the sphere, and a red
> wireframe outside the sphere. The semi-transparent yellow sphere is
> rendered beautifully. The blue wireframe can only be seen with certain
> viewing angles. The red wireframe is seen all the time, but its part
> that is supposedly behind the sphere appears in front of the sphere.
> Did I do something wrong or is it a bug of mplot3d? I am using
> matplotlib 1.0.0 on Mac OS X 10.6. Thanks!
>
> -Mike

Additionally the presented example (after adding a plt.show()) will give 
the appended traceback if the sphere is panned around. That won't happen 
if the line

ax = fig.gca(projection='3d')

is replaced with:

ax = Axes3D(fig)

Latest mpl svn (r8565), OS: Debian testing.

Regards,
João Luís



Traceback (most recent call last):
   File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/backends/backend_gtk.py", 
line 253, in button_release_event
     FigureCanvasBase.button_release_event(self, x, y, event.button, 
guiEvent=event)
   File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py", 
line 1603, in button_release_event
     self.callbacks.process(s, event)
   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py", 
line 262, in process
     proxy(*args, **kwargs)
   File "/usr/local/lib/python2.6/dist-packages/matplotlib/cbook.py", 
line 188, in __call__
     return mtd(*args, **kwargs)
   File 
"/usr/local/lib/python2.6/dist-packages/matplotlib/backend_bases.py", 
line 2575, in release_pan
     a.end_pan()
   File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", 
line 2788, in end_pan
     del self._pan_start
AttributeError: _pan_start

Hi,

There seems to be a problem in how 3D surfaces and lines are rendered
in mplot3d. The following is a simple script that plots a yellow
sphere, a blue wireframe on the surface of the sphere, and a red
wireframe outside the sphere. The semi-transparent yellow sphere is
rendered beautifully. The blue wireframe can only be seen with certain
viewing angles. The red wireframe is seen all the time, but its part
that is supposedly behind the sphere appears in front of the sphere.
Did I do something wrong or is it a bug of mplot3d? I am using
matplotlib 1.0.0 on Mac OS X 10.6. Thanks!

-Mike

===================================================
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.pyplot as plt
import numpy as np

fig = plt.figure()
ax = fig.gca(projection='3d')

u = np.linspace(0, 2 * np.pi, 100)
v = np.linspace(0, np.pi, 100)

x = 10 * np.outer(np.cos(u), np.sin(v))
y = 10 * np.outer(np.sin(u), np.sin(v))
z = 10 * np.outer(np.ones(np.size(u)), np.cos(v))
ax.plot_surface(x, y, z,  rstride=4, cstride=4, color='y', alpha=0.5)
ax.plot_wireframe(x, y, z, rstride=10, cstride=10, color='b')
ax.plot_wireframe(x*1.1, y*1.1, z*1.1, rstride=20, cstride=20, color='r')

On Jul 16, 2010, at 4:08 PM, Eric Firing wrote:

> On 07/16/2010 09:45 AM, Tony S Yu wrote:
>> I recently noticed that setting the dpi for savefig doesn't work as
>> expected when saving to pdf. Take the following code, for example:
>> 
>>>>> import matplotlib.pyplot as plt
>>>>> 
>>>>> plt.figure(figsize=(8,6))
>>>>> plt.plot([1,2])
>>>>> plt.savefig('test.png', dpi=100)
>>>>> plt.savefig('test.pdf', dpi=100)
>> 
>> The resulting png file is 800 x 600 (as expected), while the pdf file is
>> 576 x 432 [which is (800 x 600) * 72/100]. I found an old thread
> 
> No, 576 x 432 is the paper size in points, not dots, so it is 8x6 inches 
> as requested.  Since the content is all vector-based, there is no notion 
> of dots or pixels in test.pdf.

[snip]

>> 
>> P.S. maybe enough time has passed that most people have adopted PDF
>> viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be
>> removed? Just a thought.
> 
> No; I think the present behavior is correct, regardless of the pdf 
> version.  It is not really a hard-coded dpi at all, it is a confusing 
> aspect of the way mpl uses variables called "dpi".  (But someone who 
> knows more about pdf may correct me if necessary.)
> 
> Eric

Hmm, that makes sense. 

I was just confused by the fact that some programs use points as dots or pixels when displaying to screen. For example, that's how my presentation software chooses to display embedded PDFs. As a result, an 8in x 6in PNG shows up as a different size than an 8in x 6in PDF. (Yes, you can resize, but this screws up all the font sizes). Anyway, I guess this is more an issue with my presentation software than anything else.

Thanks for the clarification, Eric.

-Tony

Wing IDE recently added support for matplotlib, specifically non 
blocking show(). It might be worth also to test the 4.0 beta release.

http://www.wingware.com/wingide/beta

Christoph


On 7/16/2010 2:26 PM, Eric Firing wrote:
> All,
>
> John noticed that my changes to show() prior to 1.0 had broken a use
> case with tkagg and ipython -pylab, so I fixed that yesterday in
> maintenance branch and trunk.  Today, in 8562 and 8563, I did some
> refactoring to try to make show() behavior more understandable across
> backends, and easier to modify if necessary.  Specifically, we need to
> work with the ipython people to make sure the ipython 0.11 refactoring
> of interactive support works as intended.  I haven't done any testing
> with the development version of 0.11 yet.
>
> At present, all interactive backends start a blocking mainloop only if
> ipython has not attached a _needmain flag to show(), and if mpl is not
> in interactive mode.
>
> Under all script and ipython conditions, multiple calls to show in a
> session or script are permitted.
>
> All interactive backends behave the same when run with ipython -pylab,
> version 0.10: show is non-blocking, regardless of whether it is executed
> on the command line (completely unnecessary) or is found in a script.
>
> Under raw ipython (no -pylab or other threading flags provided), with
> mpl in non-interactive mode, all backends behave the same: show() is
> needed and blocks, but may be called multiple times.  With mpl in
> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
> qt4agg behave the same as in -pylab mode, so there so no longer any real
> need for the special threading modes; but wx* and qtagg do not behave in
> a useful way, so they still need the special threading.
>
> All of the above is based on quick tests with my own system, ubuntu
> 10.04.  I expect it will be the same for other supported systems, with
> the exception that behavior in raw ipython mode, with mpl in interactive
> mode, may not work with some earlier versions of gui toolkits--but I
> suspect we will not actually encounter this for supported versions.
>
> I have not built or tested anything under Windows or OS X.  For the
> latter, testing of the macosx backend is needed.  I expect cocoaagg to
> behave differently than the others, but no differently than it did
> before my changes.
>
> Eric
>

All,

John noticed that my changes to show() prior to 1.0 had broken a use 
case with tkagg and ipython -pylab, so I fixed that yesterday in 
maintenance branch and trunk.  Today, in 8562 and 8563, I did some 
refactoring to try to make show() behavior more understandable across 
backends, and easier to modify if necessary.  Specifically, we need to 
work with the ipython people to make sure the ipython 0.11 refactoring 
of interactive support works as intended.  I haven't done any testing 
with the development version of 0.11 yet.

At present, all interactive backends start a blocking mainloop only if 
ipython has not attached a _needmain flag to show(), and if mpl is not 
in interactive mode.

Under all script and ipython conditions, multiple calls to show in a 
session or script are permitted.

All interactive backends behave the same when run with ipython -pylab, 
version 0.10: show is non-blocking, regardless of whether it is executed 
on the command line (completely unnecessary) or is found in a script.

Under raw ipython (no -pylab or other threading flags provided), with 
mpl in non-interactive mode, all backends behave the same: show() is 
needed and blocks, but may be called multiple times.  With mpl in 
interactive mode, there are two categories: tkagg, fltkagg, gtk*, and 
qt4agg behave the same as in -pylab mode, so there so no longer any real 
need for the special threading modes; but wx* and qtagg do not behave in 
a useful way, so they still need the special threading.

All of the above is based on quick tests with my own system, ubuntu 
10.04.  I expect it will be the same for other supported systems, with 
the exception that behavior in raw ipython mode, with mpl in interactive 
mode, may not work with some earlier versions of gui toolkits--but I 
suspect we will not actually encounter this for supported versions.

I have not built or tested anything under Windows or OS X.  For the 
latter, testing of the macosx backend is needed.  I expect cocoaagg to 
behave differently than the others, but no differently than it did 
before my changes.

Eric

On 07/16/2010 09:45 AM, Tony S Yu wrote:
> I recently noticed that setting the dpi for savefig doesn't work as
> expected when saving to pdf. Take the following code, for example:
>
>  >>> import matplotlib.pyplot as plt
>  >>>
>  >>> plt.figure(figsize=(8,6))
>  >>> plt.plot([1,2])
>  >>> plt.savefig('test.png', dpi=100)
>  >>> plt.savefig('test.pdf', dpi=100)
>
> The resulting png file is 800 x 600 (as expected), while the pdf file is
> 576 x 432 [which is (800 x 600) * 72/100]. I found an old thread

No, 576 x 432 is the paper size in points, not dots, so it is 8x6 inches 
as requested.  Since the content is all vector-based, there is no notion 
of dots or pixels in test.pdf.

> <http://old.nabble.com/figsize-anomaly-in-pdf-td15234278.html>
> suggesting that a dpi of 72 should be hard coded into the PDF renderer
> for compatibility with older versions of the PDF spec. That makes sense;
> however, it'd be nice if the docstring for savefig told users about his
> behavior.

Yes, the docstring probably should point out that for vector backends 
(pdf, ps, svg), the dpi setting affects only the resolution of 
rasterized components.

>
> Below, is a patch to the savefig docstring. I'm sure someone else could
> word this better, but I thought I'd at least try.
>
> Best,
> -Tony
>
> P.S. maybe enough time has passed that most people have adopted PDF
> viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be
> removed? Just a thought.

No; I think the present behavior is correct, regardless of the pdf 
version.  It is not really a hard-coded dpi at all, it is a confusing 
aspect of the way mpl uses variables called "dpi".  (But someone who 
knows more about pdf may correct me if necessary.)

Eric

>
>
> Index: lib/matplotlib/figure.py
> ===================================================================
> --- lib/matplotlib/figure.py (revision 8561)
> +++ lib/matplotlib/figure.py (working copy)
> @@ -1018,7 +1018,10 @@
> *dpi*: [ None | scalar > 0 ]
> The resolution in dots per inch. If *None* it will default to
> - the value ``savefig.dpi`` in the matplotlibrc file.
> + the value ``savefig.dpi`` in the matplotlibrc file. NOTE: when
> + saving to pdf, the dpi will not affect the page dimensions (which
> + is always 72 dpi), but it will affect the resolution of rasterized
> + elements in the plot.
> *facecolor*, *edgecolor*:
> the colors of the figure rectangle
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I recently noticed that setting the dpi for savefig doesn't work as expected when saving to pdf. Take the following code, for example: 

>>> import matplotlib.pyplot as plt
>>> 
>>> plt.figure(figsize=(8,6))
>>> plt.plot([1,2])
>>> plt.savefig('test.png', dpi=100)
>>> plt.savefig('test.pdf', dpi=100)

The resulting png file is 800 x 600 (as expected), while the pdf file is 576 x 432 [which is (800 x 600) * 72/100]. I found an old thread suggesting that a dpi of 72 should be hard coded into the PDF renderer for compatibility with older versions of the PDF spec. That makes sense; however, it'd be nice if the docstring for savefig told users about his behavior.

Below, is a patch to the savefig docstring. I'm sure someone else could word this better, but I thought I'd at least try.

Best,
-Tony

P.S. maybe enough time has passed that most people have adopted PDF viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be removed? Just a thought.


Index: lib/matplotlib/figure.py
===================================================================
--- lib/matplotlib/figure.py	(revision 8561)
+++ lib/matplotlib/figure.py	(working copy)
@@ -1018,7 +1018,10 @@
 
           *dpi*: [ None | scalar > 0 ]
             The resolution in dots per inch.  If *None* it will default to
-            the value ``savefig.dpi`` in the matplotlibrc file.
+            the value ``savefig.dpi`` in the matplotlibrc file. NOTE: when
+            saving to pdf, the dpi will not affect the page dimensions (which
+            is always 72 dpi), but it will affect the resolution of rasterized
+            elements in the plot.
 
           *facecolor*, *edgecolor*:
             the colors of the figure rectangle

(Michael Droettboom)

>> The display at the bottom that says "Cursor at: X, Y" is in pixels, not in

>> data units. ?It would be great if this could display data units, though

>> being general enough to support custom scales (eg. log) and projections (eg.

>> polar) may be tricky without making a round-trip to the server.



(Simon Ratcliffe)

>As you mentioned, the trick is in giving the client some view on how

>pixels should map to data values without fetching these for each mouse

>movement. For simple cartesian plots this is probably pretty

>straightforward. It is something we need to get working for our

>internal use so it should get solved at some stage.

I have accomplished this in one of my applications as follows:

Axes =figure.get_axes()
#The transform used in this axis is Composite Generic Transform, so get the two affine transformation matricies
MatrixA  = axes[0].transData.inverted()._a.get_matrix()
MatrixB  = axes[0].transData.inverted()._b.get_matrix()

I use an Ajax or WebSockets call to get MatrixA and MatrixB to the client (javascript) side, and then do the affine transform in the mousemove callback:

function ev_mousemove(ev){
            if(affineMatrixPopulated){
               //First convert the browser coordinates to the form MPL uses
               var x, y, x2, y2;
               x = ev.clientX - canvas.offsetLeft;
               y = canvas.height - (ev.clientY - canvas.offsetTop);
              //Now it's just a couple matrix multiplications:
              // I flattened the Matrix when transferring from the server process, so affineMatrixA[2] is MatrixA[0,2]
              //      affineMatrixA[4] is MatrixA[1,1] etc...
               x2 = affineMatrixA[0] * x + affineMatrixA[1] * y + affineMatrixA[2];
               y2 = affineMatrixA[3] * x + affineMatrixA[4] * y + affineMatrixA[5];
               x2 = affineMatrixB[0] * x2 + affineMatrixB[1] * y2 + affineMatrixB[2];
               y2 = affineMatrixB[3] * x2 + affineMatrixB[4] * y2 + affineMatrixB[5];
               document.getElementById('cursor_info').innerText = "Cursor at: " + x2 + "," + y2;
            }
        }

The simple affine transformation can be accomplished by leaving off the MatrixB part. Non affine will probably be similar to the above followed by a log or exponential operation.

Ryan Wagner  | Senior Technical Support Engineer |
Rogue Wave Software, Inc.
5500 Flatiron Parkway, Suite 200, Boulder, CO 80301
rya...@ro...<mailto:rw...@vn...>
www.roguewave.com

On 07/14/2010 11:46 PM, Ben North wrote:
> Hi,
>
> Firstly, excellent to see matplotlib reach its 1.0 release!
>
> I came across an inconsistency in the way XAxis and YAxis behave in the
> set_ticks_position() method.  If you remove the X-axis ticks with
>
>      my_axes.xaxis.set_ticks_position('none')
>
> it leaves the labels alone, whereas if you do the same on the Y-axis:
>
>      my_axes.yaxis.set_ticks_position('none')
>
> it removes both sets of labels.  The docstring for the X-axis method
> says "'none' and 'both' affect only the ticks, not the labels", and
> although the Y-axis docstring doesn't have this phrase, I guess it's
> probably intended that the labels are left alone there too.  The patch
> below does this.

Ben,

Thank you.  Behavior and docstring are fixed in 8554, 8555.

Eric

>
> Thanks,
>
> Ben.
>
>
>
> --- ORIG--axis.py       2010-07-15 10:37:08.000068000 +0100
> +++ axis.py     2010-07-15 10:43:14.000195000 +0100
> @@ -1906,8 +1906,8 @@
>               self.set_tick_params(which='both', right=True,
>                                    left=True)
>           elif position == 'none':
> -            self.set_tick_params(which='both', right=False, labelright=False,
> -                                 left=False, labelleft=False)
> +            self.set_tick_params(which='both', right=False,
> +                                 left=False)
>           elif position == 'default':
>               self.set_tick_params(which='both', right=True, labelright=False,
>                                    left=True, labelleft=True)
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

Firstly, excellent to see matplotlib reach its 1.0 release!

I came across an inconsistency in the way XAxis and YAxis behave in the
set_ticks_position() method.  If you remove the X-axis ticks with

    my_axes.xaxis.set_ticks_position('none')

it leaves the labels alone, whereas if you do the same on the Y-axis:

    my_axes.yaxis.set_ticks_position('none')

it removes both sets of labels.  The docstring for the X-axis method
says "'none' and 'both' affect only the ticks, not the labels", and
although the Y-axis docstring doesn't have this phrase, I guess it's
probably intended that the labels are left alone there too.  The patch
below does this.

Thanks,

Ben.



--- ORIG--axis.py       2010-07-15 10:37:08.000068000 +0100
+++ axis.py     2010-07-15 10:43:14.000195000 +0100
@@ -1906,8 +1906,8 @@
             self.set_tick_params(which='both', right=True,
                                  left=True)
         elif position == 'none':
-            self.set_tick_params(which='both', right=False, labelright=False,
-                                 left=False, labelleft=False)
+            self.set_tick_params(which='both', right=False,
+                                 left=False)
         elif position == 'default':
             self.set_tick_params(which='both', right=True, labelright=False,
                                  left=True, labelleft=True)

On Sat, Jul 10, 2010 at 9:49 PM, John Hunter <jd...@gm...> wrote:
> On Sat, Jul 10, 2010 at 9:38 PM, Ryan May <rm...@gm...> wrote:
>> 2.6.  With Python 3.1, I get a compile failure with src/ft2font.cpp,
>> which isn't surprising.
>
> I'm a little surprised ft2font is failing, since it is a CXX module,
> and I recently upgraded our CXX from v5 to v6 mainly because v6 is
> supposed to be python3 compliant, and I thought this would speed us on
> our way to python3 support.  I thought we would have more problems on
> our hand-rolled extensions.,,,

Yeah, I remember seeing that. Is there some missing magic to get it to
turn on 3.1 support?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 9, 2010 at 7:27 PM, John Hunter <jd...@gm...> wrote:
> Some rapid fire comments, in no particular order
>  * this is completely un-thought out, but could we define a subclass
> of TimedAnimation to work like an iterator so users could do the
> natural thing :
>
>  line, = ax.plot(something)
>  for frame in SomeTimedAnimation(fig, blit=True):
>      line.set_data(mydata)
>      frame.update()

That's an interesting thought.  The challenge would be notifying
SomeTimedAnimation that it needs to stop. Then again, FuncAnimation
already handles this, so it would likely just be a change in syntax,
albeit a good one.

What strikes me now is how to deal with show(). All the animations are
created, and then start once the figures() are displayed with show().
Any ideas on how to make this play with that? At a fundamental level,
these classes are simplifying creating callbacks within the GUI event
loop. I'm not sure the above example can work with that, but I am
ready/willing to be proven wrong.

> * when you integrate this into trunk, I would like to see widgets.py
> upgraded to use it.  This is not a requirement and I would be happy to
> help with it, but it is a good way to push on the new API and expand
> the test cases.

Interested, but I'm not sure I see your vision here. But then again
I'm too close and only see this animation framework as useful for
animating whole figures.  I'm willing to help, but would have to be
led along the way. I will say I was looking at using widgets to make
play/stop/step buttons but haven't really fleshed that out. Those
might also be better done with actual GUI toolkit buttons.

> * I am happy to see this pushed into trunk at any time.  I would not
> push it into the branch, but we can do a 1.1 trunk release as soon as
> we are ready (release early, release often).  Putting it in the trunk
> will facilitate testing and other developer contributions.  But if
> you'd rather leave it in github for a while, I have no problem with
> that either.

Github was a learning experience and a quick convenience for doing
revision control before it was trunk ready. (Which is a reason by
itself to switch to git, full development history rather than
completed chunks.) I'll check in
after I square away a couple more things.

> * you hardcode the artist visible state True/False in ArtistAnimation,
> which overrides any settings the users may be trying to control. Not
> sure if this is a problem, but it's something to think about.  When
> you set False in ArtistAnimation._init_draw, should you first store
> the current state so you can restore the userland settings?  You
> comment that maybe you should be integrating with the "animated"
> property.  This is essentially what this is for, if animated is set it
> should not be used in drawing the background.   Not sure if this
> matters since it may be sensible to assume they are handing you
> control of visibility in ArtistAnimation, just throwing it out there.

I'll have to think about that.

> * in Animation.save, why do you set blit=False?  When making movies,
> shouldn't we also depend on the efficiencies of blit?  Or was the
> idea: blit is buggy so for production movies turn it off cause I'm
> willing to sacrifice performance for quality?
> If so, I'd rather try an fix the bugs....or expose blit as a kwarg.

You pretty much hit the nail on the head. To be honest, I don't think
I've actually tested blitting when saving, I just wasn't ready to
trust the blitting code that much. It should definitely at least be a
kwarg, and I'll have to test to see how reliable it is.

> * a tutorial for the site docs would be awesome.  It's one of the big
> missing pieces in the docs, so this would be a good time to add it.

Definitely. Besides getting everything working, this is #1.

> * when you include animation.py in the trunk, would you write the examples as
>
>  import matplotlib.animation as animation
>  ani = animation.FuncAnimation(fig, ...)
>
>  per the style guidelines in the coding guide.

Didn't realize we had that codified. I probably need to go read that now....

> * let's preserve the old gui specific examples in a subdir of
> examples/animation, so people who need bare metal control will still
> have examples to follow.  You can add a README in that dir suggesting
> the use of the new API unless necessary.

Define "bare metal." Since we have the new timer class, I could
convert the old examples to be backend agnostic without using the
animation framework. Just a thought.

Thanks for the useful feedback,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Jul 10, 2010 at 9:38 PM, Ryan May <rm...@gm...> wrote:
> 2.6.  With Python 3.1, I get a compile failure with src/ft2font.cpp,
> which isn't surprising.

I'm a little surprised ft2font is failing, since it is a CXX module,
and I recently upgraded our CXX from v5 to v6 mainly because v6 is
supposed to be python3 compliant, and I thought this would speed us on
our way to python3 support.  I thought we would have more problems on
our hand-rolled extensions.,,,

JDH

On Sat, Jul 10, 2010 at 4:18 PM, John Hunter <jd...@gm...> wrote:
> On Sat, Jul 10, 2010 at 4:13 PM, Ryan May <rm...@gm...> wrote:
>> both, specifically check_for_tk(). Here we catch the actual exception
>> object and use it to print an error message. If anyone has a
>> suggestion (not print the error? Look at the exception stack?), I'd
>> love to be able to commit these so that at least setup.py runs.
>
> You might want to paste cbook.exception_to_str into setupext.py and
> use that to get the error message.

That actually uses traceback.print_exc(), which prints out a whole
traceback and looks ugly to me. Instead, I went with sys.exc_info(),
which can get the value of the current exception. It's uglier than
getting the exception object in the except statement, but until we can
just support >= 2.6, we're pretty much stuck with it.

Otherwise, I committed the change to setupext.py. Main changes were to
redo some imports (things moved, renamed) and to make print at least
look like a function. I've actually been running with this in place
for quite a few months with no problems. The results at this point are
that matplotlib installs and runs fine for me on Linux with Python
2.6.  With Python 3.1, I get a compile failure with src/ft2font.cpp,
which isn't surprising.

So I guess we're on our way to Python 3!

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Sat, Jul 10, 2010 at 4:13 PM, Ryan May <rm...@gm...> wrote:
> both, specifically check_for_tk(). Here we catch the actual exception
> object and use it to print an error message. If anyone has a
> suggestion (not print the error? Look at the exception stack?), I'd
> love to be able to commit these so that at least setup.py runs.

You might want to paste cbook.exception_to_str into setupext.py and
use that to get the error message.

On Sat, Jul 10, 2010 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
> In case anyone working on mpl development missed it, this may be of
> interest.  I think it's time for us to work seriously on supporting
> python 2 and 3 in the same codebase, following numpy's lead.  I hope we
> can make the transition to git first--and soon.
I agree completely. I've looked at our code base ever so briefly in
terms of getting setup.py to run. I just committed some changes that
work cleanly on both versions and have some more for setupext.py. My
problem is that I can't find a way to make setupext.py run clean on
both, specifically check_for_tk(). Here we catch the actual exception
object and use it to print an error message. If anyone has a
suggestion (not print the error? Look at the exception stack?), I'd
love to be able to commit these so that at least setup.py runs.

Has anyone looked to see if our other dependencies are ported yet:
dateutil, pytz? What about the GUI toolkits? PyQt4 was the only one I
found last I looked.

Ryan

> -------- Original Message --------
> Subject: [Numpy-discussion] ANN: Numpy runs on Python 3
> Date: Sat, 10 Jul 2010 14:30:06 +0000 (UTC)
> From: Pauli Virtanen <pa...@ik...>
> Reply-To: Discussion of Numerical Python <num...@sc...>
> To: num...@sc...
>
> Hi,
>
> As many of you probably already know, Numpy works fully on Python 3 and
> Python 2, with a *single code base*, since March. This work is scheduled
> to be included in the next releases 1.5 and 2.0.
>
> Porting Scipy to work on Python 3 has proved to be much less work, and
> will probably be finished "soon". (Ongoing work is here: http://
> github.com/cournape/scipy3/commits/py3k , http://github.com/pv/scipy-work/
> commits/py3k )
>
> For those who are interested in already starting to port their stuff to
> Python 3, you can use Numpy's SVN trunk version. Grab it:
>
>        svn clone http://svn.scipy.org/svn/numpy/trunk/ numpy
>        cd numpy
>        python3 setup.py build
>
> An important point is that supporting Python 3 and Python 2 in the same
> code base can be done, and it is not very difficult either. It is also
> much preferable from the maintenance POV to creating separate branches
> for Python 2 and 3. We attempted to log changes needed in Numpy at
>
>        http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt
>
> which may be useful (although not completely up-to-date) information for
> people wanting to do make the same transition in their own code.
>
> (Announcement as recommended by our PR department @ EuroScipy :)
>
> --
> Pauli Virtanen
>
> _______________________________________________
> NumPy-Discussion mailing list
> Num...@sc...
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

In case anyone working on mpl development missed it, this may be of 
interest.  I think it's time for us to work seriously on supporting 
python 2 and 3 in the same codebase, following numpy's lead.  I hope we 
can make the transition to git first--and soon.

Eric

-------- Original Message --------
Subject: [Numpy-discussion] ANN: Numpy runs on Python 3
Date: Sat, 10 Jul 2010 14:30:06 +0000 (UTC)
From: Pauli Virtanen <pa...@ik...>
Reply-To: Discussion of Numerical Python <num...@sc...>
To: num...@sc...

Hi,

As many of you probably already know, Numpy works fully on Python 3 and
Python 2, with a *single code base*, since March. This work is scheduled
to be included in the next releases 1.5 and 2.0.

Porting Scipy to work on Python 3 has proved to be much less work, and
will probably be finished "soon". (Ongoing work is here: http://
github.com/cournape/scipy3/commits/py3k , http://github.com/pv/scipy-work/
commits/py3k )

For those who are interested in already starting to port their stuff to
Python 3, you can use Numpy's SVN trunk version. Grab it:

	svn clone http://svn.scipy.org/svn/numpy/trunk/ numpy
	cd numpy
	python3 setup.py build

An important point is that supporting Python 3 and Python 2 in the same
code base can be done, and it is not very difficult either. It is also
much preferable from the maintenance POV to creating separate branches
for Python 2 and 3. We attempted to log changes needed in Numpy at

	http://projects.scipy.org/numpy/browser/trunk/doc/Py3K.txt

which may be useful (although not completely up-to-date) information for
people wanting to do make the same transition in their own code.

(Announcement as recommended by our PR department @ EuroScipy :)

-- 
Pauli Virtanen

_______________________________________________
NumPy-Discussion mailing list
Num...@sc...
http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Jul 9, 2010, at 22:11, John Hunter <jd...@gm...> wrote:

> On Fri, Jul 9, 2010 at 9:59 PM, Eric Firing <ef...@ha...> wrote:
>> On 07/09/2010 11:45 AM, Ryan May wrote:
>>> Hi,
>>> 
>>> I just noticed that ContourSet only inherits ScalarMappable and
>>> ContourLabeller, neither of which is an Artist subclass, which means
>>> ContourSet is not an Artist. (And is why it does not have a remove()
>>> method).  Anyone have any idea why and if we should correct that? I'm
>>> not sure what the ramifications would be.
>> 
>> It's just historical.  Should every plotting command return an Artist,
>> simple or compound?  If so, I suspect contouring is not the only thing
>> that will need refactoring.  I haven't investigated what would be required.
> 
> Ryan, was there a particular use case in which you found that CS was
> not an Artist to be a limitation, or were you just asking out of
> curiosit

Looking at adding a remove method, per another thread. I was confused by the lack of standard machinery, and wasn't sure if I should just add remove method or make it an artist.

Ryan


> 
> JDH
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Jul 9, 2010 at 9:59 PM, Eric Firing <ef...@ha...> wrote:
> On 07/09/2010 11:45 AM, Ryan May wrote:
>> Hi,
>>
>> I just noticed that ContourSet only inherits ScalarMappable and
>> ContourLabeller, neither of which is an Artist subclass, which means
>> ContourSet is not an Artist. (And is why it does not have a remove()
>> method).  Anyone have any idea why and if we should correct that? I'm
>> not sure what the ramifications would be.
>
> It's just historical.  Should every plotting command return an Artist,
> simple or compound?  If so, I suspect contouring is not the only thing
> that will need refactoring.  I haven't investigated what would be required.

Ryan, was there a particular use case in which you found that CS was
not an Artist to be a limitation, or were you just asking out of
curiosity?

JDH

On 07/09/2010 11:45 AM, Ryan May wrote:
> Hi,
>
> I just noticed that ContourSet only inherits ScalarMappable and
> ContourLabeller, neither of which is an Artist subclass, which means
> ContourSet is not an Artist. (And is why it does not have a remove()
> method).  Anyone have any idea why and if we should correct that? I'm
> not sure what the ramifications would be.

It's just historical.  Should every plotting command return an Artist, 
simple or compound?  If so, I suspect contouring is not the only thing 
that will need refactoring.  I haven't investigated what would be required.

Eric

>
> Ryan
>

On Fri, Jul 9, 2010 at 5:22 PM, Ryan May <rm...@gm...> wrote:

> I've been "hard" at work over the last couple of months putting
> together a set of classes that simplifies the creation of animations
> in matplotlib. This started when I resurrected some old code for

Very nice -- people are going to really like this. I've had several
requests personally to add something like this so thanks for doing it
:-)

Some rapid fire comments, in no particular order

  * on recent ubuntu linux with gtkagg, dynamic_image has a "one
pixel" bug on the right side if blit=True.  I suspect this has nothing
to do with your package and everything to do with gtkagg blitting code
having an off-by-one error somewhere.  I added this to the tracker:
https://sourceforge.net/tracker/?func=detail&aid=3027636&group_id=80706&atid=560720

  * this is completely un-thought out, but could we define a subclass
of TimedAnimation to work like an iterator so users could do the
natural thing :

  line, = ax.plot(something)
  for frame in SomeTimedAnimation(fig, blit=True):
      line.set_data(mydata)
      frame.update()

or something along those lines....

* when you integrate this into trunk, I would like to see widgets.py
upgraded to use it.  This is not a requirement and I would be happy to
help with it, but it is a good way to push on the new API and expand
the test cases.

* I am happy to see this pushed into trunk at any time.  I would not
push it into the branch, but we can do a 1.1 trunk release as soon as
we are ready (release early, release often).  Putting it in the trunk
will facilitate testing and other developer contributions.  But if
you'd rather leave it in github for a while, I have no problem with
that either.

* you hardcode the artist visible state True/False in ArtistAnimation,
which overrides any settings the users may be trying to control. Not
sure if this is a problem, but it's something to think about.  When
you set False in ArtistAnimation._init_draw, should you first store
the current state so you can restore the userland settings?  You
comment that maybe you should be integrating with the "animated"
property.  This is essentially what this is for, if animated is set it
should not be used in drawing the background.   Not sure if this
matters since it may be sensible to assume they are handing you
control of visibility in ArtistAnimation, just throwing it out there.

* in Animation.save, why do you set blit=False?  When making movies,
shouldn't we also depend on the efficiencies of blit?  Or was the
idea: blit is buggy so for production movies turn it off cause I'm
willing to sacrifice performance for quality?
If so, I'd rather try an fix the bugs....or expose blit as a kwarg.

* a tutorial for the site docs would be awesome.  It's one of the big
missing pieces in the docs, so this would be a good time to add it.

* when you include animation.py in the trunk, would you write the examples as

  import matplotlib.animation as animation
  ani = animation.FuncAnimation(fig, ...)

  per the style guidelines in the coding guide.

* let's preserve the old gui specific examples in a subdir of
examples/animation, so people who need bare metal control will still
have examples to follow.  You can add a README in that dir suggesting
the use of the new API unless necessary.

Nice work.

JDH

On Fri, Jul 9, 2010 at 5:22 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> I've been "hard" at work over the last couple of months putting
> together a set of classes that simplifies the creation of animations
> in matplotlib. This started when I resurrected some old code for
> animations to give to a colleague, when I realized just how bad the
> old code was and how much better I could do. The result of this
> "afternoon" hack is what I'm ready to put forth.  Some of the goals:

In my haste to get this out, I forgot to mention that thanks go to Ben
Root for already banging on this quite a bit, giving quite a bit of
useful design feedback and helping me find some bugs.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,

I've been "hard" at work over the last couple of months putting
together a set of classes that simplifies the creation of animations
in matplotlib. This started when I resurrected some old code for
animations to give to a colleague, when I realized just how bad the
old code was and how much better I could do. The result of this
"afternoon" hack is what I'm ready to put forth.  Some of the goals:

* Run independently of the backend, unlike the examples we have now
(This is really accomplished by the Timer object we now have)
* Remove the boilerplate code of setting up loops
* Facilitate saving out animations as a movie file
* Provide a simple API that integrates well with the rest of Matplotlib
* Provide (optional) blitting support so that users don't have to
learn the ins and outs of blitting

Overall, I think I accomplished my goals, so I'm putting this out
there for wider comments. I've attached the python module which, when
run, displays two animated figures. There is also a git repository at:

http://github.com/dopplershift/Animation

which has some more examples, including ports of our old examples.
(The examples assume animation.py is in your python path somewhere,
which you'll have to do by hand. This can be as simple as dropping
animation.py into the directory).

Some things to note:
* The flow is broken into *a lot* of member functions. This is to
provide sufficient entry points for subclasses so that they really
only need to reimplement the parts they override. Optional blitting
support drove a lot of this.
* There are two main classes for end users:
  * FuncAnimation -- provide a callback which draws the next frame of animation
  * ArtistAnimation -- provide a sequence of collections of artists
which are turned off and on for each frame of animation
* There is support for saving movies with either mencoder or ffmpeg.
The config for this is really rough, and the place I could *really*
use suggestions. I'm not sure how best to go about it. I've been
unable to find a (currently maintained) python library for saving
movie files, so system calls to the utilities is the best I can do at
the moment. I'm not sure what to use on windows, since I'm not sure of
the state (and requirements) of mencode/ffmpeg on windows.

TODOs:
* Configuring saving movie files (formats, programs, etc.) (see above)
* Documentation (I promise not to commit until this is written)
* More examples (could use some more procedural examples, like
animating using data read from a socket, or inotify)

I welcome feedback on this, because I really want to see this become
an easy and bulletproof way of doing animations in matplotlib. This
seems to be an area of frequent question on the mailing list, and I
want this framework to lessen the questions, not increase them.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma