matplotlib-devel Mailing List for matplotlib (Page 465)

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Correction: I did fix the first problem, and the second
    Eric> problem is not at all what I thought.  Instead, the
    Eric> examples/data/lena.jpg file in my svn mpl directory is
    Eric> corrupted.  I have no idea why.  Looking directly at the

This usually happens whenever Andrew commits -- don't know why
(platform dependent new line problem, perhaps?)

peds-pc311:~/mpl> svn log | grep astraw|head
r2480 | astraw | 2006-06-15 06:33:07 -0500 (Thu, 15 Jun 2006) | 1 line
r2430 | astraw | 2006-06-06 15:12:33 -0500 (Tue, 06 Jun 2006) | 1 line
r2279 | astraw | 2006-04-10 10:35:31 -0500 (Mon, 10 Apr 2006) | 3
lines
r2180 | astraw | 2006-03-20 15:38:12 -0600 (Mon, 20 Mar 2006) | 1 line



JDH

Eric Firing wrote:
> Andrew Straw wrote:
> 
> 
>>Actually, this has been in MPL for a while. For example, see the
>>image_demo3.py example. You don't need the __array_interface__ for this
>>bit of functionality.
> 
> 
> It's broken.
> 
> The first problem is that the kw "aspect = 'preserve'" is no longer 
> needed or supported.  Removing that (as I will do in svn shortly), I get 
> a somewhat scrambled image.

Correction: I did fix the first problem, and the second problem is not 
at all what I thought.  Instead, the examples/data/lena.jpg file in my 
svn mpl directory is corrupted.  I have no idea why.  Looking directly 
at the version on svn via the svn browser, I see that it is corrupted also.

Eric

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> Last I checked if I recall correctly, about a year ago, the
    John> PS backend merely dumped a raster image and didn't do real
    John> vector graphics.  Has this changed?

Looks like it has:

  http://lwn.net/Articles/189905

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
    Christopher> Just as a note, if you have Cairo, you have PS, PDF,
    Christopher> SVG, raster, and, indeed, native draw-to-the-screen
    Christopher> functionality.

Last I checked if I recall correctly, about a year ago, the PS backend
merely dumped a raster image and didn't do real vector graphics.  Has
this changed?

JDH

John Hunter wrote:
> I've talked with Eric Jones many times about the desirability
> of sharing a single low-level drawing model, probably based on
> PDF/KIVA, that have backends for PS, SVG, PDF and one raster format
> (eg Agg or Cairo). 

Just as a note, if you have Cairo, you have PS, PDF, SVG, raster, and, 
indeed, native draw-to-the-screen functionality.

They're not all robust and complete, but it's seeing a lot of 
development. A robust, numpy-aware PyCairo would be really nice.

In short, Cairo has essentially the same goals (plus a few more) as 
Kiva, except it's written in C. There's some discussion of using it in 
wxWidgets, and, of course, it's already used in newer GTKs.

-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

Chr...@no...

Yes, this has been fixed.

