HDTenEightyP/NetNews huggingface dataset:
From: ben@ph.tn.tudelft.nl (Ben Verwer)
Subject: Re: image processing loops: a c programming question
Organization: Delft University of Technology
Distribution: sci.image.processing
Date: Wed, 19 Aug 1992 23:53:56 GMT

klamer@mi.el.utwente.nl (Klamer Schutte) writes:

>In <ben.714157437@galaxy> ben@ph.tn.tudelft.nl (Ben Verwer) writes:

>A problem with using a linear array is present when multiplication is
>slower as pointer indirection (for instance, on a sparc, or a 68000).
>Accessing image pixel (x,y) will involve accessing image[y*xsize+x];
>otherwise *(imageptr[y]+x) is used.

This is false. Or misleading. You do not need to muliply to get
to a point. Once you have set a pointer to it, increments will do.
Only when you do random acces to the image you are right.

>>The loop I most often use is:

>>pixel *p = beginofdata;
>>int i;  /* make sure this is 32 bits! */

>>for (i=xsize*ysize; --i>=0;) *p++ = ...;

>>This is the fastest on 68000Us! And also on sparcstations. Try it. (thanx to 
>>Gert van Antwerpen)

>It is not on sparcstations (and i doubt it on 68k). Faster is:

>pixel *p_end = beginofdata+sizeofdata+1;

I think you have a +1 too much.

