🚀 go-pugleaf

In <1992Jul24.113320.8898@uoft02.utoledo.edu> jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:
>  Plans are in the making for other routines such as Forier filtering routines.
>  (If you don't know what that is, don't ask, I'm not good enough at it yet 
>  to be able to explain it coherently) Edge detection, and other convolution
>  routines are also being built.  

>  Once again, if you have any suggestions, questions, or help to give me, 
>  I would be delighted.

An excellent resource for your project could be _Digital Image Processing_ by
Gonzalez and Wintz.  This book not only makes writing the code to a image
routine easy, but gives a fairly understandable explanation to the theory 
behind a lot of the algorithms.

At the University of Louisville, students who take EE 618 Image Processing
and Pattern Recognition are required to build (of the course of the semester)
a general Image Processing package, complete in the end with a classifier.
The classifier we built (in the lab group I was in) end up being pretty
bad (only 56% accuracy).  We ended up using a VAX 3100 Graphic Workstation.
Now all the Image students at U of L use a HP UNIX graphic workstation
(much faster).

E-mail me if you want more information.


-- 
-------------------------------------------------------------------------------
			 |
Dave Jansing             | "Free at last, they took your life . . .
University of Louisville |  But they could not take your pride!"
Electrical Engineering   |  -- Clivelles & Cole after U2, "Pride"
			 |
-------------------------------------------------------------------------------

In article <1992Jul24.113320.8898@uoft02.utoledo.edu>, jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:
|>    At any rate, I am looking for more ideas from anyone even vaguely interested 
|>   in image processing for routines to include.  

How about routines for :

	- Thinning
	- Connected component labeling
	- Logical operations (AND, OR, XOR, ...)
	- Adding "noise"
	- Rotation

On a related matter, I think it would be a good idea if, along with a FAQ
for this newsgroup, some knowledgable person maintains an image processing
bibliography, to which the readers can contribute... just an idea...

Cheers,

-- Siamak

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Siamak Khoubyari		   	| Internet:    khoub-s@cs.buffalo.edu
Department of Computer Science	/ CEDAR	| BITNET:      khoub-s@sunybcs.BITNET
State University of New York at Buffalo | UUCP: !uunet!cs.buffalo.edu!khoub-s
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

In article <1992Jul24.113320.8898@uoft02.utoledo.edu> jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:
>    I am writing them to be used like normal DOS or UNIX command-line commands.
>  Why?  Because I want this package to be portable and GUI's are harder to 
>  port.

I've had some experience with using/building packages like this.  Basically,
there are two flavors: program-oriented and code libraries.  The first,
like yours, uses individual programs that each perform a function.  The
second provides a set of program-callable routines, again each performing
a single function.  Each type has its advocates.  Personally, I like both.
Programs, especially with a scripting capability, are great for simple
tasks and rapid prototyping.  Libraries are better if you really want to
have reusable code components, but you can't just pull one routine off
the shelf and run it by itself.

My own feeling is that the best way to design this package is to build
a library of code and wrap minimal program support around each one to 
create the command-line callable programs.  Each program is basically
nothing but opening files and calling the corresponding routine(s) from
the library.  Keep the parameters consistent between the two, and you 
have a versatile system that allows you to switch easily between the two.  
For example, 

   ADD infile1 infile2 outfile

and

   void Add(Image im1, Image im2, Image out)

I know you were looking for suggestions as to what to put in the package,
but a good design is the best starting point.  

-- 
Bryan Morse                University of North Carolina at Chapel Hill
morse@cs.unc.edu           Department of Computer Science

In article <1992Jul24.113320.8898@uoft02.utoledo.edu>,
jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:

|>   At any rate, I am looking for more ideas from anyone even vaguely
|>interested 
|>  in image procesing for routines to include...				   -Jon Arney
|>				   jarney@jupiter.cse.utoledo.edu

You mentioned some image processing routines which you have included,
and you have
requested suggestions for more routines to include.

I'd like to point out that, for many applications, the ability to
process a user-selected
subset of an image is crucial.  Examples of this include selecting and
"zooming"
a portion of an image on a display device, selecting a subset of an
image
and then performing some operation (such as a Fourier transform) on the
subset,
selecting multiple subsets and comparing them (or, for example, adding
them)
in some manner.  For my own work, it is essential that I be able to
select a
subset of an image, then be able to "integrate" the subset by summing
the
pixel rows or columns - and ultimately output this information to a
file.

Unfortunately, the interactive selection of a subset of an image is
probably more
effective and easier by means of GUI-type programs, rather than by
command-line-
driven programs.  Fortunately, it may be relatively simple to construct
a
device-dependent shell which is capable of executing your command-line
program
while providing basic GUI features (use of a pointing device, mouse,
etc.). 