Mark Bakker wrote:
> Sorry to bother you again, but I recently upgraded from 0.87.2 to 
> 0.87.3, and
> cannot save eps files anymore. I get a 'subprocess' error.
> I am running Python 2.3, mpl 0.87.3, and TkAgg (although that 
> shouldn't matter).
> Error occurs whether using toolbar or savefig to save.
> Here's the script and the errror. Has this been fixed in svn?
>
> >>> from pylab import *
> >>> plot([1,2,3])
> [<matplotlib.lines.Line2D instance at 0x01B50418>]
> >>> savefig('c:/temp/test.eps')
> Traceback (most recent call last):
>   File "<pyshell#2>", line 1, in ?
>     savefig('c:/temp/test.eps')
>   File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 811, 
> in savefig
>     return fig.savefig(*args, **kwargs)
>   File "C:\Python23\Lib\site-packages\matplotlib\figure.py", line 660, 
> in savefig
>     self.canvas.print_figure(*args, **kwargs)
>   File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
> line 184, in print_figure
>     agg.print_figure(filename, dpi, facecolor, edgecolor, orientation,
>   File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py", 
> line 481, in print_figure
>     from backend_ps import FigureCanvasPS # lazy import
>   File 
> "C:\Python23\Lib\site-packages\matplotlib\backends\backend_ps.py", 
> line 10, in ?
>     from subprocess import Popen, STDOUT, PIPE
> ImportError: No module named subprocess
> ------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

Sorry to bother you again, but I recently upgraded from 0.87.2 to 0.87.3,
and
cannot save eps files anymore. I get a 'subprocess' error.
I am running Python 2.3, mpl 0.87.3, and TkAgg (although that shouldn't
matter).
Error occurs whether using toolbar or savefig to save.
Here's the script and the errror. Has this been fixed in svn?

>>> from pylab import *
>>> plot([1,2,3])
[<matplotlib.lines.Line2D instance at 0x01B50418>]
>>> savefig('c:/temp/test.eps')
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in ?
    savefig('c:/temp/test.eps')
  File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 811, in
savefig
    return fig.savefig(*args, **kwargs)
  File "C:\Python23\Lib\site-packages\matplotlib\figure.py", line 660, in
savefig
    self.canvas.print_figure(*args, **kwargs)
  File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py",
line 184, in print_figure
    agg.print_figure(filename, dpi, facecolor, edgecolor, orientation,
  File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_agg.py",
line 481, in print_figure
    from backend_ps import FigureCanvasPS # lazy import
  File "C:\Python23\Lib\site-packages\matplotlib\backends\backend_ps.py",
line 10, in ?
    from subprocess import Popen, STDOUT, PIPE
ImportError: No module named subprocess

>>>>> "Robert" == Robert Hetland <rhe...@ma...> writes:

    Robert> I'm not suggesting immediate development for a PDF backend
    Robert> (although if it came automatically with kiva, I would use
    Robert> it), I think eps +ghostscript is good enough for now.

As you may know, we have a prototype of a PDF backend, though it is
missing many features.

JDH

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:

    Mark> The weird thing is that this used to work fine in the past.
    Mark> At least, I am pretty sure it did.  Then again, I am
    Mark> watching the Worlcup final at this time.  So a significant
    Mark> part of my brain is doing something else, Mark

At some point, we upgraded our tk filesave dialog to use the more
modern one.  We could always revert to the old one, which would
likely fix this but let's give it a day and see if we can't have the
best of both worlds.  Hopefully, the effbot will pick up on my c.l.py
post...

JDH

The weird thing is that this used to work fine in the past.
At least, I am pretty sure it did.
Then again, I am watching the Worlcup final at this time.
So a significant part of my brain is doing something else,
Mark

On 7/9/06, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
>     Mark> John was asking whether there was something left to be fixed
>     Mark> befor 0.88.  In 0.87.3, there is still a bug left that has
>     Mark> been reported several times I think.
>
> Interesting.  the tk ask file dialog seems to be triggering a destgroy
> event on the main window, which removes it from mpl figure
> management.  Here is a minimal Tk script which exposes the problem.
> When you press the mouse button, you get a file dialog that when you
> close it triggers a destroy event and calls the callback function
>
> I don't know if this is a tk bug or if we are misusing the Tk code.
> Tk experts?
>
>
> I'll post on python-list.
>
> JDH
>
> import Tkinter as Tk
> from tkFileDialog import asksaveasfilename
>
> def button(event):
>     fname = asksaveasfilename(
>         title='Save the figure'
>         )
>
>
>
>
> window = Tk.Tk()
> frame = Tk.Frame(window, width=500,height=500)
> frame.bind('<Button-1>', button)
> frame.pack()
>
>
> def callback(*args):
>     print 'called callback'
> window.bind("<Destroy>", callback)
>
> window.mainloop()
>
>
>

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:

    Mark> John was asking whether there was something left to be fixed
    Mark> befor 0.88.  In 0.87.3, there is still a bug left that has
    Mark> been reported several times I think.

Interesting.  the tk ask file dialog seems to be triggering a destgroy
event on the main window, which removes it from mpl figure
management.  Here is a minimal Tk script which exposes the problem.
When you press the mouse button, you get a file dialog that when you
close it triggers a destroy event and calls the callback function

I don't know if this is a tk bug or if we are misusing the Tk code.
Tk experts?


I'll post on python-list.

JDH

import Tkinter as Tk
from tkFileDialog import asksaveasfilename

def button(event):
    fname = asksaveasfilename(
        title='Save the figure'
        )


            

window = Tk.Tk()
frame = Tk.Frame(window, width=500,height=500)
frame.bind('<Button-1>', button)
frame.pack()


def callback(*args):
    print 'called callback'
window.bind("<Destroy>", callback)

window.mainloop()

On 7/9/06, Mark Bakker <ma...@gm...> wrote:
> John was asking whether there was something left to be fixed befor 0.88.
> In 0.87.3, there is still a bug left that has been reported several times I
> think.
>
> In interactive mode on TkAgg, after solving by clicking on the 'save' button
> in toolbar2,
> mpl loses its knowledge of the figure. Any plotting statement given after
> that
> creates a new figure, rather than add to the existing one. I wish I knew how
> to fix this.
> I am (still, but not much longer) running Python 2.3, but I think Fernando
> reported
> the bug in Python 2.4 as well.

Confirmed: bug is still there, with current SVN mpl under python2.4.

Cheers,

f

John was asking whether there was something left to be fixed befor 0.88.
In 0.87.3, there is still a bug left that has been reported several times I
think.

In interactive mode on TkAgg, after solving by clicking on the 'save' button
in toolbar2,
mpl loses its knowledge of the figure. Any plotting statement given after
that
creates a new figure, rather than add to the existing one. I wish I knew how
to fix this.
I am (still, but not much longer) running Python 2.3, but I think Fernando
reported
the bug in Python 2.4 as well.

Thanks,

Mark

On Saturday 08 July 2006 10:28 am, Darren Dale wrote:
> On Friday 07 July 2006 6:45 pm, Fernando Perez wrote:
> > On 7/7/06, Jeff Whitaker <js...@fa...> wrote:
> > > John:  setupext.py in svn 2545 uses numpy.get_include(), which
> > > apparently is not available in 0.9.8.  In 0.9.8, it's
> > > get_numpy_include().
> >
> > And in current numpy, get_numpy_include fires a deprecation warning (I
> > just fixed this in my code).  Such are the joys of living on the
> > bleeding edge :)
>
> Sorry, I was the one who changed get_numpy_include to get_include. I guess
> I was thinking that anyone who is using svn mpl would also be using svn
> numpy. Should I change it back to get_numpy_include?

This is fixed in svn. I wrapped get_include in a try statement for the time 
being, get_numpy_include gets called in the event of an attribute error.

Darren

On Friday 07 July 2006 6:45 pm, Fernando Perez wrote:
> On 7/7/06, Jeff Whitaker <js...@fa...> wrote:
> > John:  setupext.py in svn 2545 uses numpy.get_include(), which
> > apparently is not available in 0.9.8.  In 0.9.8, it's
> > get_numpy_include().
>
> And in current numpy, get_numpy_include fires a deprecation warning (I
> just fixed this in my code).  Such are the joys of living on the
> bleeding edge :)


Sorry, I was the one who changed get_numpy_include to get_include. I guess I 
was thinking that anyone who is using svn mpl would also be using svn numpy. 
Should I change it back to get_numpy_include?

On 7/8/06, Travis Oliphant <oli...@ie...> wrote:
> Fernando Perez wrote:
> > Hi all,
> >
> > I was trying to track down a problem with current numpy/scipy from
> > svn, and realized that mpl doesn't build anymore:
> >
> >
> Get the latest SVN of matplotlib.   I fixed it there to use
> numpy/oldnumeric.h
>
> It compiles and runs for me.

Mmh, odd.  I must have caught things again in-between updates, because
I /was/ using SVN mpl for the test at the moment.

Thanks for the info, I'll update again.

Cheers,

f

Hi all,

I was trying to track down a problem with current numpy/scipy from
svn, and realized that mpl doesn't build anymore:

...

compile options:
'-I/home/fperez/tmp/local/lib/python2.4/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -I/usr/include/python2.4 -c'
extra options: '-DSCIPY=1'
gcc: src/_ns_cntr.c
src/_ns_cntr.c: In function 'build_cntr_list_v2':
src/_ns_cntr.c:1376: warning: unused variable 'point'
src/_ns_cntr.c: In function 'Cntr_init':
src/_ns_cntr.c:1617: error: 'PyArray_SBYTE' undeclared (first use in
this function)
src/_ns_cntr.c:1617: error: (Each undeclared identifier is reported only once
src/_ns_cntr.c:1617: error: for each function it appears in.)
src/_ns_cntr.c: In function 'build_cntr_list_v2':
src/_ns_cntr.c:1376: warning: unused variable 'point'
src/_ns_cntr.c: In function 'Cntr_init':
src/_ns_cntr.c:1617: error: 'PyArray_SBYTE' undeclared (first use in
this function)
src/_ns_cntr.c:1617: error: (Each undeclared identifier is reported only once
src/_ns_cntr.c:1617: error: for each function it appears in.)
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -fPIC
-I/home/fperez/tmp/local/lib/python2.4/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -I/usr/include/python2.4 -c
src/_ns_cntr.c -o build/temp.linux-i686-2.4/src/_ns_cntr.o -DSCIPY=1"
failed with exit status 1


There have been changes to the C API in numpy which are probably
causing this (See Travis' recent messages on that list).

Cheers,

f

On 7/7/06, Jeff Whitaker <js...@fa...> wrote:

> John:  setupext.py in svn 2545 uses numpy.get_include(), which
> apparently is not available in 0.9.8.  In 0.9.8, it's get_numpy_include().

And in current numpy, get_numpy_include fires a deprecation warning (I
just fixed this in my code).  Such are the joys of living on the
bleeding edge :)

Cheers,

f

John Hunter wrote:
> We'd like to do a bugfix release for the next release of enthought
> python, which will include the latest mpl.  Apparently, there is a
> problem with 0.87.3 and numpy which has been fixed in svn.
>
> If there is anything we should wait on, let us know, otherwise we'll
> probably try to roll out 0.87.4 early next week.
>
> Thanks,
> JDH
>
>   

John:  setupext.py in svn 2545 uses numpy.get_include(), which 
apparently is not available in 0.9.8.  In 0.9.8, it's get_numpy_include().

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Jul 7, 2006, at 5:16 PM, John Hunter wrote:

> PDF is certainly an important document format, but it doesn't seem to
> be widely used for figures.

I only use PDF figures.  They are useful both in pdflatex (how I  
write), and play nice with all of the other mac utilities, in  
particular Keynote (how I present).  They are generally small, and  
good looking at any size because of the vector graphics.

When converting MPL figures to pdf I usually just export to eps, then  
convert using ghostscript.  In fact, if you open an eps file, OS X  
will do the conversion automagically, and open your new pdf in  
Preview.  For publication quality (with annotations, etc), I export  
to eps, edit in Illustrator, and eventually export to pdf.

I'm not suggesting immediate development for a PDF backend (although  
if it came automatically with kiva, I would use it), I think eps 
+ghostscript is good enough for now.  However, general pdf support is  
an important issue for me.