>for(p=beginofdata;p<p_end;) *p++ = ...;
>(At least with /bin/cc and Sun C 1.4. gcc 2.2.1 didn't care...)

I don't get a difference between the following two:
for (p=start; p<end;) *p++ = 1;  /* end = start + leng */
for (i=leng; --i>=0;) *p++ = 1;
And it reads a lot better.

>Don't read that program. Above principles are not correct applied!
>(i.e. lot of looping with pointer[index] instead of *pointer++ ! )
>Also statements which are in the loop can be easily placed outside!

Through, but only the innerloop is important. 
And as you see, the principles are applied there.
(Although I agree the x=0; x<xend; x++ should be x=xend; --x>=0;
but It was written for a compiler on a vector machine which only
recognized the x=0; x<end; x++ type, sorry about that)
The little loop to fill the filter and the final copying of the result
take about .1 % of the total filter time.
Why don't you spend a few hours to see if you can get it back to
.05%. I'am sure lots of people will be interested. :)

>Klamer

Ben
From: julien@scs.leeds.ac.uk (J C Flack)
Newsgroups: sci.image.processing
Subject: Re: Segmentation and Remotely Sensed Data -- SUMMARY
Keywords: segmentation, remote sensing
Date: 13 Aug 92 16:29:33 GMT
Organization: The University of Leeds, School of Computer Studies

As promised here is a summary of the replies I got to from my query
concerning the segmentation of remotely sensed images. The original
posting was sent to: sci.image.processing, comp.infosystems.gis and
IMARS-L.

====================================================================

The evaluation and comparison of segmentation techniques has long
since been a problem:

In article <1992Aug5.185035.21313@Arco.COM> opus@arco.com (Dr. Steven 'Wild Man'Wong)
> The problem with evaluating standard segmentation processes is that we
> have too much of the 'See ma, no hands' syndrome that also affects the KBS
> (knowledge based systems)  community.  Unfortunately, I also was part of
> that crowd.  What we need is a public accessible place with standard
> benchmarks and algorihms that everyone can experiment  with, test, and
> compare against.  This idea has been proposed again and again but still
> hasn't gathered any steam.  The standard picture of 'the girl' just
> doesn't cut it.

Peter Sincak mailing to IMARS-L argued that it is difficult to establish
definitions of edges, homogenous areas, clusters ... and it is therefore
difficult to evaluate segmentations.

I think part of the problem in complex scenes, is that you can have
more than one correct segmentation --- it really depends on what your user 
wants from a decomposition of the image.

=====================================================================

Eric Majani recommends the following reference:

Hierarchical Segmentation using a composite criterion for remotely sensed
imagery
Goldberg-M and Zhang-JY
Photogrammetria Vol 42 issue 3, pp. 87-96, 1987

=====================================================================

Janet Franklin, in reply to my comp.infosystems.gis posting suggested that 
the work done by Tailor, Cross, Mason, Hogg et al on the knowledge base 
interpretation of remotely sensed images could be useful.

Their work is based on a map guided segmentation using high level domain
specific knowledge to improve the acuracy of the image decompostion.

I have a complete set of reference for that work ... email me if you are
interested.

=====================================================================

Thanks to all those who replied to my postings ....

Julien Flack,
University of Leeds.
email: julien@scs.leeds.ac.uk
Newsgroups: sci.image.processing
From: fox@rei2.uucp (Fuzzy Fox)
Subject: Re: image processing loops: a c programming question
Date: Wed, 12 Aug 1992 18:15:48 GMT
Distribution: sci.image.processing
Organization: REI

slehar@kendall.bu.edu (Steve Lehar) writes:

>This works o.k,  but  the problem now is  that   you are performing  a
>multiplication  in  the innermost  loop  of the  program,  which slows
>things down quite a bit.

I hope you are aware that that when you create an array, say, int
array[200][200], then when you reference array[i][j], there is an
implicit multiplication performed by the compiler to find this address.
There is no performance loss or gain by doing the multiplication
explicitly when you malloc your own array.

The solution given previously, using an array of pointers, is probably
the best speed-up.

-- 
#ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
#define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
#define  FALSE  1   |
#endif              |         How's my posting?  Call 1-800-ALT-FLAME
Newsgroups: sci.image.processing
From: hanisch@stsci.edu (Bob Hanisch,N406,4910)
Subject: Re: WANTED: MAximum entropy C source code
Reply-To: hanisch@stsci.edu
Organization: Space Telescope Science Institute, Baltimore MD
Date: Wed, 12 Aug 1992 15:31:10 GMT

John Skilling has a company called Maximum Entropy Data Consultants, Ltd. that
markets his MEM code (called MEMSYS5).  This is generally considered the state-
of-the-art MEM package, at least within the astronomy image processing community.
I know they sell to a lot of medical imaging people too.  If you are interested,
MEDC can be contacted at 20 Cockroft Place, Cambridge, England  CB3 0HF.  
Tel. (44)223-312562.  Send e-mail to mark@vax.ra.physics.cambridge.ac.uk.

There are some PD packages too, but the ones I know of are layered on larger
astronomical data reduction and analysis packages.  NRAO's AIPS software includes
an MEM implementation, and NOAO's IRAF package just recently has a package.
The AIPS software is written in Fortran, and IRAF software is written in a
pre-processed language similar to RATFOR.
---
Robert J. Hanisch                       Tel. (410)338-4910   Fax. (410)338-5090
Space Telescope Science Institute       NSI: hanisch@stsci.edu [130.167.1.2]
3700 San Martin Drive                   DECNet: STSCIC::HANISCH [6549::] 
Baltimore, MD  21218  USA               Bitnet: hanisch@stsci

Xref: sparky sci.image.processing:441 comp.compression:3007
From: eschbach@abc.wrc.xerox.com (Reiner Eschbach)
Newsgroups: sci.image.processing,comp.compression
Subject: Re: Compressing halftone images
Date: 13 Aug 92 12:20:10 GMT
Organization: Xerox

In article <sjreeves.920810102554@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:

>I read in SP Magazine that "coding of halftone images, once thought to
>have great promise, has not been successful."  I would like to find out
>more information about this.  Can someone summarize what's been done in
>this area and just how "unsucessful" the efforts have been?

Stan,
how do I have to read this? What is 'coding of halftone images', there are a
lot of different ways to read this. Since the title says 'compression', do you
want to know about the compression of halftones? Also there is a big
difference between a halftone you have just generated and want to
store/transmit/print and a halftone image you have just scanned from a paper
original.

Reiner
From: huff@mcclb0.med.nyu.edu (Edward J. Huff)
Newsgroups: sci.image.processing
Subject: Reconstruction of electrical impedance data
Date: 21 Aug 92 02:25:05 GMT
Followup-To: sci.image.processing
Organization: NYU Chemistry Dept.

This question was posted to the IMAGE-L bitnet mailing list.

Date: 21 Aug 1992 09:35:00 +1000
From: T.BARKER@QUT.EDU.AU

Dear Net-ters,
 
A colleague of mine is curious to determine whether or not there are any
software implementations of reconstruction techniques for data based on
electrical impedance measurements. It appears that standard CT
reconstruction
technqiues can't be applied to this data.
 
Details of public-domain and/or commercial if there are any would be of
interest to him. Code in C would be ideal.
 
Please send any details or *pointers to me directly and will pass them on.
 
Thanks in advance for any and all assistance,
 
Tim Barker				email barker@qut.du.au
Centre for Medical & Health Physics
Queensland University of Technology
Brisbane. QLD
Australia
Newsgroups: sci.image.processing
From: jeganath@leland.Stanford.EDU (Muthuveerappan Jeganathan)
Subject: Frame Grabbers <-> PC RAM
Organization: DSG, Stanford University, CA 94305, USA
Distribution: usa
Date: Wed, 19 Aug 92 22:49:41 GMT

Hi, I hope this is the appropriate news group for the following discussion. I 
have a question regarding image transfer from frame grabbers to PC RAM. I am 
interested in capturing a 1k x 1k x 8 (1 MB) image from a CCD using a frame 
grabber. At what rate can I dump these images from the frame grabber on to the 
PC RAM or possibly a SCSI hard disk. If the CCD operated at 5Hz frame rate, is 
it possible to transfer all 5 MB to the RAM in a second? I have been told data 
transfer is limited by the PC bus. Is this true? How about with a DMA transfer?
If the answer depends on the system, what are the typical transfer rates for
a 486 50 MHz PC with 64 MB RAM and 1 GB SCSI HD.

Any help is appreciated. Thanks. By the way, if this would be more appropriate
for another group let me know.

-- Muthu Jeganathan
From: edmund@swanee.ee.uwa.edu.au (Edmund Lai)
Newsgroups: sci.image.processing
Subject: Edge Detection
Date: 20 Aug 92 01:31:41 GMT
Organization: Elec Eng, Univ of Western Australia

Does anyone have a bibliography of edge detection algorithms/techniques?
If so, could you please email me?

I can post it to the group later if there is enough interest.

Edmund Lai
Department of Information Engineering		phone: +852-609-7988
The Chinese University of Hong Kong		fax:   +852-603-5032
Shatin, N.T., Hong Kong.			email: mklai@eng.ie.cuhk.hk
From: elw@jaguar.sky2 (Ellis Workman, 1-157 Med Sci, 4-4435)
Newsgroups: sci.image.processing
Subject: Re: image processing loops: a c programming question
Date: 13 Aug 92 19:34:34 GMT
Reply-To: elw@jaguar.sky2
Organization: Sun Microsystems

In article 713717257@isy, stefang@isy.liu.se (Stefan Gustavson) writes:
>alien@essex.ac.uk ("Adrian F Clark") writes:
>
>
>>In article <1992Aug10.221247.8016@cfa.harvard.edu> alberto@cfa.harvard.edu (Alberto Accomazzi) writes:
>
>>Actually, you can get just a smidgin faster on most machines:
>>  dp = data;
>>  for (y = 0; y < ysize; y++)
>>    for (x = 0; x < xsize; x++)
>>      *dp++ = ...
>>}
>
>>but this is probably even less readable than the other examples
>>posted.
>
>You really don't need a separate x counter varaiable. Use the
>pointer itself for the inner loop:
>
>  dp = data;
>  for (y = 0; y < ysize; y++)
>   {
>     rowend = (y+1)*xsize*sizeof(int); /* or whatever size your data is */
>     for ( ; (int)dp < rowend; )       /* note the obscure empty statements */
>       *dp++ = ...
>   }
>
>This saves one increment instruction. It makes a difference.
>Yes, I have written a program like this. No, I wouldn't like to
>try to read somebody else's program written like this.
>
>And now for the *really* compact stuff...
>
>For greater obscurity, you could use the pointer for the outer loop, too,
>and move some initialization inside the for(;;) construct, and remove the
>silly type casts that weenie compilers try to make you put in there:
>
>  for(dp=data; dp<xsize*ysize*sizeof(int);)
>    {
>      for(rowend = dp+xsize*sizeof(int); dp<rowend; )
>        *dp++ = ...
>    }
>
>Or if you don't care which row you are on, you could just write:
>
>  for(dp=data; dp<xsize*ysize*sizeof(int); *dp++= ...)


			???????

		DO YOU REALLY WANT TO DO THE 
		
			xsize*ysize*sizeof(int)
			
			(compute byte count)
		
		ON EVERY ITERATION OF THE LOOP??????


				ISHHHH ...

