matplotlib-users Mailing List for matplotlib

Hello,

Is there a simple argument to pass to matshow so that it'll print 0 as 
white and 1 as black, and not the opposite as it defaults to ?

--
Yann Le Du

Darren,
All of the error handling code was recently reworked by John to make all of 
the front ends be consistent.  So, that line doesn't even exist in the CVS 
repository anymore.  If you sync to the latest CVS then you should be fine.

You can find the instructions for CVS access here: 
http://sourceforge.net/cvs/?group_id=80706

Ted


At 09:06 AM 2/23/2005, Darren Dale wrote:
>On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> >     Darren> backend_qt.py is present in my cvs directory, but it looks
> >     Darren> like it didnt make it into the MPL-0.72 tarball.
> >
> > This was a problem with the MANIFEST file in the 0.72 release.  I
> > should be fixed in the 0.72.1 bugfix release, which is up on the sf
> > site.
>
>Great! One bug to report. Line 262 of backend_qt.py should read:
>
>error_msg = error_msg_qt
>
>or I get an error:
>
>File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py",
>line 262, in ?
>     error_msg = error_msg
>NameError: name 'error_msg' is not defined
>
>--
>
>Darren
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

>>>>> "Greg" == Greg Novak <no...@uc...> writes:

    Greg> This is gripe #1: weak typing only works when using
    Greg> undefined variables bites you on the nose.  Otherwise we're

This is a good point -- Norbert submitted a patch addressing this a
couple of months ago but it broke python2.2 so we unrolled it.  I've
added it to my list of things to do.  It's tricky to get right, but
it's manageable and important.

    Greg> Gripe #2 is that it would be nice if the same word were
    Greg> abbreviated the same way everywhere.  Ie, either cmap or cm,
    Greg> not both.

I don't think I agree with you here.  matplotlib.cm is a *module* and
cm is a convenient reference to that module for pylab interactive
users who want to save on keystrokes.  I think it would lead to
confusion and hard to find bugs if a module name and a kwarg were the
same.  Now cm may not be the best module name, perhaps cmaps would be
better.  I don't see this as a huge problem since a simple 

  >>> pcolor?  

in ipython would have shown you the correct kwarg.  And if mpl had
raised an exception on seeing cm as a kwarg as you suggest in gripe#1,
it wouldn't have been a problem for you.

BTW, do you know you can interactively change the colormap for an
existing plot with the jet, gray, hot, et al commands

  >>> pcolor(rand(12,12))  # use your default colormap
  >>> hot()     # colormap is now hot
  >>> summer()  # colormap is now summer

    Greg> Gripe #3 is related to interactive windows when Python and
    Greg> the X11 server are connected by a slow link.  All of the
    Greg> interactive backends I've used for matplotlib look great,
    Greg> but render very slowly in this situation b/c they're sending
    Greg> all the pixel data.  Since most plots consist of a few
    Greg> lines, a bit of text, and a few dots, it'd be nice if the
    Greg> windows rendered quickly over slow connections.  For
    Greg> example, Gnuplot runs very well in this configuration.  I
    Greg> realize that this doesn't invovle matplotlib per se, I just
    Greg> wanted to throw it out there as a concern.

Perry already addressed this -- basically because we have so many
python GUIs it becomes a maintenance nightmare to add new features if
we use native drawing.  Using agg to render to a bitmap which is then
transferred to a GUI canvas means we can add a feature in one place
and Tk, Wx, GTk, Fltk and QT users automagically get it with *no*
changes to the GUI backend.  It comes with a cost, as you observed.

You do have the option of using a GUI native drawing backend, eg GTK
instead of GTKAgg or WX instead of WXAgg.  Because we use double
buffering in GTK, it may not help (Steve -- would it be possible to
make double buffering optional?)  The native GTK drawing is inferior
to Agg, in my view, but you may be willing to trade quality for
speed.  

There is hope for you, however, that you can have the best of both
worlds.  Steve says that GTK is moving to a Cairo renderer for GTK
2.8, which does provide nice graphics.  And it is a happy confluence
of circumstances that 1) matplotlib has a Cairo backend, 2) the GTK
maintainer (Steve Chaplin) is also the author of the Cairo and
GTKCairo backends and 3) Steve is very good about keeping the GTK*
stuff up to the latest developments in the gtk world.  So in the near
future, we may have a GTK backend that uses native drawing and looks
good too.  In which case you may get speed over an X11 connection as
well as nice looking plots.

    Greg> I apologize for the negative tone of this mail.  Don't get
    Greg> me wrong--I use matplotlib and I like it b/c it's the best
    Greg> thing I've found.  However, I just had one of those
    Greg> "GAAARGHGGHHHH!" moments and it's taking a little while to
    Greg> de-stress.

