My situation where I got onto this, is having one field named 'mmm'
("MinMaxMean") being an 3 element array.
Now, to assign the values first I tried:
self.hdrArray = makeHdrArray(self.h) #this makes the record array
self.hdr = self.hdrArray.field #this is my shortcut to the
bound member function
# it essentially is a solution (hack) for the getitem part
# but regarding setitem I had to learn that "assigning to a function" is
illigal in Python - as opposed to C++
#so to do assignment I need to do:
self.hdr('mmm'), self.hdr('mmm'), self.hdr('mmm') = (mi,ma,av)
now that I'm looking at it,
would probably be better...
How about adding an attribute 'f' which could serve as a "proxy" to allow:
myRec.f.mmm = (mi,ma,av)
and maybe even additionally:
myRec.f['mmm'] = (mi,ma,av)
----- Original Message -----
From: "Perry Greenfield" <perry(a)stsci.edu>
To: "Sebastian Haase" <haase(a)msg.ucsf.edu>;
Sent: Thursday, December 04, 2003 3:08 PM
Subject: RE: [Numpy-discussion] numarray.records - get/set item
> > Hi,
> > Is it maybe a good idea to add this to the definition of 'class Record'
> > class Record:
> > """Class for one single row."""
> > <snip>
> > def __getitem__(self, fieldName):
> > return self.array.field(fieldName)[self.row]
> > def __setitem__(self, fieldName, value):
> > self.array.field(fieldName)[self.row] = value
> > I don't know about the implications if __delitem __ and so on are not
> > defined.
> > I just think it would look quite nice to say
> > myRecArr['mmm'] = 'hallo'
> > as opposed to
> > myRecArr.setfield('mmm', 'hallo')
> > Actually I would even like
> > myRecArr.mmm = 'hallo'
> > This should be possible by defining __setattr__.
> > It would obviously only work for fieldnames that do not contain '.' or '
> > or ...
> > Any comments ?
> We've had many internal discussions about doing this. The latter was
> considered a problem because of possible name collisions of field
> names with other attributes or methods. The former is not bothered
> by this problem, but we decided to be conservative on this and see
> how strong the need was. We are interested in other opinions.
What are the policies about tab characters in numarray Python and C
code? What are the policies about indentation in numarray Python and C code?
The following small program found a bunch of tabs in numarray code:
topdir = '/usr/local/src/numarray-0.8/'
for dirpath, dirnames, filenames in os.walk(topdir):
for name in filenames:
fullname = os.path.join(dirpath, name)
lines = file(fullname, 'r').read().splitlines()
for i, line in enumerate(lines):
if '\t' in line:
print fullname[len(topdir):], i+1, line
Sometime after v0.8 setup.py was changed to include some
'classifiers'. Doesn't work for me (python 2.2.2 on FreeBSD):
,----[python setup.py install --home=~/install/freebsd-x86]
| Using EXTRA_COMPILE_ARGS = 
| error in setup script: invalid distribution option 'classifiers'
Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de
Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D
(Part 3 you find in my messages before fall 2003.)
The way LICENSE.txt is included in the __init__ file for numarray breaks
McMillan's installer (and probably py2exe as well, although I haven't
checked that). The offending line is:
__LICENSE__ = open(_os.path.join(__path__,"LICENSE.txt")).read()
The first problem is that the installer doesn't pick up the dependancy
on LICENSE.txt. That's not a huge deal as it's relatively simple to add
that to the list of dependancy's by hand.
More serious is that the __path__ variable is bogus in an installer
archive so that the reading of the license file fails, even if it's present.
One solution is just include the license text directly instead of
reading it from a separate file. This is simple and the license is short
enough that this shouldn't clutter things too much. It's not like
there's all that much in the __init__ file anyway <0.5 wink>.
A second solution is to wrap the above incantation in try, except;
however, this doesn't guarantee that the license file is included.
A third solution is to come up with a different incantation that works
for installer. I've looked at this briefly and it looks a little messy.
Nevertheless, I'll come up with something that works if this is deemed
the preferred solution. Someone else will have to figure out what works
[ If the above makes no sense to those of you unfamilar with McMillan's
installer, I apologize -- ask away and I'll try to clarify]
I am producing and reading 16 bit tiff files using PIL. These files
however can not be displayed by most image processing programs (gimp
From: Peter Verveer [mailto:firstname.lastname@example.org]
Sent: Thu 08-Jan-04 11:41
To: Sebastian Haase; numpy-discussion(a)lists.sourceforge.net
Subject: Re: [Numpy-discussion] Update for IM. a small image processing system
I use the 1.1.4 final version. I do however, have images that are not read by
PIL ('cannot identify image file'). I think these files are okay, since I can
read them in a scientific imaging program. So maybe the 16bit support in PIL
is not complete.
On Wednesday 07 January 2004 20:43, Sebastian Haase wrote:
> > know a good solution for getting 16bit tiffs into numarray?
> Hi Peter,
> When did you try that ? My info is the PIL released within the last few
> month version 1.1.4 which does the job.
> this is from http://effbot.org/zone/pil-changes-114.htm:
> (1.1.4a2 released)
> + Improved support for 16-bit unsigned integer images (mode "I;16").
> This includes TIFF reader support, and support for "getextrema"
> and "point" (from Klamer Shutte).
> (Ooops: PIL 1.1.4 final was released on May 10, 2003. (time flies ...)
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
Numpy-discussion mailing list
I have uploaded a new version of my small image processing system IM to
"http://members.tripod.com/~edcjones/IM-01.01.04.tar.gz". Most of the code
in IM (pronounced "I'm") is inferior to "nd_image" so I will eventually
convert it all to "nd_image".
Some features are:
Wrappers for some useful functions in the numarray API.
Module(arrin), TypeCode(arrin), Width(arrin), Height(arrin),
Bands(arrin), Mode(arrin), NatypeOrMode(arrin), and
Open and Save
Converts between array types and formats. Out of range values are
Some additions to numarray
BlockReduce, MultiReduce, BlockMean, CountNonZero, CountZeros,
Stretch (grey level range), Zoom, Shrink, and Saturate.
Convert an array to a list of (array[i,j], i, j) or a dictionary
with entries d[(i,j)] = array[i,j].
Sliding window operators including MeanX and HaarX which have masking.
Only the unmasked pixels are averaged when finding a mean. For MeanX
and HaarX, a border is added to the image. The pixels in the border
become the masked pixels.
There are many open source image processing systems but most of them get
only to the Canny edge operator and then stop. A sample of the better ones
And then there is the huge and hard to use "Image Understanding Environment"
(IUE) at "http://www.aai.com/AAI/IUE/IUE.html". Has anyone used this?
A good starting point is "The Computer Vision Homepage" at
"http://www-2.cs.cmu.edu/~cil/vision.html". At this site there is a list of
published software. A well-known example is the Kanade-Lucas-Tomasi Feature
Tracker coded by Stan Birchfield at
"http://vision.stanford.edu/~birch/klt/". Thanks. Note how short the
software list is compared with the size of the computer vision lterature.
Why does so little software exists for the more advanced parts of computer
vision? I feel this is mostly because academic researchers seldom publish
their software. In some cases (for example, face recognition software) there
are financial motives. In most cases. I suspect that there is no pressure on
the researchers from journals or department chairmen to publish the
software. So they avoid the work of making their software presentable by not
releasing it. The result are many unreproduced experiments and slow
transitions of new algorithms out of academia.
A good computer vision system
Has an easy to use and widely used scripting language.
Has powerful array processing capabilities.
Wraps a variety of other computer vision systems. The wrapping process
should be straightforward.
SWIG, Pyrex, Psyco, ..., and the Python API.
Provides a uniform interface to its components.
Is used by many people.
> On Wednesday 07 January 2004 07:50, RJS wrote:
> > Most programs I have seen align a selected sub-image, then shift
> > the whole image/array (without rotation, although that would be
> If I understand you well, you essentially want to estimate a shift
> images. I have some code that can do that. I do not intend to include
> nd_image for now, but I can send you the code.
Yes, please. I sure that it's better/faster than my PIL or PythonMagick
efforts. I don't know about machine vision etc, but shift is indispensable
for video astronomy.
> > 2. A fast method(ology) to do weighted sums of 2D arrays with a mask
> > available for each array.
> I think this can be achieved relatively easily with standard numarray
Yes, it is straight-forward, in a way, but I'm always scouring the net for
C and Python algorithms. Very (most?) often they're better than my own.
This app is really a proof-of-concept; hopefully others will incorporate
the "clipped image stacking" into their already fine astro apps.
The problem is that the standard methods - median, mean, or summing - all
suffer when long images in unequal exposure stacks have large clipped regions.