Update for IM. a small image processing system
IM 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. NA_GetType NA_TypeName NA_GetTypeFromTypeno NA_TypenoFromType SafeCastCheck Standardized parameters Module(arrin), TypeCode(arrin), Width(arrin), Height(arrin), Bands(arrin), Mode(arrin), NatypeOrMode(arrin), and BytesPerItem(arrin) Open and Save ArrayToArrayCast Converts between array types and formats. Out of range values are clipped. 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. THOUGHTS 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 are: ImageMagick http://www.imagemagick.org/ OpenCV http://www.intel.com/research/mrl/research/opencv/ Xite http://www.ifi.uio.no/forskning/grupper/dsb/Software/Xite/ VXL http://vxl.sourceforge.net/ Gandalf http://sourceforge.net/projects/gandalf-library/ imgSeek http://imgseek.sourceforge.net/ 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. Python Has powerful array processing capabilities. numarray, nd_image 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 Saturday 03 January 2004 03:11, Edward C. Jones wrote:
IM
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".
I had a look and I guess that indeed you could use the nd_image package for some low level stuff (I am the author of nd_image). nd_image is however also still being developed and I am looking for directions to further work on. I wondered if there is anything you would like to see in there?
THOUGHTS
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 are:
ImageMagick http://www.imagemagick.org/ OpenCV http://www.intel.com/research/mrl/research/opencv/ Xite http://www.ifi.uio.no/forskning/grupper/dsb/Software/Xite/ VXL http://vxl.sourceforge.net/ Gandalf http://sourceforge.net/projects/gandalf-library/ imgSeek http://imgseek.sourceforge.net/
I think not all of these are general image processing systems and often a bit limited. One problem that I have with most of these packages is that they stop at processing 8bit or 16bit two-dimensional images. That is a limit for quite a lot of image analysis research, for instance medical imaging. That is why numarray is so great, it supports multi-dimensional arrays of arbritrary type. nd_image is designed to support multiple dimensions and any data type. That is not always easy and may prevent some optimizations, but I think it is an important feature. That idea is of course not new, matlab is starting to support multi-dimensional image routines and I am aware of at least one C library that does this, although it is not free software: http://www.ph.tn.tudelft.nl/DIPlib/
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?
The website appears to updated last in 1999, which is not encouraging. Looks hideously complex too.
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.
This is certainly true. I know from experience that often you simply cannot afford to design and maintain a software package after you came up with something new and published it. So a lot of things never leave the laboratory simply because it is hard to do properly. I hope that having a system around like numarray with packages will help.
A good computer vision system Has an easy to use and widely used scripting language. Python Has powerful array processing capabilities. numarray, nd_image 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.
I intend to develop nd_image further as a basic component for multidimensional image analysis. It would be great if it would get picked up to be part of a system like to propose. Maybe in the future SciPy could play that role. What I would like to hear from people that use this type of software is what kind of basic operations you would like to see become part of nd_image. That will help me to further develop the package. Contributed code is obviously also welcome. Peter -- Dr. Peter J. Verveer Cell Biology and Cell Biophysics Programme European Molecular Biology Laboratory Meyerhofstrasse 1 D-69117 Heidelberg Germany Tel. : +49 6221 387245 Fax : +49 6221 387306
Peter Verveer wrote:
On Saturday 03 January 2004 03:11, Edward C. Jones wrote:
IM
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".
I had a look and I guess that indeed you could use the nd_image package for some low level stuff (I am the author of nd_image). nd_image is however also still being developed and I am looking for directions to further work on. I wondered if there is anything you would like to see in there?
Thanks for your response. I have put a slightly revised version of IM on my web page "http://members.tripod.com/~edcjones/". The new version includes functions, written in C, for slicing arrays. A cople of things I would like to see: The ability to read and write a variety of image formats. ImageMagick has a good set. All of ImageMagick should be wrapped. The Canny edge operator along with code for generating polygonal approximations to edges. See OpenCV. Do you have some examples of algorithms for multi-dimensional images that you think should be put in nd_image? Thanks, Ed Jones
Hi Ed,
A cople of things I would like to see:
The ability to read and write a variety of image formats.
That is of course important. But in my view really a separate issue from developing a library of analysis routines. The latter just have to operate on numarray arrays and need not to worry about how the data gets there. Of course you need to get your data in numarray. PIL seems to do a good job with images, except for 16bit tiffs which causes me quiet some problems. Anybody know a good solution for getting 16bit tiffs into numarray?
ImageMagick has a good set. All of ImageMagick should be wrapped.
Isn't there already a python interface to ImageMagick?
The Canny edge operator along with code for generating polygonal approximations to edges. See OpenCV.
Canny I will likely implement at some point. Polygonal approximations to edges can be done in many ways I guess. I would need to find some reasonable method in the literature to do that. Suggestions are welcome.
Do you have some examples of algorithms for multi-dimensional images that you think should be put in nd_image?
At the moment I have only been looking at general basic image processing operations which normally generalize well to multiple dimensions. I will continue to do that. There are also somewhat higher level operations that I currently have not included. For instance, I implemented a sub-pixel shift estimator which I need for my work. That would be an example of a routine that is completely written in python using numarray and nd_image routines and does not need any C. This could be useful for others, but I am not sure if it belongs in a low-level library. Maybe we need some repository for that sort of python applications. Cheers, Peter
Hi Ed,
A cople of things I would like to see:
The ability to read and write a variety of image formats.
That is of course important. But in my view really a separate issue from developing a library of analysis routines. The latter just have to operate on numarray arrays and need not to worry about how the data gets there. Of course you need to get your data in numarray. PIL seems to do a good job with images, except for 16bit tiffs which causes me quiet some problems. Anybody know a good solution for getting 16bit tiffs into numarray?
I'd agree that support for image formats should be decoupled from processing functions
ImageMagick has a good set. All of ImageMagick should be wrapped.
Isn't there already a python interface to ImageMagick?
Perhaps we should look at how much work it would be to adopt Travis's wrapped version for numarray. It may be fairly simple to do if his version uses the the more common api calls. Perry
Perry Greenfield wrote:
Hi Ed,
A cople of things I would like to see:
The ability to read and write a variety of image formats.
That is of course important. But in my view really a separate issue from developing a library of analysis routines. The latter just have to operate on numarray arrays and need not to worry about how the data gets there. Of course you need to get your data in numarray. PIL seems to do a good job with images, except for 16bit tiffs which causes me quiet some problems. Anybody know a good solution for getting 16bit tiffs into numarray?
I'd agree that support for image formats should be decoupled from processing functions
ImageMagick has a good set. All of ImageMagick should be wrapped.
Isn't there already a python interface to ImageMagick?
Perhaps we should look at how much work it would be to adopt Travis's wrapped version for numarray. It may be fairly simple to do if his version uses the the more common api calls.
Perry
I have checked this out a bit. All the Numeric function calls are among the ones that numarray emulates. All but one of them seem to be properly DECREFed. The exception is in "imageobject.c", line 973, where "bitobj" is created. Also: ImageMagick was forked, producing GraphicsMagick. The two are very similar. Which is better to use? Ed Jones
Hi Ed,
A cople of things I would like to see:
The ability to read and write a variety of image formats.
That is of course important. But in my view really a separate issue from developing a library of analysis routines. The latter just have to operate on numarray arrays and need not to worry about how the data gets there. Of course you need to get your data in numarray. PIL seems to do a good job with images, except for 16bit tiffs which causes me quiet some problems. Anybody 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 ...) Regards, Sebastian
Hi Sebastian, 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. Peter 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 ...)
Edward C. Jones wrote:
Peter Verveer wrote:
On Saturday 03 January 2004 03:11, Edward C. Jones wrote:
IM
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".
I had a look and I guess that indeed you could use the nd_image package for some low level stuff (I am the author of nd_image). nd_image is however also still being developed and I am looking for directions to further work on. I wondered if there is anything you would like to see in there?
Thanks for your response. I have put a slightly revised version of IM on my web page "http://members.tripod.com/~edcjones/". The new version includes functions, written in C, for slicing arrays.
A cople of things I would like to see:
The ability to read and write a variety of image formats. ImageMagick has a good set. All of ImageMagick should be wrapped.
I have wrappers for ImageMagick done (for Numeric). See pylab.sourceforge.net -Travis
participants (5)
-
Edward C. Jones -
Perry Greenfield -
Peter Verveer -
Sebastian Haase -
Travis E. Oliphant