No problem.  With all the fan mail we're getting around here, we're
starting to get a little soft :-).  Some well placed criticism keeps
us on our toes.

Thanks,
JDH

>>>>> "Greg" == Greg Novak <no...@uc...> writes:

    Greg> Not everyone uses matplotlib inside of scripts!  Judging
    Greg> from the manual, this is the only approved way to use the
    Greg> library.

Hmm.  Not quite true.  I hear there is a fellow in Boulder who
sometimes uses matplotlib interactively <wink>.  If the manual gives a
different impression, that is unintentional, and may result from
selective reading.  Did you read section 1.5 with subheading
"Interactive"?  Eg,

   The recommended way to use matplotlib interactively from a shell is
   with ipython, which has an pylab mode that detects your matplotlib
   .matplotlibrc file and makes the right settings to run matplotlib
   with your GUI of choice in interactive mode using threading.  gtk
   users will need to make sure that they have compiled gtk with
   threading for this to work.  Using ipython in pylab mode is
   basically a nobrainer because it knows enough about matplotlib
   internals to make all the right settings for you internally.

Fernando and I have spent a lot of time and effort to make matplotlib
work seamlessly in interactive use.  The issues are non-trivial
because you have to handle threading to keep the GUI from stealing the
show.  Because threading is always involved when using most GUIs from
a python shell, we also provide an example in examples/interactive.py
which three mpl developers collaborated on to show people the
beginnings of how to roll their own custom interactive GTK shell.

I've also added a lot of short aliases for long keywords so you can
do, for example

 >>> plot([1,2,3], ls='--', c='red')

instead of

 >>> plot([1,2,3], linestyle='--', color='red')

Basically, the claim that we only support a scripting interface is not
true.  If you have specific things to suggest to further improve
interactive use, or documentation suggestions, fire away.

    Greg> There seems to be no way to change the backend in the middle
    Greg> of an interactive session.  Looking through the manual, I
    Greg> find that I can specify it on the command line, in
    Greg> .matplotlibrc, or via matplotlib.use('..'), but only "before
    Greg> you import matplotlib.pylab"

matplotlib development usually happens when a developer needs a
feature or one or more users make a case that a feature is important
-- you are officially the second person to request the ability to
switch backends interactively, if memory serves.

The first person was Fernando Perez, who has driven many of the
improvements in interactive use because he makes lots of suggestions
and contributes code.  Recently on matplotlib-devel, we discussed the
importance of being able to switch backends interactively
http://sourceforge.net/mailarchive/message.php?msg_id=10724264 and I
provided a pylab_interface function switch_backend which does just
that.  As you'll see in that thread, Fernando is looking into ways to
include the backend switching functionality into ipython, eg so you
can run a script with

  >>> run -backend PS somefile.py

But even w/o this ease of use, in the current matplotlib release the
pylab switch_backend function exists.  It's not documented because we
are still exploring and testing it and it is experimental.  But I
added a docstring this morning which I'll paste in here

def switch_backend(newbackend):
    """
    Swtich the default backend to newbackend.  This feature is
    EXPERIMENTAL, and is only expected to work switching to an image
    backend.  Eg, if you have a bunch of PS scripts that you want to
    run from an interactive ipython session, yuo may want to switch to
    the PS backend before running them to avoid having a bunch of GUI
    windows popup.  If you try to interactively switch from one GUI
    backend to another, you will explode.

    Calling this command will close all open windows.
    """


    Greg> I would be extremely happy if there were a way to change
    Greg> backends midstream from an interactive shell (I use ipython,
    Greg> for example)

Good.  You should be extremely happy then.  As I suggested above, this
feature is lightly tested, so let us know what you find.

JDH

On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> backend_qt.py is present in my cvs directory, but it looks
>     Darren> like it didnt make it into the MPL-0.72 tarball.
>
> This was a problem with the MANIFEST file in the 0.72 release.  I
> should be fixed in the 0.72.1 bugfix release, which is up on the sf
> site.

Great! One bug to report. Line 262 of backend_qt.py should read:

error_msg = error_msg_qt

or I get an error:

File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", 
line 262, in ?
    error_msg = error_msg
NameError: name 'error_msg' is not defined

-- 

Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> backend_qt.py is present in my cvs directory, but it looks
    Darren> like it didnt make it into the MPL-0.72 tarball.

