You change makes a lot of sense to me. What doesn't make a lot of sense is the current behaviour of allowing pyplot.set_cmap to change the colormap of the last added image (why not other artists?). We have methods to do this (plt.gci().set_cmap(cmap) from the top of my head) and removing the image cmap changing functionality from plt.set_cmap would make the whole issue more intuitive. Of course, this would break backwards compatibility of anyone relying on this behaviour. Anyone else have a view on this?

Not to justify the current behavior, but I think it comes from matlab:

http://www.mathworks.com/help/techdoc/ref/colormap.html

It's not very clear from the description, but it is clear from the examples further down that that is how it's intended to work.

I don't think we can change this without breaking backward compatibility, as you say. It is strange how it sort of works "retroactively" like that.

Maybe we could add a kwarg "update_current_image" (or something shorter) that defaults to True? Ok, that's not a great idea, either, but it's the best I can think of right now...

Not to justify the current behavior, but I think it comes from matlab

Playing devil's advocate, I guess the question then is whether pyplot is a "warts and all" reflection of matlab's core api :-)
From a personal stance, I'm not really worried by this as I don't tend to want to set a global palette, but I can see that it could be very confusing to a user.

No -- there's lots of places where matplotlib has chosen to deviate from matlab's API -- I was just giving some history.

The problem is that it's worked this way for so long, it's bound to break people's scripts. We can deprecate for a release, and then fix this in a subsequent release, however.

This pull request looks good; the discussion relates to a possible future pull request.

Hi, sorry I am having the same issue if I do:

import pylab as pl

im = pl.imshow(pl.rand(100,100))
im.set_cmap("gray")

nothing happens.

However if I change the colormap with

pl.set_cmap("gray")

then the colors are changed as intended.

The reason is that pl.set_cmap is defined in pyplot.py but im.set_cmap uses set_cmap defined in matplotlib/cm.py,
so opposite to my intuition they are two different functions.

Now I am new to matplotlib, but the behaviour seem broken to me.

Is this really an issue to be reopened, or am I doing something wrong? Thanks for the help!

Luca

Luca,
What you observe is consistent with matplotlib as a whole; automatic redrawing occurs only when changes are made via a pyplot function, not via a method. The pyplot functions are thin method wrappers that include a draw_if_interactive() call. In the case of the example you give, you can follow your call to im.set_cmap('gray') with pl.draw() to force the image to be redrawn with the new color map.

Thanks Eric ( @efiring ),
sorry if I got it wrong.

In the tutorial however (http://matplotlib.org/users/image_tutorial.html)
it is a bit confusing, because it says:

Now, with a luminosity image, the default colormap (aka lookup table, LUT), is applied. 
The default is called jet.     There are plenty of others to choose from. 
Let’s set some others using the set_cmap() method on our image plot        object:

In [8]: imgplot.set_cmap('hot')

And the image is shown with a different colormap, without mentioning the call to pylab.draw()
Maybe some explanation there could be helpful, especially for beginners (like me)

Just out of curiosity is there a way to have the draw() performed automatically when some property is modified?

Thanks again for the help, and sorry if I opened an issue when not needed.

Cheers,
Luca

Just out of curiosity is there a way to have the draw() performed automatically when some property is modified?

Sadly not. The methods are not wired up that way (they can't know about the pyplot module without causing some nasty circularity). For example, compare the axes.plot method vs the pyplot.plot function (https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes/_axes.py#L1334 vs https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/pyplot.py#L2995). You will see that the method call just adds the appropriate Artist objects (the lines etc that get drawn) whereas the pyplot function does this + triggers a re-draw if necessary.

In the tutorial however it is a bit confusing, because it says:

Interesting. You are right. The reason this works is that the tutorial is written in the perspective of an IPython user, which will plot the last object in the prompt (I think - I've not actually tested that).

Thanks again for the help, and sorry if I opened an issue when not needed.

No worries.

Hi Phil,
thanks for the explanation, I will try to delve deeply in the documentation
to understand better the details.

As of the tutorial: I have run the code in the tutorial using Ipython 1.1.0
(run with the --pylab option) and unfortunately it doesn't work as well.

Thanks again for the help and explanations,
they have been really useful.

Cheers,
Luca

On 24 September 2013 08:41, Phil Elson notifications@github.com wrote:

Just out of curiosity is there a way to have the draw() performed
automatically when some property is modified?

Sadly not. The methods are not wired up that way (they can't know about
the pyplot module without causing some nasty circularity). For example,
compare the axes.plot method vs the pyplot.plot function (
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes/_axes.py#L1334vs
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/pyplot.py#L2995).
You will see that the method call just adds the appropriate Artist objects
(the lines etc that get drawn) whereas the pyplot function does this +
triggers a re-draw if necessary.

In the tutorial however it is a bit confusing, because it says:

Interesting. You are right. The reason this works is that the tutorial is
written in the perspective of an IPython user, which will plot the last
object in the prompt (I think - I've not actually tested that).

Thanks again for the help, and sorry if I opened an issue when not needed.

No worries.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/896#issuecomment-24980499
.

Luca Cerone

Tel: +447585611951
Skype: luca.cerone