matplotlib-users

[Matplotlib-users] new embedding_in_wx3 example

[Andrew S. <str...@as...>]

Hi All,

I've added a new example, embedding_in_wx3, to CVS.  From the docstring:

> This is yet another example of using matplotlib with wx.  Hopefully
> this is pretty full-featured:
>
>   - both matplotlib toolbar and WX buttons manipulate plot
>   - full wxApp framework, including widget interaction
>   - XRC (XML wxWidgets resource) file to create GUI (made with XRCed)
>
> This was derived from embedding_in_wx and dynamic_image_wxagg.
>
> Thanks to matplotlib and wx teams for creating such great software!


John+Perry+whoever: the only matplotlib bug I found this time is worked 
around by the line

> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar problem -ADS

We should fix that at some point.

Cheers!
Andrew

Re: [Matplotlib-users] new embedding_in_wx3 example

[John H. <jdh...@ac...>]

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> Hi All, I've added a new example, embedding_in_wx3, to
    Andrew> CVS.  From the docstring:

Coincidentally, I was also working on a different embedding_in_wx3
which shows how to use a custom toolbar, in response to another
question off list.  I changed the name submitted that as
embedding_in_wx4 :-)

    Andrew> John+Perry+whoever: the only matplotlib bug I found this
    Andrew> time is worked around by the line

    >> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar
    >> problem -ADS

    Andrew> We should fix that at some point.

What was the bug?  I didn't notice any problems with lower.

BTW, the recommended way to set rc params in now with the rc command.
This was initially defined in matplotlib.matlab but I just moved it to
matplotlib.__init__.py to make it accessible to application
developers.  You can do

  matplotlib.rc('image', origin='lower')

and set multiple image params with multiple kwargs.

        self.toolbar.update() # Not sure why this is needed - ADS

This updates the Axes menu on the toolbar, which is needed if the
number of axes have changed.  Since the number of axes/subplots can
change after the figure/toolbar was created, this tells the toolbar to
update it's axes menu.

Another comment: try not to use x.resize in matplotlib examples,
because of the Numeric bug (did you get the emails Todd and I
exchanged regarding this?).  Numeric segfaulted for me when I
initially ran your example with the .resize command.

Note that matplotlib.mlab has the meshgrid command for building mesh
arrays from 2 1D vectors.  I replaced your code with

        x = numerix.arange(120.0)*2*numerix.pi/60.0
        y = numerix.arange(100.0)*2*numerix.pi/50.0
        self.x, self.y = meshgrid(x, y)
        z = numerix.sin(self.x) + numerix.cos(self.y)


Finally, there seems to be a figure size problem on linux: when I run
your example the figure window is too small and the image wraps.

Updates are in CVS - thanks for the submission.

JDH

Re: [Matplotlib-users] new embedding_in_wx3 example

[Andrew S. <as...@ca...>]

John Hunter wrote:

>    Andrew> John+Perry+whoever: the only matplotlib bug I found this
>    Andrew> time is worked around by the line
>
>    >> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar
>    >> problem -ADS
>
>    Andrew> We should fix that at some point.
>
>What was the bug?  I didn't notice any problems with lower.
>  
>
Try vertically zooming and panning with the matplotlib toolbar -- you'll 
see that the overlay points move opposite from the data.  Maybe it's my 
head that's on wrong, though. :)

>Updates are in CVS - thanks for the submission.
>  
>

Thanks for the suggestions.  You'll make a respectable (matplotlib) 
programmer out of me yet!

Cheers!
Andrew

Re: [Matplotlib-users] new embedding_in_wx3 example

[Andrew S. <str...@as...>]

John Hunter wrote:

>
>    Andrew> John+Perry+whoever: the only matplotlib bug I found this
>    Andrew> time is worked around by the line
>
>    >> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar
>    >> problem -ADS
>
>    Andrew> We should fix that at some point.
>
>What was the bug?  I didn't notice any problems with lower.
>  
>
OK, I discovered a rather easy demonstration of what looks to be a 
(possibly the same) bug (adding 'ylim' to the image_origin demo):

from matplotlib.matlab import *

x = arange(100.0); x.shape = 10,10


subplot(211)
title('blue should be up')
imshow(x, origin='upper', interpolation='nearest')
set(gca(),'ylim',(0,23))

subplot(212)
title('blue should be down')
imshow(x, origin='lower', interpolation='nearest')
set(gca(),'ylim',(0,23))

#savefig('image_origin2')
show()

Re: [Matplotlib-users] new embedding_in_wx3 example

[John H. <jdh...@ac...>]

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

  Andrew> OK, I discovered a rather easy demonstration of what looks
  Andrew> to be a OK, (possibly the same) bug (adding 'ylim' to the
  Andrew> image_origin demo):

    from matplotlib.matlab import *
    x = arange(100.0); x.shape = 10,10

    subplot(211)
    title('blue should be up')
    imshow(x, origin='upper', interpolation='nearest')
    set(gca(),'ylim',(0,23))

    subplot(212)
    title('blue should be down')
    imshow(x, origin='lower', interpolation='nearest')
    set(gca(),'ylim',(0,23))

    #savefig('image_origin2')
    show()

I agree it looks like a bug.  Just to make sure we are on the same
page: what do you thing the correct behavior should be here?  Do you
think subplot (211) is correct?  

The question is: how should image origin interact with the axes
ylimits?  In this example, should both images fill the space from 0-10
on the y axes, regardless of the ylimit setting?  In the origin upper
case, should the blue strip be at 10 and the red strip at zero?  In
the origin lower case, should the blue be at zero and the red at 10?

Inquiring minds want to know.

Thanks,
JDH