This was a problem with the MANIFEST file in the 0.72 release.  I
should be fixed in the 0.72.1 bugfix release, which is up on the sf
site.

JDH

Hi,

I got curious this morning and wanted to try out the QtAgg backend. I get the 
following error when I try to import pylab from a python interpreter:

File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qtagg.py", 
line 12, in ?
    from backend_qt import qt, FigureManagerQT, FigureCanvasQT,\
ImportError: No module named backend_qt

backend_qt.py is present in my cvs directory, but it looks like it didnt make 
it into the MPL-0.72 tarball.

-- 

Darren

On Feb 23, 2005, at 1:28 AM, Greg Novak wrote:
> Gripe #3 is related to interactive windows when Python and the X11
> server are connected by a slow link.  All of the interactive backends
> I've used for matplotlib look great, but render very slowly in this
> situation b/c they're sending all the pixel data.  Since most plots
> consist of a few lines, a bit of text, and a few dots, it'd be nice if
> the windows rendered quickly over slow connections.  For example,
> Gnuplot runs very well in this configuration.  I realize that this
> doesn't invovle matplotlib per se, I just wanted to throw it out there
> as a concern.
>
This is a consequence of how most of the interactive backends are 
implemented. Since matplotlib is using agg to render graphics for them, 
all updates to graphs mean a new image must be transmitted to the 
window. If it is a remote window, that update is going to cost. There 
may be ways of improving the backends so that not the whole window 
needs to be updated, but I have a feeling that isn't going to yield a 
big improvement in many cases (a new plot of points means changes over 
most of the image even if it can be characterized by a relatively small 
number of points and labels). I don't see any great solution to this 
(maybe John has some good ideas). I pointed this out as a consequence 
of going this way before it was done (and I recommended going this way 
:-). Implementing the backends using their built in plotting commands 
may be a way around this, but it means having much higher maintenance 
costs for backends and lots of annoying capability mismatches (some 
backends don't support rotated text, alpha blending, etc.)

Perry

Ok, I was so rattled when I wrote the previous message that I forgot
to ask my actual question:

I was trying to change backends midstream because I was only getting
b/w plots when I used pcolor--I couldn't change the colormap.  At
first I thought that this was because I was using the Postscript
backend and for some reason it assumed I wanted b/w output for
printing.  After fooling around with some of the other imaging
backends, I used one of the interactive ones (this is a pain b/c I'm
running Python remotely and I'm sitting at the end of a slow internet
link.  Therefore interactive windows take forever to pop up.  More on
this later), and the plot was still b/w.

After significant frustration, I realized that my problem was that I
was specifying the color map as 'cm=' instead of 'cmap='; a reasonable
guess since the rest of the line is 'cm.hot'  The problem was that
matplotlib silently ignored my misspecified argument.

This is gripe #1: weak typing only works when using undefined
variables bites you on the nose.  Otherwise we're back to the bad old
days of fortran, when misspelling a variable name silently defined a
new variable.  It would be nice if somewhere in the heirarchy of
function calls within matplotlib someone checked to make sure there
were no lonely, unused keyword arguments sloshing around.  I realize
that this is hard to do robustly and with any generality, but there's
a lot at stake.  Python would be unusable if use-before-definition
didn't generate an exception.

Gripe #2 is that it would be nice if the same word were abbreviated
the same way everywhere.  Ie, either cmap or cm, not both.  

Gripe #3 is related to interactive windows when Python and the X11
server are connected by a slow link.  All of the interactive backends
I've used for matplotlib look great, but render very slowly in this
situation b/c they're sending all the pixel data.  Since most plots
consist of a few lines, a bit of text, and a few dots, it'd be nice if
the windows rendered quickly over slow connections.  For example,
Gnuplot runs very well in this configuration.  I realize that this
doesn't invovle matplotlib per se, I just wanted to throw it out there
as a concern.

I apologize for the negative tone of this mail.  Don't get me wrong--I
use matplotlib and I like it b/c it's the best thing I've found.
However, I just had one of those "GAAARGHGGHHHH!" moments and it's
taking a little while to de-stress.

Cheers,
Greg

Not everyone uses matplotlib inside of scripts!  Judging from the
manual, this is the only approved way to use the library.

There seems to be no way to change the backend in the middle of an
interactive session.  Looking through the manual, I find that I can
specify it on the command line, in .matplotlibrc, or via
matplotlib.use('..'), but only "before you import matplotlib.pylab"

I would be extremely happy if there were a way to change backends
midstream from an interactive shell (I use ipython, for example)

Thanks,
Greg