HDTenEightyP/NetNews huggingface dataset:
From: sjreeves@eng.auburn.edu (Stan Reeves)
Newsgroups: sci.image.processing,comp.compression,comp.compression.research,alt.comp.compression
Subject: Re: REQUEST FOR A STANDARD IMAGE
Keywords: photographer, grayscale, still picture
Date: 14 Sep 92 15:37:15 GMT
Organization: Auburn University Engineering

In article <92Sep11.053254.23570@acs.ucalgary.ca> provine@enel.ucalgary.ca (Joseph Provine) writes:
>could anyone give me a pointer to the ftp-site where I can get the grayscale
>image of the photographer(the standard test image used). The image of size 
>512X512 is preferable.

The cameraman image is available via anonymous ftp from eedsp.gatech.edu
in database/images/camera.256.  The file is unformatted byte format with
image dimensions 256x256.  I've never seen a 512x512 version of the 
cameraman.


--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
From: cflatter@nrao.edu (Chris Flatters)
Newsgroups: sci.image.processing
Subject: Re: Image Synthesis, Rendering and Display A
Date: 4 Sep 92 22:18:17 GMT
Article-I.D.: nrao.1992Sep4.221817.26709
Reply-To: cflatter@nrao.edu
Organization: NRAO

In article <1992Sep4.182427.1774@colorado.edu> heuring@riker.cs.colorado.edu (Vincent Heuring) writes:
>I need references to texts that describe the algorithms for image
>synthesis, rendering, and display. Entry level and advanced would
>be appreciated!

Digital Image Processing
Rafael C. Gonzalez and Richard E. Woods
Addison Wesley 1992
ISBN 0-201-5083-6

The updated version of the text by Gonzalez and Wintz. A comprehensive
but expensive (about $65) text: appears to be to image processing what
Foley and van Dam is to graphics.

	Chris Flatters
	cflatter@nrao.edu
From: edjans01@orion.spd.louisville.edu (David Jansing)
Newsgroups: sci.image.processing
Subject: Looking for Jean-Claude
Date: 14 Sep 92 17:10:43 GMT
Organization: University of Louisville

I hate to waste space in a newsgroup on this, simply for an oversight on my 
part.  But, here goes:

I am looking for Jean-Claude.  I used to have his Internet address until my
system promptly ate it and I have no way to recover it.  Jean-Claude, I have
the object recognition code that you were asking about.  Please e-mail me
ASAP so that I can send it to you.

Many thanks to those who had to sit through this message,

Dave

-- 
--------------------------------------------------------------------------------
Dave Jansing                     | "What we call the beginning is often the end
Electrical Engineering Department|  And to make an end is to make a beginning.
University of Louisville         |  The end is where we start from . . ."
                                 |  -- T.S. Eliot, "Four Quartets"
--------------------------------------------------------------------------------
DISCLAIMER:	The opinions expressed here are strictly my own and do not
		necessarily reflect those of the Department of Electrical
		Engineering or any other department within the University
		of Louisville.
From: henebry@matt.ksu.ksu.edu (Geoffrey M Henebry)
Newsgroups: sci.image.processing
Subject: availability of lowtran 7?
Keywords: remote sensing, radiometric correction
Date: 10 Sep 92 20:13:45 GMT
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

greetings!  does anyone have a lead on the availability of lowtran 7 over the
net?  many thanks! -- g. henebry aka henebry@matt.ksu.edu
Newsgroups: sci.image.processing
From: dak@cip-s02.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Favorite FFTs (was 'Re: 2d dft phase info')
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date: 10 Sep 92 11:23:17 GMT

smith@mcclb0.med.nyu.edu writes:

>> 
>> My favourite Fourier transform package is a Radix-8 FFT that does
>> 512x512 float -> 256x512 complex in 4.3 sec on a DECStation 5000/200,
>> and was written by myself (that's why it is my favourite ;-), and
>> doesn't contain a Hartley transform.

>Now that we are on to 'favourite FFTs', mine is Lynn ten Eykes multi-radix FFT
>which does FFTs of any sized multi-dimensioned array with dimensions that have 
>prime factors less than 49 (X must be even, however) the output of a 200x200 
>array of reals is 101x200 complex.  It is very fast, due to special code to 
>handle factors of 2,3,4,5 & 8, in addition to the primes to 49.  We have 
>ported it to IBM, VMS, Ultix and UNICOS (Cray).  Its good... (less than 3 
>secs for 512x512 reals on a DECstation 5000/240)

Well, while we're at it.
My favorite FFT is a number theoretic transform which works modulo some
big prime number p at the end of your number range, where p-1 is dividable
by N. Uses modulo arithmetic instead of complex arithmetic, and makes
use of the fact that in these number systems Nth primitive roots of 1 exist
which are simple integers. (Base 2 FFTs work quite ok).

Digital filters implemented with these FFTs have no calculation rounding
errors whatsoever, and 16 bit are sufficient for almost all conceivable
picture filters. A pity signal processors are that bad at modulo arithmetic.
Newsgroups: sci.image.processing
From: spz@specklec.mpifr-bonn.mpg.de (S.P.Zeidler)
Subject: Re: 2d dft phase info
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 8 Sep 1992 23:24:48 GMT

In <1992Sep7.110102.25536@bnr.co.uk> pgh@bnr.co.uk (Peter Hamer) writes:

>Serious question: so why not use the Hartley transform which does not
>introduce these redundancies in the first place?
>... or use your favourite Fourier package and display the Hartley transform?

My favourite Fourier transform package is a Radix-8 FFT that does
512x512 float -> 256x512 complex in 4.3 sec on a DECStation 5000/200,
and was written by myself (that's why it is my favourite ;-), and
doesn't contain a Hartley transform.

Seriously, though: I need phase and modulus seperately, and it wouldn't
make sense to first compute 10,000 Hartley transforms followed by the
same number of phase/modulus separations, because that would take even
longer than shoving the stuff thru the optimized FFT.

regards,
	spz
-- 
        spz is S.Petra Zeidler  Copyright 1992 S.Petra Zeidler
spz@specklec.mpifr-bonn.mpg.de  
 MPI fuer Radioastronomie Bonn  
    Auf dem Huegel 69, Germany  reading prescription: cum kilo salis
Newsgroups: sci.image.processing
From: dave@pipi.iis.u-tokyo.ac.jp (David Wuertele)
Subject: Re: Sub-band coding of HDTV Images Help
Organization: Institute of Industrial Science, University of tokyo.
Date: Wed, 9 Sep 1992 10:25:00 GMT

In article <1992Sep8.221740.9893@uoft02.utoledo.edu> kmurali2@uoft02.utoledo.edu writes:
>	  I am plannning to do my MS thesis in Sub-band coding of HDTV Images. 
>Are there any easily undestanding (w/o much of abstract Mathematics) tehnical 
>papers or text books avialable ? Is there any technique that can be used to 
>reduce the bit/pixels. Any help would be appreciated.

Anything published by the following (mostly Bellcore) engineers should be
useful: H. Gharavi, A. Tabatabai, D.LeGall, T.C. Chen, P.E. Fleischer 
R. Ansari.  Bellcore has been developing subband coding for ATV for some
time now.

You should also check out _Subband Image Coding_, edited by John W. Woods,
Kluwer Academic Publishers.  Chapters 6&7 (and their bibliographies)
should be most useful.

There are of course many techniques for reducing the number of bits/pixel,
lossy and otherwise.  Search topics: information theory, coding of
waveforms, digital communication.  See also newsgroups *.compression.*

Dave
-----
David Wuertele, Yasuda Lab, Electronic Engineering, Institute of Industrial Science,
University of Tokyo.				dave@windsor.iis.u-tokyo.ac.jp
Newsgroups: sci.image.processing
From: gene@aee.aee.com (Gene Kochanowsky)
Subject: What Postscript rips can I get source code to?
Summary: Looking for source code suppliers of Postscript RIPS
Keywords: postscript
Organization: Associated Electronic Engineers
Distribution: sci
Date: Tue, 15 Sep 1992 22:47:05 GMT

I have a project that will require a postscript 2 RIP, and would like to
have as complete a list of suppliers as possible. If I could get both
commercial and public domain, that would be great.


Thanks

gene@aee.com

-- 
------------------------------------------------------------------------------
Gene Kochanowsky                           | "And remember ....
Associated Electronic Engineers, Inc.      |       The better you look ... 
2864 Cercy Trace                           |       
Newsgroups: sci.image.processing
From: joelb@beta.lanl.gov (Joel R. Berendzen)
Subject: Re: Favorite FFTs (was 'Re: 2d dft phase info')
Organization: Los Alamos National Laboratory
Date: Wed, 9 Sep 1992 18:13:07 GMT

Newsgroups: sci.image.processing
Subject: Re: Favorite FFTs (was 'Re: 2d dft phase info')
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: Los Alamos National Laboratory
Keywords: 

I wish that I had known of the existence of your favorite FFT's a few weeks
ago when I was looking for public-domain FFT codes.  It would be VERY useful
if anyone with favorite FFT's could post where to obtain them by ftp.  
Here are the ones that I know about:

ncar.ucar.edu: /dsl/lib/fftpack 
     1-d real/complex and complex/complex FFT's, mixed-radix, 
     sequential-storage only.
ncar.ucar.edu: /dsl/lib/ecmfft
     complex/complex  multiple simultaneous fft, radix 2, 3, & 5.  Array storage
     may be used.  This code has the disadvantage of needing a work array
     as large as the data array.  Aside from that fairly fast.  I have run
     it on Crays, Convexes, VAXes, SGI's, HPs700's, Suns, and IBM RISC/6000s.
ncar.ucar.edu: /chammp/shallow/lib/fft99f.f:
     a real/complex version of the ecmfft code described above.
pprg.unm.edu: /pub/khoros/contrib/cfft.shar.Z
     a 2-d real/complex or complex/complexradix-2 fft code, designed to be used
     as a filter from UNIX or integrated into KHOROS.

What I'm looking for is a 2-D real/half-complex mixed-radix code that doesn't
require additional storage, analogous to the VECLIB SRC2FT routine found on
Convexes.  I'm doing FFT filtering of 2304x2304 images, and the requirement
of additional storage makes the memory requirements too large to be practical.

--Joel Berendzen
From: honig@aster.ics.uci.edu (David A. Honig)
Subject: Re: keywords search on public domain?
Newsgroups: sci.image.processing
Reply-To: honig@ics.uci.edu (David A. Honig)
Organization: UC Disneyland, in the Kingdom of Bren
Date: 4 Sep 92 23:52:26 GMT

 stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
>In article <1992Sep4.132558.2652@bernina.ethz.ch> gst5@igpho (Li) writes:
>
>(This address is bogus. Please get your system configuration fixed.)
>
>>I'm sure that we can do a searching on public domain by keywords.
>
>Search public domain what? Software? News? Books? And why limit it to
>public domain? Do you have a need for material that you can use without
>worrying about copyright limitations? Very little of the material posted
>to news is public domain, and you will find no books in the last 17
>years that are. Some software is released that way, but not much.
>
>>For
>>example, we can search for softwear or reference on wavelet by keyword
>>'wavelet'. Dose anybody know how to do this?

I think the orig poster was talking about archie, the ftp archive finder.

Try "archie keyword"

--
David "Dances with Motion Sensors" Honig

'People that are really very wierd can get into sensative positions
and have a tremendous impact on history.'	-- Vice President Dan Quayle
Newsgroups: sci.image.processing
From: prabhu@cs.tulane.edu (Prabhu)
Subject: *** WANTED : GLC MATRIX SOFTWARE ****
Keywords: Grey Level Co-occurrence Matrix, Texture
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Date: Mon, 14 Sep 1992 16:07:21 GMT
Nntp-Posting-Host-[nntpd-4244]: jupiter


	I am looking for ftp-able/free software for fast computation
of Grey Level Cooccurrence Matrices of images.  

	Software in C for Sunstations would be ideal, but I would appreciate
*any* pointer to such a software.  Pl respond to prabhu@cs.tulane.edu and
I'll post a summary, if there is enough interest.

	Thanks very much - prabhu

---------------------------------------------------------------------------
Devaraya Prabhu      				prabhu@cs.tulane.edu  
Dept of Comp Science
Tulane University 
New Orleans

          Relax, this .sig virus is *really* harmless..

===========================================================================
Newsgroups: sci.image.processing
From: dbriggs@zia.aoc.nrao.edu (Daniel Briggs)
Subject: Re: 2d dft phase info
Organization: National Radio Astronomy Observatory, Socorro NM
Date: Tue, 8 Sep 92 13:34:49 GMT

In article <1992Sep7.110102.25536@bnr.co.uk>
  pgh@bnr.co.uk (Peter Hamer) writes:
>Serious question: so why not use the Hartley transform which does not
>introduce these redundancies in the first place?

Well, in at least some fields, (mine, for instance), the fundamental observable
actually starts in the Fourier plane.  We measure Fourier coefficients
directly, and reconstruct the image from them.  And, as someone else already
mentioned, it's really not all that painful to go from a real full plane to
a complex half plane.  There is a lot of bookkeeping that must go into our
programs, no matter which transform we use.  Keeping track of transform
direction just isn't that much added complexity.  Finally, is or isn't the
FHT kosher to use these days?  When first it came out, Stanford was trying
to milk it for all it was worth.  I actually sent for one of their information
packets.  They wanted something like 5% of gross sales per copy or some hefty
minimum, for any program which used the transform.  That all by itself was
a good reason not to use the transform at the time, when it doesn't really
provide much more in the way of functionality than the FFT.

-- 
| Daniel Briggs  (dbriggs@nrao.edu)                      |        USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |            DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        |
Support the League for Programming Freedom  (info from league@prep.ai.mit.edu)
Newsgroups: sci.image.processing
From: akarpowicz@mta.ca (Adam Karpowicz)
Subject: CCD resolution
Reply-To: akarpowicz@mta.ca
Organization: Mount Allison U, Sackville, N.B. Canada 
Date: Wed, 16 Sep 1992 01:45:02 GMT


Hello there,

I am shopping for a TV camera (nothing fancy, just a b/w CCD) to be
used with a frame grabber board.  The board captures 640x480 pixel
images in 32000 colors or 256 shades of grey.

I am somewhat confused by resolutions of cameras as listed in factory
specs.  I understand the standard NTSC signal cannot be better than
525 vertical by 350 horizontal scan lines.  Do I get better quality
pictures with a camera having higher numbers of picture elements in the
CCD chip, say 800x500 vs 500x400? Should the number of elements be
proportional to the aspect ratio of the board resolution for best
results?  Specs also list numbers of horizontal and vertical TV lines for
a camera besides the numbers of picture elements (for the 800x500 camera
they list 570 vertical by 350 horizontal) and no. of NTSC scan lines.
What are they?

Thanks in advance

Adam
Newsgroups: sci.image.processing
From: provine@enel.ucalgary.ca (Joseph Provine)
Subject: REQUEST FOR A STANDARD IMAGE
Summary: Photographer image
Date: Fri, 11 Sep 92 05:32:54 GMT
Organization: ECE Department, U. of Calgary, Calgary, Alberta, Canada
Keywords: photographer, grayscale, still picture

Dear netters,
could anyone give me a pointer to the ftp-site where I can get the grayscale
image of the photographer(the standard test image used). The image of size 
512X512 is preferable.
Thanks.
Joseph Provine.
provine@enel.ucalgary.ca
P.S.:I guess such a request recently appeared on the net. If that person 
got a reply, please pass me the location.
From: pgh@bnr.co.uk (Peter Hamer)
Subject: Re: 2d dft phase info
Reply-To: pgh@bnr.co.uk (Peter Hamer)
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB
Date: Mon, 7 Sep 1992 11:01:02 GMT

In the referenced article spz@specklec.mpifr-bonn.mpg.de (S.P.Zeidler) writes:
>In <9209011949.AA19843@hp-and.an.hp.com> susanm@hp-and.an.hp.com (Susan Margulies) writes:
>
>One thing that you might want to take into account is that the Fourier
>transform of an ordinary image is hermitic, ie if you do a transform
>AxB real image -> AxB complex Fourier transform, you got quite some
>redundancies.

Serious question: so why not use the Hartley transform which does not
introduce these redundancies in the first place?

>Doing instead AxB image -> -(A/2+1)xB phase and (A/2+1)xB modulus
>will give you a nicely viewable (and displayable) Fourier transform.

... or use your favourite Fourier package and display the Hartley transform?

Regards, Peter

PS The Hartley transform can be regarded as a `tidier' Fourier transform.

   a) Uses cos(x)+sin(x) rather than cos(x)+i*sin(x).
   b) The inverse is the same operation as the transform.
   c) Takes real => real.
   d) Does not introduce redundancies into the representation.
   e) Even clearer relationship to the sine and cosine transforms.
   d) Easy to convert between Hartley and Fourier transforms.
From: davis@gauss.enet.dec.com (Peter Davis)
Newsgroups: sci.image.processing
Subject: Re: Image Synthesis, Rendering and Display A
Date: 9 Sep 92 01:12:53 GMT
Organization: Digital Equipment Corporation


In article <1992Sep4.182427.1774@colorado.edu> heuring@riker.cs.colorado.edu (Vincent Heuring) writes:
>I need references to texts that describe the algorithms for image
>synthesis, rendering, and display. Entry level and advanced would
>be appreciated!

Actually, image synthesis is most commonly used to describe modelling and
rendering of 3D graphics, and does not come under what's usually referred
to as image processing.  The IEEE has a book on Image Synthesis.  I believe
it's edited by Nelson Max.  It's a collection of papers on various topics of
image synthesis, and might be a good place to start. 

                   /
                  /
        /  /  /  /		Peter Davis,	Digital Equipment Corp.
       /  /  /  /				davis@3d.enet.dec.com
      /__/__/__/
     /
  __/
From: torbjorn@forit.forut.no (Torbjorn Sund)
Newsgroups: sci.image.processing
Subject: Re: ccd camera
Date: 6 Sep 92 17:39:53 GMT
Organization: Norwegian Telecom/FORUT, Norway

In article <jecome01.715798061@starbase.spd.louisville.edu>, jecome01@rigel.spd.louisville.edu (Eric Comer) writes:
    	if the lens caps is place on a ccd camera and an image is capture,
    	why aren't all of the pixel values 0 (black)?

Because of the "dark current": charge accumulates on a CCD due
to BOTH light falling on it (zero in your case), and due to thermal
effects. The dark current builds up over time, so you normally
want to keep exposure times short (if you can). If you cannot
(like in astronomy) you can instead reduce the dark current by
cooling the CCD array, charge build-up falls off exponentially
(roughly) with temperature.

Anyway, dark current is quite predictable at constant temperature,
so it can be predicted and subtracted out.

	when the image is
    	normalized it seems like there are faint light diagonal lines
    	throughtout the whole image.  the image acquired was a gray scale
    	image the min value was 0 and the max value was 6.  any ideas?
    
The CCD array is not perfect - meaning that the individual cells
have different response characteristic and different dark current.

When you have subtracted the dark current you also should
calibrate the image, accounting for each pixel's individual
response characteristic. If you use the CCD array as an ordinary
camera the calibration may not be necessary of course.

torbjorn.
Newsgroups: sci.image.processing
From: edge@unislc.uucp (Brian Edginton)
Subject: splitting a frame into fields
Organization: Unisys Corporation SLC
Date: Mon, 14 Sep 1992 13:04:45 GMT

In the process of grabbing a moving image, the frame I grab has
the fields split by n pixels, n apparently related to the speed
of the object as it is being grabbed.  This shift occurs both
with a still-image digital camera (mavica 5000) and a digital 
video camera (panasonic 9xxx).  Although frame and field mode
can be selected on the mavica, it appears only to affect the
recording on floppy, not the live video image.

Is there a software or hardware solution to this problem. I 
have the ability to manipulate the image in TIFF format after
I have grabbed it and stored it to disk, but I would really 
like a solution that could be applied before the frame grabber.

Thanks in advance,
 edge

-- 
Brian Edginton                | {hpda, sun, uplherc}!unislc!edge
Unisys                        | unislc!edge@cs.utah.edu
320 North 2200 West B2E10     | (801) 594-6009 Human (usually)
Salt Lake City, Utah 84116    | (801) 594-3827 Fax
Newsgroups: sci.image.processing,sci.math.num-analysis,sci.physics,sci.space,comp.graphics,comp.visualization
From: keith@msmri.med.ubc.ca
Subject: WANTED: Cheap cpu cycles and Megaflops
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 8 Sep 1992 15:54:51 GMT

Please post replies to sci.image.processing or e-mail me directly.  I will
post a summaries of replies to sci.image.processing.

I am interested in inexpensive hardware for large amounts 
of images processing.  By inexpensive I mean for only 
a few thousand dollars or less.  I am thinking along the
lines of a additional processor board for a PC or SUN.  I have seen PC
mother boards with a Intel i860 coprocessor. 
Does anyone have any experience with this
chip.  I understand the gcc compiler (a free C complier) will generate
code for the chip.  Again, does anyone have any experience with this product
or any other inexpensive number crunchers.

Thanks in Advance


Keith S Cover
Physics, UBC
Vancouver, BC
Canada
keith@msmri.med.ubc.ca
From: smith@mcclb0.med.nyu.edu
Newsgroups: sci.image.processing
Subject: Re: Favorite FFTs: Lynn Ten Eyke's FFT available.
Date: 10 Sep 92 19:20:18 GMT
Organization: NYU Medical Center, New York, NY 10016, USA

I have recieved several requests for the FFT code.  I have made a 
concatinated file called 'ten_eyke.txt' and put it in out anonymous area for 
people to FTP if they want.  For VMS people, take 'ten_eyke_pak.com' which is 
a VMS_SHARE file.  The concatinated file should be just fine, however, for 
people cursed with UNI*X: the code compiles without problem under Ultrix, and 
also on all the other platforms we have tried.

This routine, and a _WHOLE_LOT_MORE_ is a part of our image processing 
package called MDPP (Micrograph Data Processing Program) which runs on DEC 
workstations (either VAX/VMS or Ultrix).  It is a general purpose image 
processing package, originally targetted at problems in electron microscopy, 
but now very much more general in scope.  It requires X-windows for image
display, but there are versions for VWS and a small number of other displays, 
like the Lexidata and the Gould IP8500 and IP9000.  If you are interested 
in this you can order MDPP from the DECUS software Library which charges a 
nominal fee for handling and media.  From memory, the part number is V00535.

+----------------------------------------------------------------------------+
|Ross Smith,  Research Computing Resource, Department of Cell Biology, NYU-MC|
|E-Mail:  SMITH@NYUMED.BITNET (BITNET),   SMITH@MCCLB0.MED.NYU.EDU (Internet)|
+----------------------------------------------------------------------------+
From: ritley@uimrl7.mrl.uiuc.edu ()
Subject: Has anyone programmed DT-2853 f.grab?
Reply-To: ritley@uiucmrl.bitnet ()
Organization: Materials Research Lab
Date: Tue, 8 Sep 1992 12:47:33 GMT



We have recently acquired a Data Translation DT-2853 "low-cost"
frame grabber.

Does anyone have any experience programming this board?

I am new to programming personal computers in the C language, and
I am experiencing some difficulty in reading/writing the registers
which control this board.

Unfortunately the company (Data Translation) insists that most people
abandon the manual which accompanies this product, and instead
purchase additional software, which I am reluctant to do.

Many thanks!

Newsgroups: sci.image.processing