matplotlib-devel Mailing List for matplotlib

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