Finally, you can always get good ideas by looking at existing software
packages.
There has been some discussion on this newsgroup of existing image
processing packages, and I'd like to put in a plug for IRAF, the Image
Reduction and Analysis Facility (more info is probably available
through
NOAO, P.O.Box 26732, Tucson AZ 85726).  This is a COLOSSAL public-domain
(?) package
developed by the National Optical Astronomy Observatories (NOAO), and
in
part by the Space Telescope Science Institute (STScI) and others.  This
package
has an extensive compliment of functions for processing astronomical
data,
but in addition has plenty of general image processing tools.  It is
also extensible,
so you may develop your own tools for use with IRAF.  It is supported
on a wide variety of machines, and it is quite simple to install - but
it is HUGE!  If nothing else,
finding out more about the tools included in this package might give
you
some good ideas for tools to include in your own program!

In article <edjans01.711996751@starbase.spd.louisville.edu> edjans01@starbase.spd.louisville.edu (David Jansing) writes:
>In <1992Jul24.113320.8898@uoft02.utoledo.edu> jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:
>>  Plans are in the making for other routines such as Forier filtering routines.
I'd be really interested in the Fourrier routine.
I'm myself writing a package and built several routines already, as histogram,
convolution, contrast stretching and a got a source code for a U*ix GIF
reader and got it work on my PC with Turbo C 2.0.

>>  Once again, if you have any suggestions, questions, or help to give me, 
>>  I would be delighted.
Hope I can help by any means 'coz I'm in the same s**t!


>An excellent resource for your project could be _Digital Image Processing_ by
>Gonzalez and Wintz.  This book not only makes writing the code to a image
>routine easy, but gives a fairly understandable explanation to the theory 
>behind a lot of the algorithms.
I find it myself a bit too theoritical and lots of math and not much
of actual code. But I think it's the way to start if one wants to code
that kind of package.
Here a very small bibliography I used for my project in number plate
recognition:

	o Boyle, R.D. Computer Vision: a first course. Blackwell Scientific
	  Publications, 1988.

	o Braggins, D. The machine vision sourcebook. IFS publications Ltd,
	  1986.

	o Gonzalez...

	o Jain, A.K. Fundamentals of Digital Image Processing. Prentice-
	  Hall, 1989.

	o James, M. Pattern recognition. BSP Professional Books, 1987.

	o Lewis, R. Practical Digital Image Processing. Ellis Horwood, 1990.

	o Pearson, D. (editor). Image Processing. The Essex Series in 
	  Telecommunication and Information Systems, 1991.

	o Simon, J-C. La reconnaissance des formes par algorithmes. Masson,
	  1985.

	o Vernon, D. Machine Vision: Automated Visual inspection and Robot
	  Vision. Prentice Hall, 1991.

However I have heard of a book from Addison-Wesley:
Computer and Robot Vision (part I and II) by Robert M. Haralick et al. but
dunno what's in it.

>At the University of Louisville, students who take EE 618 Image Processing
>and Pattern Recognition are required to build (of the course of the semester)
>a general Image Processing package, complete in the end with a classifier.
>The classifier we built (in the lab group I was in) end up being pretty
>bad (only 56% accuracy).  We ended up using a VAX 3100 Graphic Workstation.
>Now all the Image students at U of L use a HP UNIX graphic workstation
>(much faster).
>
>E-mail me if you want more information.
I will!


Cheers,

=========================================================
Jean-Baptiste SU

" Because the sage always confronts difficulties,
  he never experiences them " -- Lao Tzu

e-mail: kbs@ccr.jussieu.fr
=========================================================


-- 
=========================================================
Jean-Baptiste SU

" Because the sage always confronts difficulties,

In article <14162@borg.cs.unc.edu> morse@satie.cs.unc.edu (Bryan Morse) writes:

> My own feeling is that the best way to design this package is to build
> a library of code and wrap minimal program support around each one to 
> create the command-line callable programs.  Each program is basically
> nothing but opening files and calling the corresponding routine(s) from
> the library.  Keep the parameters consistent between the two, and you 
> have a versatile system that allows you to switch easily between the two.  
> For example, 
>
>      ADD infile1 infile2 outfile
> 
> and
> 
>      void Add(Image im1, Image im2, Image out)
> 


Hmm, did you know you were describing the khoros system, and
philosophy?

-- John

In article <1992Jul24.113320.8898@uoft02.utoledo.edu>, jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:
[...]
!    I am writing them to be used like normal DOS or UNIX command-line commands.
!   Why?  Because I want this package to be portable and GUI's are harder to 
!   port.
!    I also intend to make this package public domain, and anyone interested in
!   contributing to the project is welcome to do so and the company would be
!   most appreciated.
[...]
!   GIFTORAW infile outfile
!   RAWTOGIF infile outfile
!   HIST infile [outfile]	    
!   NEGATE infile [r] [g] [b] outfile
!   THRESH infile [r=x] [g=y] [b=z] outfile
!   BRIGHTEN infile [r=x] [g=y] [b=z] outfile
!   CONTRAST infile [r=x] [g=y] [b=z] outfile
!   ADD infile1 infile2 outfile
!   CALIBRATE dark light infile outfile
[...]
!   Once again, if you have any suggestions, questions, or help to give me, 
!   I would be delighted.