-Rob

On Friday 07 July 2006 17:16, John Hunter wrote:
> >>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:
>
>     Ga=EBl> On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
>     >> Ideally, I would like to see PS, SVG, Agg and
>     >> [Tk|GTK|WX|Qt|FLTK]Agg and no more.  But I know that other
>     >> people feel differently.
>
>     Ga=EBl>     pdf seems very important to me.
>
> PDF is certainly an important document format, but it doesn't seem to
> be widely used for figures.  I often make pdf documents but
> incorporate PNG figures into them (eg PDF latex).

I would prefer to use pdf figures in my latex documents. They are smaller,=
=20
they support alpha blending, and unlike png they are scalable. Unfortunatel=
y,=20
most academic journals still request postscript files, but this may change=
=20
some day. Printers may eventually use pdf as their native format instead of=
=20
postscript.

Not that I am advocating adding more backends to mpl, just more=20
contributors. :)

On 7/7/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:
>
>     Ga=EBl> On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
>     >> Ideally, I would like to see PS, SVG, Agg and
>     >> [Tk|GTK|WX|Qt|FLTK]Agg and no more.  But I know that other
>     >> people feel differently.
>
>     Ga=EBl>     pdf seems very important to me.
>
> PDF is certainly an important document format, but it doesn't seem to
> be widely used for figures.  I often make pdf documents but
> incorporate PNG figures into them (eg PDF latex).  My backend list
> above is not a list of backends that I think matplotlib should support
> as much as it is a list of backends that I personally find useful and
> would personally support even if noone else did.  Any backend that is
> supported by someone should remain in, even if they are the only one
> using it, in my opinion.  But most backends are not supported.
>
> Only PS and Agg (and by extension all of the GTK* backends) support
> all of matplotlib's features.  This should give some indication of how
> much work it is to develop a fully compliant backend, and why we have
> an incentive to minimize the number of them.

