Hi. Sorry if this was covered already, but I ran into a recent problem with animating an image using GTKAgg (and matplotlib 0.83.2). In my update_fig() function, I do: im.set_data(g) manager.canvas.draw() where g is some arbritrary 20x20 array. Over time it's elements will be set to 1, and then decay exponentially. For the majority of the time the array contains all 0s. Under these conditions, it gets very choppy, and skips a large number of frames. If I do something like: g[0, 0] = 1, then the animation runs smoothly, and looks like it's supposed to (except I now have one cell in the grid set the an incorrect value. 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. Thanks, Abe
Sorry, realized I was a little vague. When I say, 'choppy', I mean that some cells won't get updated. If there is a lot of activity everything looks like, but once activity dies down, some elements stay on in various stages (somewhat like bad pixels). Abraham Schneider wrote: > Hi. Sorry if this was covered already, but I ran into a recent problem > with animating an image using GTKAgg (and matplotlib 0.83.2). In my > update_fig() function, I do: > > im.set_data(g) > manager.canvas.draw() > > where g is some arbritrary 20x20 array. Over time it's elements will > be set to 1, and then decay exponentially. For the majority of the > time the array contains all 0s. Under these conditions, it gets very > choppy, and skips a large number of frames. > > If I do something like: g[0, 0] = 1, then the animation runs smoothly, > and looks like it's supposed to (except I now have one cell in the > grid set the an incorrect value. > > 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. > > Thanks, > > Abe > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes: Abraham> I haven't had time to do a full search yet, but was Abraham> hoping someone might at least have an idea of where to Abraham> begin to look. My current suspicions is that there might Abraham> 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
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
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
On 2005年8月30日, Ken McIvor wrote: [...] > # 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