You might want to check out Jef Poskanzer pbmplus package which
already does all of what you describe.  It is command line oriented and
will build under just about any environment from DOS boxes to CRAYs.  Plus,
it is designed to be extensible, hence adding new algorithms is easy.

-- 
!@$^&*)($#$@!@#$^&*()_+_)(*&^$#@!$^&*()_+)(*&^$#@$^&*+_(*&^$#@#^&*()&*$#@(*&+_$!
 Dominic Richens  :  dominic@shamin.genie.uottawa.ca  :  Tel. (613) 564 9911 
      MCRLab, Dept of Elec Eng, University of Ottawa, K1N 6N5, CANADA   
"You construct intricate rituals which allow you to touch the skin of other men"

In article <1992Jul26.163849.2216@jussieu.fr> kbs@ccr-p6.ccr.jussieu.fr (Khac-Binh SU p5717) writes:
>In article <edjans01.711996751@starbase.spd.louisville.edu> edjans01@starbase.spd.louisville.edu (David Jansing) writes:
>>In <1992Jul24.113320.8898@uoft02.utoledo.edu> jarney@jupiter.cse.utoledo.edu (jonathan arney) writes:
>>>  Plans are in the making for other routines such as Forier filtering routines.
>I'd be really interested in the Fourrier routine.

You should get the book _Numerical Recipes in C_ by Press, Flannerey, et al,
Cambridge Press. Has very good Fourier routines. You'll need the smaller 
_Numerical Recipes Example Book_ as well. A MUST for all IPers.

>I'm myself writing a package and built several routines already, as histogram,
>convolution, contrast stretching and a got a source code for a U*ix GIF
>reader and got it work on my PC with Turbo C 2.0.

They sell a disc in MS-DOS format; you can simply copy the relevant code.

Mike
-- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w  :q  :wq  :wq! ^d  X ^?
exit X Q  ^C ^? :quitbye  CtrlAltDel   ~~q  :~q  logout  save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@  ^L  ^[c  ^# ^E ^X ^I ^T ? help  helpquit ^D  ^d 
man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."

I have uploaded all the Numerical recipes source code to my Sun.  I'd be
happy to ftp it all to a public site.  Where should I send it?
--
Arthur T. Manning   <manning@halley.est.3m.com>                       O
3M Center 518-1    St Paul MN  55144-1000        \___/______         o   
ph. 612 733-4401   fax 612 736-3122             __  / _ _ _  \      .
Allin1--> <MANNING @MRGATE @EST780>            (_/_/_/ / / /_/      <><

In article <Bry3I7.7pH@news.cso.uiuc.edu> ritley@uiucmrl.bitnet () writes:

	[stuff deleted]

>There has been some discussion on this newsgroup of existing image
>processing packages, and I'd like to put in a plug for IRAF, the Image
>Reduction and Analysis Facility (more info is probably available
>through
>NOAO, P.O.Box 26732, Tucson AZ 85726).  This is a COLOSSAL public-domain
>(?) package
>developed by the National Optical Astronomy Observatories (NOAO), and
>in
>part by the Space Telescope Science Institute (STScI) and others.  This
>package
>has an extensive compliment of functions for processing astronomical
>data,
>but in addition has plenty of general image processing tools.  It is
>also extensible,
>so you may develop your own tools for use with IRAF.  It is supported
>on a wide variety of machines, and it is quite simple to install - but
>it is HUGE!  If nothing else,
>finding out more about the tools included in this package might give
>you
>some good ideas for tools to include in your own program!

Speaking of good packages for astronomy (or useful in other fields), you
should look into MIRA, a new package available from:

Axiom Research, Inc.
Box 44162
Tucson, AZ  85733
(602) 791-2864

MIRA works with short integer and short real (32 bit) images, does all kinds
of arithmetic operations, photometry, works with 1-d data, curve fitting,
convolutions, etc. and has really nice display capabilities as well.  For example, you can do interactive contrast and brightness changes by moving the mouse
and there is a 100x100 pixel real-time zoom and pan window which shows part
of the displayed image.  Many can also be displayed at one time.  The whole thing
is operated using graphic buttons and sometimes keystrokes.  It displays using
151 levels and has a real time column, row, and pixel value readout.
It has a fully windowed 3-d graphical interface that's much faster than
Windows (256 color video modes).  MIRA will on a 486/33 will blow away IRAF
running on a Sparcstation.

Hardware requirements: VESA compatible SVGA card using ET-4000 chip with 1MB
of memory (< $200), math coprocessor, 2--4 MB of system memory, 386+, 3 button
mouse.

Mike Newberry