how about
			for(i=xsize*ysize, dp = data;i;i--)
				*dp++ = ...;


-------------------------------------------------------
Ellis Workman                   Internet:  elw@mayo.edu
Biomedical Imaging Resource
Mayo Foundation                 Talk:    (507) 284-4435                  
Rochester, MN 55905             FAX:     (507)-284-1632
-------------------------------------------------------
Newsgroups: sci.image.processing
From: hwang@cortez.mitre.org (Vincent Hwang)
Subject: Computing MTF of a digitizing system
Keywords: MTF
Organization: The MITRE Corporation
Distribution: global
Date: Wed, 19 Aug 1992 18:53:40 GMT

	I need to compute the modular transfer function of a digitizing 
system. This value (the fourier spectrun of the response of the digitizing
system to an impulse signal) provides some handle on the sharpness of the
digitizing system. This is useful in finding out whether the lens based 2D
digitizer provide sufficient sharpness.

	Questions:
1. Any suggestion on how to compute the MTF and what's the procedure (I 
	want the MTF of the scanner, not the MTF of the display/hardcopy)
2. Any other measurement one might use to measure the sensor sharpness?

	Thank you.

Vincent Hwang (vhwang@mitre.org)

Newsgroups: sci.image.processing
From: ojt@cs.brown.edu (Oren J. Tversky)
Subject: Edge Detection Software Needed
Organization: Brown University Department of Computer Science
Date: Fri, 14 Aug 1992 15:30:50 GMT



To whom it may concern,

     I have an interest in obtaining public domain edge detection software
for use on a research project.  Any information would be greatly appreciated.
Thank you.


							Oren
______________________________________________________________________________
Oren Tversky           I believe we are on an irreversible trend toward more
ojt@cs.brown.edu       freedom and democracy - but that could change.
..!brunix!ojt                        -- Vice President Dan Quayle
Newsgroups: sci.image.processing
From: rvloon@cv.ruu.nl (Ronald van Loon)
Subject: Re: TIFF? file format
Originator: rvloon@triton.cv.ruu.nl
Date: Thu, 13 Aug 1992 08:33:47 GMT
Organization: University of Utrecht, 3D Computer Vision Research Group

In <1992Aug12.145332.5315@lut.ac.uk> M.L.Cook3@lut.ac.uk (Vaxaholics Anonymous) writes:

| "I am working on a parallel ray tracing system for my MSc project, this system
| "computes 24 bits per pixel images with a resolution of 505 x 511. What I would
| "like to be able to do is to output the images my system produces in a format,
| "say TIFF for example so that I can port it off on floppy and print it in colour
| "on another machine.
| "
| "Could somebody out there give me exact details of an image format that I could
| "use for this purpose, I think TIFF is most likely what I need. If anyone has
| "any tips for PD software outputting such file formats well to colour postscript
| "printers that would be useful as well...

Use the ppm-format, as found in the PBMPLUS package at export.lcs.mit.edu; it
is simple, has almost no overhead, and can be converted to dozens of other
formats, if needed.
-- 
Ronald van Loon (rvloon@cv.ruu.nl) 3DCV Group, Utrecht, The Netherlands.

Insanity is not bad in itself as long as there is a system to it. (H.Liberg)
Healthy absurdism once in a while has never hurt anybody (me)
Newsgroups: sci.image.processing,comp.compression
From: ski@leland.Stanford.EDU (Rick VanderKam)
Subject: Re: Compressing halftone images
Summary: Some references for compression of halftoned images
Keywords: halftone halftoning compression image processing
Organization: Information Systems Lab, Stanford University  94305
Date: Fri, 14 Aug 92 18:41:39 GMT

In article <sjreeves.920810102554@eng.auburn.edu> sjreeves@eng.auburn.edu (Stan Reeves) writes:
>
>I read in SP Magazine that "coding of halftone images, once thought to
>have great promise, has not been successful."  I would like to find out
>more information about this.  Can someone summarize what's been done in
>this area and just how "unsucessful" the efforts have been?
>
>Stan Reeves
>Auburn University, Department of Electrical Engineering, Auburn, AL  36849
>INTERNET: sjreeves@eng.auburn.edu


I can't give an exhaustive summary, but can perhaps get you started.
I'll assume that you're referring to binary (monochrome) rather than
color halftoning.  There seems to be relatively more research activity
in the area of halftoning per se than there is in the area of
compression of halftoned images.  If you are interested in halftoning
by itself, see the Proceedings of the ICASSP-91, ICASSP-92, and
SPIE-92 conferences for some of the most recent proposed methods.  A
few (not all) of the relevant names are Neuhoff & Pappas, Zakhor, and
Allebach.  There is also Ulichney's book, _Digital Halftoning_, put
out by MIT Press (1987), which presents a variety of analyses on a
variety of halftoning techniques.

There are two forms of compression that you might be interested
in---lossless and lossy.  For lossless (noiseless, no information
loss) compression, the most promising method (in my opinion) is IBM's
Q-coder, which is documented by about five articles in the _IBM
Journal of Research and Development_, November, 1988 (Vol. 32, No. 6).
These articles have other useful references as well.  IBM is working
to have their system established as part of the Joint Binary Image
Group (JBIG) standard for compression.  It seems to be an excellent
noiseless coding scheme, which routinely produces coding rates that
achieve or beat the first-order entropy for a variety of halftoned
images. 

