more fun with animation

I haven't had time to do a full search yet, but was

    > hoping someone might at least have an idea of where to
    > begin to look. My current suspicions is that there might
    > be a caching issue.

It could be -- the image module does do some caching. But im.set_data
*does* clear the cache with

        self._imcache =None

I suggest you follow pick through set_data and make_image in the image
module to see if you can sort out what is going wrong. Alternatively,
if you post an example then I can take a look.

JDH

I've done Abraham's work for him this time, and attached an example which demonstrates behavior that he *may* be seeing.

The problem is that the minimum and maximum values of the image are determined every time the image is asked to draw itself (in matplotlib.image.AxesImage.__draw()). I assume that what's happening is that the colors aren't fading down the color ramp as the values decay, but are rather staying constant or blurring a little.

This happens because the color ramp is being applied across the current minimum and maximum of the data, rather than across some absolute scale. The solution to this (see the attached script for the example) is to specify a vmin and vmax, which will pin the top and bottom of the color ramp to those values:

  # assuming z0 is the initial MxN array that is being decayed...
  z_min = min(nx.minimum.reduce(z0))
  z_max = max(nx.maximum.reduce(z0))
  image = axes.imshow(z0, vmin=z_min, vmax=z_max)

As an aside: I'd love to hear if anyone knows of a nicer way to get Numeric to give you the minimum value of a matrix.

Ken

img_wx.py (1.71 KB)

···

On Aug 30, 2005, at 10:29 PM, John Hunter wrote:

I suggest you follow pick through set_data and make_image in the image
module to see if you can sort out what is going wrong. Alternatively,
if you post an example then I can take a look.

Thanks! Great catch. Sadly, I have been bitten by this before, but had completely forgotten about it. I've switched to just doing vmin=0, vmax=1, as I know the range before hand.

Abe

Ken McIvor wrote:

···

On Aug 30, 2005, at 10:29 PM, John Hunter wrote:

I suggest you follow pick through set_data and make_image in the image
module to see if you can sort out what is going wrong. Alternatively,
if you post an example then I can take a look.

I've done Abraham's work for him this time, and attached an example which demonstrates behavior that he *may* be seeing.

The problem is that the minimum and maximum values of the image are determined every time the image is asked to draw itself (in matplotlib.image.AxesImage.__draw()). I assume that what's happening is that the colors aren't fading down the color ramp as the values decay, but are rather staying constant or blurring a little.

This happens because the color ramp is being applied across the current minimum and maximum of the data, rather than across some absolute scale. The solution to this (see the attached script for the example) is to specify a vmin and vmax, which will pin the top and bottom of the color ramp to those values:

    # assuming z0 is the initial MxN array that is being decayed...
    z_min = min(nx.minimum.reduce(z0))
    z_max = max(nx.maximum.reduce(z0))
    image = axes.imshow(z0, vmin=z_min, vmax=z_max)

As an aside: I'd love to hear if anyone knows of a nicer way to get Numeric to give you the minimum value of a matrix.

Ken

[...]

  # assuming z0 is the initial MxN array that is being decayed...
  z_min = min(nx.minimum.reduce(z0))
  z_max = max(nx.maximum.reduce(z0))
  image = axes.imshow(z0, vmin=z_min, vmax=z_max)

As an aside: I'd love to hear if anyone knows of a nicer way to get
Numeric to give you the minimum value of a matrix.

What about:
   z_min=min(ravel(z0))

In [3]:Numeric.ravel?
    ravel(m) returns a 1d array corresponding to all the elements of it's
    argument.

OTOH, I am not sure, if the usage of min (which is a python builtin,
operating on sequences) does not cost some performance.
So maybe

  z_min = nx.minimum.reduce(nx.ravel(z0))

is more efficient?

Best,

Arnd

···

On Tue, 30 Aug 2005, Ken McIvor wrote: