matplotlib-devel Mailing List for matplotlib (Page 3)

>>>>> "Nicholas" == Nicholas Young <N.P...@wa...> writes:
 Nicholas> On Wed, 2005年09月07日 at 16:15 +0100, Nicholas Young wrote:
 >> I've attached a patch to CVS with the necessary changes below.
 >> There are some issues here:
 Nicholas> My patch contained memory leaks which I've fixed in the
 Nicholas> attachment - but I'm not that experienced in c/c++ so
 Nicholas> there could be more I haven't noticed.
 Nicholas> Nick
You might want to test with the following script
import os
def report_memory(i):
 pid = os.getpid()
 a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
 print i, ' ', a2[1],
 return int(a2[1].split()[1])
for i in range(100):
 your_code_here()
 report_memory(i)
You should see little or no leak if everything checks out.
JDH

On Wed, 2005年09月07日 at 16:15 +0100, Nicholas Young wrote:
> I've attached a patch to CVS with the necessary changes below. There
> are some issues here:
My patch contained memory leaks which I've fixed in the attachment - but
I'm not that experienced in c/c++ so there could be more I haven't
noticed.
Nick

Hi,
I've recently come across a need to plot images for which I have
irregular sample points. As far as I can see the way to do this in
current mpl CVS is either pcolor or contourf (which is sometimes much
faster).
I've implemented a third way with a subclass of AxisImage called
NonUniformImage which creates an axes image using a custom extension to
the PyCXX _image module. The NonUniformImage class first turns all data
to a MxNx4 UInt8 on initialisation as a cache. The make_image function
is replaced to call the extension code on each call with the x and y
axes, the RGBA image data, the size of the image to output and the view
limits. This code uses nearest neighbour interpolation to determine the
closest colour and create the output. By putting the heavy calculations
into C++, by avoiding dealing with sample points that aren't rendered
and by only calculating the sample point to pixel map once per call this
code allows easy viewing and scrolling on fairly high resolution data.
On my laptop (1GB memory) 2.56 million points are handled fairly easily
(test script below:
I've attached a patch to CVS with the necessary changes below. There
are some issues here:
- I'm not sure what the axes.Axes function to access this should be
called so I haven't made one.
- I'm not sure how to handle image boundaries; I currently have no
boundaries and just choose the nearest sample point - however far away
that is.
- To cope with large images the original array data is not stored and
thus cmap and norm cannot be changed once set_data has been called.
test code:
---
from pylab import *
from Numeric import NewAxis
from matplotlib.image import NonUniformImage
x = arange(-4, 4, 0.005)
y = arange(-4, 4, 0.005)
print 'Size %d points' % (len(x) * len(y))
z = sqrt(x[NewAxis,:]**2 + y[:,NewAxis]**2)
im = NonUniformImage(gca())
im.set_data(x, y, z)
gca().images.append(im)
show()
x2 = x**3
im = NonUniformImage(gca())
im.set_data(x2, y, z)
gca().images.append(im)
show()
---
Hope this is useful,
Nick

On Saturday 03 September 2005 8:47 pm, Eric Firing wrote:
> John,
>
> In the course of looking at the colorbar patch, I came up with two small
> changes for you to consider:
>
> 1) I added an rc option "tick.direction" which can be "in" (default) or
> "out". With "in", there is no change from present behavior. With
> "out", all ticks are outside the box, and tick labels are shifted
> accordingly. I think outward ticks are particularly appropriate for
> things like filled contours and colorbars; inward ticks tend to be
> obscured.
Thank you for doing this, I had been making the same changes to my colorbars.
Darren

John,
In the course of looking at the colorbar patch, I came up with two small 
changes for you to consider:
1) I added an rc option "tick.direction" which can be "in" (default) or 
"out". With "in", there is no change from present behavior. With 
"out", all ticks are outside the box, and tick labels are shifted 
accordingly. I think outward ticks are particularly appropriate for 
things like filled contours and colorbars; inward ticks tend to be obscured.
2) I shifted the axis drawing to a later stage, so that the axes are 
drawn on top, instead of getting overpainted by contourf.
There are also some cleanups:
1) "class ContourfMappable(ScalarMappable)" was not being used, so I 
deleted it.
2) I deleted a redundant initialization of self.images[] from axes.py.
3) Optionally, stripped out trailing blanks. I will provide two diffs, 
one that ignores blanks, and one that does not, but otherwise the same. 
 I will send you the diffs offline so as not to clutter the list.
Now, regarding the colorbar change committed by Jeff: at present it has 
the minor disadvantage of breaking contourf if the latter is called with 
explicit colors instead of with a colormap. I think I can fix this and 
improve readability by making some changes in contour.py and in the 
colorbar code. That's next.
Eric