For lossy compression, there have been a couple of published works in
which the halftoning and compression are done separately (Neuhoff &
Pappas, ICASSP-91; Y.-M. Chao, "An Investigation into the Coding of
Halftone Images," Ph.D. thesis, MIT, 1987).  I co-authored a paper
(with Chou, Riskin, and Gray) at
ICASSP-92 showing that a better idea is to do the halftoning and
compression jointly.  In that paper, we showed an image compressed at
about 11:1 which looks pretty decent (we think!).  We are continuing
to work on this problem here at Stanford.  Hope this helps....

Rick A. Vander Kam
rvk@isl.stanford.edu
From: flick@flick.almaden.ibm.com (Myron Flickner)
Newsgroups: sci.image.processing
Subject: Re: Anyone working on automatic defect detection?
Keywords: defect fourier convolution
Date: 22 Aug 92 07:03:31 GMT
Organization: IBM Almaden Research Center


There are journals that cover this area, try the springer publication
'Machine Vision and Applications, an International Journal' to start
with.

imaging away / M. Flick Flickner, IBM Almaden Research Center, San Jose, CA
VNET/BITNET: FLICK at ALMADEN  Internet: flick@almaden.ibm.com
From: kale@aelle.cs.odu.edu (Vijay S. Kale)
Newsgroups: sci.image.processing
Subject: 2-D scanner
Date: 14 Aug 92 21:08:14 GMT
Organization: Old Dominion University

HI Folks,

 I would appreciate any info/pointers on any 2-D scanner to convert
 a 256x256 image into a an image datafile. The image could be in 
 direct contact with the scanner. The requirement of the scanner is
 that it should be very compact.

 Pl send me ur replies directly at kale@asmsun.larc.nasa.gov

..Vijay
From: julien@scs.leeds.ac.uk (J C Flack)
Newsgroups: sci.image.processing
Subject: The IMARS-L mailing list
Date: 17 Aug 92 10:46:52 GMT
Organization: The University of Leeds, School of Computer Studies


I had some queries concerning the IMAGRS-L list. Here is a summary of it's 
function:

*  Digital Image Processing of Remotely Sensed Data
*  Sizelim= 500             Renewal= Yearly
*  LOOPCHECK=FULL,RECORD(20)
*  Review= Public           Subscription= Open
*  Notify= No               Reply-to= List,Respect
*  Ack = Msg                Files=Yes
*  Validate= Store only     Stats= Normal
*  x-Tags= Yes              Formcheck= yes
*  Notebook= Yes,A,Monthly  Mail-via= Distribute
*  Errors-to= KUKO@CSPUNI12 Formcheck= Yes
*  Confidential= NO
*
*  Owner=  KUKO@CSPUNI12    (Peter Sincak)
*
*    The area of digital image processing of remotely sensed data
* should be the main topic of this club - so exactly the problems of
* the interest  are the  methods  of  digital  image  processing  for
* remotely sensed data (like LANDSAT or SPOT) as well as microwave
* and also new types of data for remote sensing of the Earth or other
* objects. Also computer problems with these very time demanding
* methods  can  interesting  including visualization, paralel
* computing etc.
*

The list currently has 225 subscribers. The traffic is not too high ---
about 3 or 4 messages a day.

To subscribe, send the subject line 'subscribe IMAGRS-L' to LISTSERV@CSEARN.
If you have any problems please contact the owner of the list, Peter Sincak,
KUKO@CSPUNI12.

Enjoy,

--- 
Julien Flack,
Leedss University.
email:julien@scs.leeds.ac.uk
Newsgroups: sci.image.processing
From: thomsen@spf.trw.com (Mark Thomsen)
Subject: Re: SPLAT
Organization: TRW Inc., Redondo Beach, CA
Date: Wed, 12 Aug 92 18:08:51 GMT

Bryan Morse writes
> As I understand it, splatting is a technique for resampling images.
> Imagine each original pixel as a snowball and throw that snowball
> at the new image ("splat!").  Each snowball as it hits distributes
> its snow (intensity) over a region.  Each new pixel is then incremented
> by the contribution of that snowball to that pixel.  Usually, the
> distribution is Gaussian, but others have been used.  Once you've
> thrown all of the snowballs and added their contributions, you have
> a new resampled image.
>  
> Basically, the idea is to reverse the usual interpolation.  Rather than
> computing each new pixel as a function of the old pixels, compute the
> relative contribution of each of the old pixels (their splat) to the
> new ones and add these together for the new pixels.

This can work provided that the "size of the snowball" is correct for
the output grid. If the output grid is sparse relative to the input grid
then it should work fine with lots of small snowballs - small intensities
and small area (suggest adding based on original intensities and then
normalizing/scaling values). If the output grid is dense relative to the
input grid then the snowballs should have large area (to ensure every
output grid point is covered) and large intensities (one snowball
"splats" many grid points).

This snowball scaling aspect seems critical. The projection of the input
grid points onto the nearest output grid points is known to leave holes
and create weird collision effects. Fixing it by making the input grid
points distributions (snowballs) and projecting the distributions onto
the output grid in an additive manner may or may not be faster than a
classic warp with interpolation. Has anyone done a study? A timing
comparison with real code?

I would be most interested in seeing an algorithm statement, either in
a posting or by reference to a paper (or book?).

Mark R. Thomsen