PDF has one important combination that neither PS nor png provide:
vector (hence, resolution independent) images with proper
transparency.  I know SVG has that, but I don't know how well SVGs
embed in PDFs (last I tried, I couldn't make it work satisfactorily).

Cheers,

f

>>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:

    Ga=EBl> On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
    >> Ideally, I would like to see PS, SVG, Agg and
    >> [Tk|GTK|WX|Qt|FLTK]Agg and no more.  But I know that other
    >> people feel differently.

    Ga=EBl>     pdf seems very important to me.

PDF is certainly an important document format, but it doesn't seem to
be widely used for figures.  I often make pdf documents but
incorporate PNG figures into them (eg PDF latex).  My backend list
above is not a list of backends that I think matplotlib should support
as much as it is a list of backends that I personally find useful and
would personally support even if noone else did.  Any backend that is
supported by someone should remain in, even if they are the only one
using it, in my opinion.  But most backends are not supported.

Only PS and Agg (and by extension all of the GTK* backends) support
all of matplotlib's features.  This should give some indication of how
much work it is to develop a fully compliant backend, and why we have
an incentive to minimize the number of them.

JDH=20

On Fri, Jul 07, 2006 at 03:46:01PM -0500, John Hunter wrote:
> Ideally, I would like to see PS, SVG, Agg and [Tk|GTK|WX|Qt|FLTK]Agg
> and no more.  But I know that other people feel differently.

    pdf seems very important to me.

	Just my two cents,

    Ga=EBl

    This question triggers another one from myself (that was raised by
colleagues).

    I know that there is some traits lying in mpl. Will there be one day
some traitsUI code too, to generate GUI to modify properties of objects
one the display ? This is fully related to backends.
    I find that this is one of the most requested features for mpl by my
colleagues (mind you, not by myself).

        Ga=EBl