HDTenEightyP/NetNews huggingface dataset:
From: edgar@function.mps.ohio-state.edu (Gerald Edgar)
Newsgroups: sci.image.processing
Subject: Re: TIFF? file format
Date: 12 Aug 92 18:21:20 GMT
Organization: The Ohio State University, Dept. of Math.
NNTP-Posting-Host: function.mps.ohio-state.edu


I note that the TIFF file format specification (version 6.0)
is 121 pages long...
-- 
  Gerald A. Edgar                Internet:  edgar@mps.ohio-state.edu
  Department of Mathematics      Bitnet:    EDGAR@OHSTPY
  The Ohio State University      telephone: 614-292-0395 (Office)
  Columbus, OH 43210             -292-4975 (Math. Dept.) -292-1479 (Dept. Fax)
Xref: sparky sci.image.processing:485 comp.graphics:8978 rec.arts.fine:608
From: IMAGING.CLUB@OFFICE.WANG.COM ("Imaging Club")
Newsgroups: sci.image.processing,comp.graphics,rec.arts.fine
Subject: Re: Art gallery image processing
Date: 19 Aug 92 16:05:42 GMT
Organization: Mail to News Gateway at Wang Labs

I have now Emailed a copy of this article to everyone who requested
it.  There's also a detailed article on what the National Gallery in
Washington is doing regarding image processing in the current issue
of Federal Computer Week; this second article is rather long for
rekeying, so I'll be happy to (US) mail anyone a copy.  Wang doesn't
do this kind of imaging; we focus on document imaging.
---------------------Michael.Willett@OFFICE.Wang.com-----------------

There is a rather interesting article in the August 15th issue of
the Economist, describing what Washington's National Gallery of
Art and Munich's Pinakothek are doing regarding image processing
of paintings.  The National Gallery is building a computer system
covering 2,800 of its American works.  Whereas photographs fade
and wrinkle, the digital images are accurate, detailed and last
forever.  The digital images will be able to track how the colors
of the paintings change over time; yellows are especially bad.

The National Gallery is using their system to determine if the
pictures need cleaning.  They swab a small section of a dirty
painting, letting their computer work out differences between the
clean and the dirty parts, and then apply these differences to the
digital record of the painting as a whole, producing a computer-
generated image of what a picture would look like were the whole
thing to be given a scrub.

Another technique, borrowed from satellite imaging, is to exaggerate
the color contrasts within a painting's digital image.  Apply the
trick to Jan Gossaert's "Adoration of the Magi", for example, and a
pair of cherubs, long darkened to the same muddy brown as the beam
they are sitting on spring to view.

Computers will also change art galleries for visitors, too.  By
putting their paintings on computer, galleries can make them
easier to find, understand and appreciate.

The Doerner Institute, a research laboratory attached to Munich's
Pinakothek, is using a computer system similar to the National
Gallery's to measure accurately the damage done to pictures in
transit.  By comparing scans of a painting's "Craquelure"--
the network of hairline cracks that covers its surface--before and
after it is moved, the institute can see if the cracks have multiplied
or lengthed.  An early trial of a painting, taken on a 250-mile road
trip in a car, showed that even a properly packed picture gets lots of
new cracks when it is moved.  The institute plans to publish its
findings in October.

If anyone would like a full copy of this article, let me know.

--------------------Michael.Willett@OFFICE.Wang.com------------------
From: honig@pan.ics.uci.edu (David A. Honig)
Subject: Re: Question on image registration and accuracy
Newsgroups: sci.image.processing
Reply-To: honig@ics.uci.edu (David A. Honig)
Organization: UC Disneyland, in the Kingdom of Bren
Date: 21 Aug 92 22:23:59 GMT

 tirone@neurocog.lrdc.pitt.edu (Steve Tirone) writes:
>
>	I've got several MRI images of the brain, taken over period of
>time (minutes), and there's some slight movement of the head between
>images.  I'd like to "register" these images, that is, align them so
>the images all overlap exactly.  I do not have any external markers to
>use as reference points (fiducials), BTW.
>
>	What is a good way to go about this?   It appears that without fiducials,
>automatic image registration has been attempted in various ways, from
>superposition of centroids and principal axes (?) to correlation using FFTs to
>contour matching via Hough transforms...anyone care to comment on what might be
>the "best" solution for my purposes?
>
>	Also, I'm wondering what kind of error (in the pixel values) I might
>introduce by registration and how I might quantify it.  Is it possible to align
>images with subpixel accuracy?   How does resampling the image affect my
>interpretation of the pixel value? (Like "its an average signal value, plus x
>percent error introduced by resampling after rotation" ??)
>
>	I'm a newcomer to image processing.  Any pointers, solutions, etc.
>very much appreciated.
>
>Steve
>tirone@neurocog.lrdc.pitt.edu


A big issue is whether the registration algorithm expects the kind of motion
present inthe image.  Some algs were designed to handle only 2-D
translations & rotations, not rotations in depth, or volume-changes.
Its an open problem.

--
David "Dances with Motion Sensors" Honig

"Don't you believe half of what you see, and none of what you hear."
	---Lou Reed
From: smr@csuvax1.csu.murdoch.edu.au (smrr)
Newsgroups: sci.image.processing
Subject: Neural nets for image processing? (not recognition)
Keywords: image processing neural nets references
Date: 22 Aug 92 15:22:31 GMT
Organization: Murdoch University

Hello everybody,

Has anyone used or come acros papers on neural nets for image  processing. 
This is not the same as using neural nets for pattern recognition. I was
wondering if it is possible  to use neural  nets for image enhancement, 
edge detection and segmentation of objects in an image.

Any pointers would be  appreciated. Please reply by email or a posting
to the newsgroup. All email replies will summarised and posted to the
newsgroup

Thanks in advance.

Shri Rai.

Email:  smr@csuvax1.csu.murdoch.edu.au
Newsgroups: sci.image.processing
From: sjreeves@eng.auburn.edu (Stan Reeves)
Subject: "Consumer" Image Processing
Organization: Auburn University Engineering
Date: Mon, 17 Aug 1992 14:56:51 GMT


I would like to collect some evidence that image processing is moving more
and more into the mainstream of consumer electronics.  More specifically,
I am trying to find information that would motivate a greater emphasis on
teaching image processing to undergraduates in electrical engineering (if,
indeed, this is justified).

Examples that I've thought of are:

- HDTV will soon move into the mainstream and will require engineers with
  a working knowledge of image and video signal processing.
- Increasingly sophisticated VCR's and camcorders are beginning to use
  image processing.
- AT&T's picture phone points to the fact that true videophones are just
  around the corner.
- The possibility of telecomputers that provide random access to TV programs
  and interactivity --- this will soon be feasible with continued growth in
  available bandwidth and transmission technology.

Any thoughts along these lines would be greatly appreciated.  I will summarize
email responses to the net.



--
Stan Reeves
Auburn University, Department of Electrical Engineering, Auburn, AL  36849
INTERNET: sjreeves@eng.auburn.edu
From: mapsajw@gdr.bath.ac.uk (S A J Winder)
Newsgroups: sci.image.processing
Subject: Re: Canny Edge Detector
Date: 18 Aug 92 12:05:46 GMT
Organization: Bath University Computing Group

A couple of weeks ago, I posted an article describing the Canny edge
operator. A number of people have e-mailed me regarding the Smoothing
stage:

ME> 1. Smooth the image with a Gaussian kernel. This has the form:
ME>    G(r) = 1/(2*pi*sigma*sigma) * exp(-r*r/(2*sigma)) for the 2D case,
ME>    where sigma is the smoothing factor. You can do this in two 1D
ME>    operations with G(x) = 1/(sigma*sqrt(2*pi)) * exp(-x*x/(2*sigma))
ME>    -- first smooth horizontally, then smooth the result vertically.

There is of course a mistake here. The Gaussian functions are actually:

  G(r) = 1/(2*pi*sigma*sigma) * exp(-r*r/(2*sigma*sigma))
                                                 ^^^^^^
  G(x) = 1/(sigma*sqrt(2*pi)) * exp(-x*x/(2*sigma*sigma))
                                                 ^^^^^^
Sorry to anyone I lead astray with my previous posting.

Simon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Simon A.J. Winder             Computer Vision Research
 sajw@uk.ac.bath.maths    University of Bath Computing Group
 Tel: +44 (0)225 826183   /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
From: santi@jazz.sni-usa.com (Santiago Paredes)
Newsgroups: sci.image.processing
Subject: Document Image Processing Systems
Keywords: image products
Date: 21 Aug 92 13:40:47 GMT
Reply-To: santi@jazz.sni-usa.com (Santiago Paredes)
Organization: Siemens-Nixdorf Information Systems, Inc. Cambridge, MA

I am conducting a survey on comercially available document image
processing systems.
Any feedback in the form of first hand experience, articles,
or product evaluations would be highly appreciated.


**********************************************************************
* SIEMENS                    Santi Paredes                   Internet:
santi@sni-usa.com    *
* _______                        R&D Division                 USENET:
uunet!nixbur!santi   *
*                                       4 Cambridge Center              
  Ph: [usa](617)864-0066   *
* NIXDORF                   Cambridge, MA   02142       FAX:
[usa](617)864-3176   *
**********************************************************************
Xref: sparky sci.image.processing:484 comp.graphics:8974
From: jk87377@cc.tut.fi (Juhana Kouhia)
Newsgroups: sci.image.processing,comp.graphics
Subject: Re: Art gallery image processing
Date: 19 Aug 92 11:50:44 GMT
Organization: Tampere University of Technology


In article <1992Aug19.015109.26290@bert.eecs.uic.edu>
spiff@bert.eecs.uic.edu (Jason Leigh) writes:
>In article <1992Aug18.214345.25931@unocal.com>
>stgprao@xing.unocal.com (Richard Ottolini) writes:
>>I assume when all the bells and whistles are worked out, some good Asian
>>electronics company will figure out how to get the technology cheaply into
>>amateur's hands.
>
>And why would it be an Asian company who would do this?

Ok, let it be a non-USA company then.
It could be a USA company if there's no fine mechanical parts in the
product -- maybe they could buy mechanical parts from an Asian
company. Hmmmm.

It is the fact that Japan is the leader in making this kind of
products for public.


Juhana Kouhia
:-)
Xref: sparky sci.image.processing:503 sci.med.physics:340 comp.graphics:9023
From: tirone@neurocog.lrdc.pitt.edu (Steve Tirone)
Newsgroups: sci.image.processing,sci.med.physics,comp.graphics
Subject: Question on image registration and accuracy
Date: 20 Aug 92 17:26:56 GMT
Followup-To: sci.image.processing


	I've got several MRI images of the brain, taken over period of
time (minutes), and there's some slight movement of the head between
images.  I'd like to "register" these images, that is, align them so
the images all overlap exactly.  I do not have any external markers to
use as reference points (fiducials), BTW.

	What is a good way to go about this?   It appears that without fiducials,
automatic image registration has been attempted in various ways, from
superposition of centroids and principal axes (?) to correlation using FFTs to
contour matching via Hough transforms...anyone care to comment on what might be
the "best" solution for my purposes?

	Also, I'm wondering what kind of error (in the pixel values) I might
introduce by registration and how I might quantify it.  Is it possible to align
images with subpixel accuracy?   How does resampling the image affect my
interpretation of the pixel value? (Like "its an average signal value, plus x
percent error introduced by resampling after rotation" ??)

	I'm a newcomer to image processing.  Any pointers, solutions, etc.
very much appreciated.

Steve
tirone@neurocog.lrdc.pitt.edu
From: sngattan@matt.ksu.ksu.edu (Sanjay N Gattani)
Newsgroups: sci.image.processing
Subject: Metrabyte MV1 frame grabber
Date: 14 Aug 1992 15:05:35 -0500
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu
Keywords: image analysis..

HI:

	I have access to JAVA software which can accept only Metrabyte MV1
frame grabber ( or a digitizer board ).  This board is manufactured by
KEITHLEY METRABYTE and now they have stopped manufacturing this until
unless someone will plave an order with them for not less than 1000 pieces.
My request then is:  IS there anyone out there who wants to dispose off
MV1 frame grabber.?  Contact at  sngattan@matt.ksu.ksu.edu

sanjay
Newsgroups: sci.image.processing,comp.graphics
From: sngattan@matt.ksu.ksu.edu (Sanjay N Gattani)
Newsgroups: sci.image.processing
Subject: What is a GIF/TIFF/PCX...etc format?
Date: 17 Aug 92 22:15:09 GMT
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

Hello:

	How does a GIF file (or for that matter, any other format file)
store the pixel information from an image screen?  Is it convenient to access
this information so that I can write my own basic image processing routines.
The kind of work that I am doing does not require sophisticated image
processing packages.  But I do have a frame grabber that can store
the image in various formats.  My question is: how can I perform some of the filtering operations?  Please email to 

    sngattan@matt.ksu.ksu.edu


sanjay
Newsgroups: sci.image.processing,rec.photo,rec.video
From: wong@qucis.queensu.ca (Tak Shing Wong)
Subject: Re: summary(still camera whose image to computer)
Organization: Computing & Information Science, Queen's University at Kingston
Date: Sat, 15 Aug 1992 00:17:11 GMT

The latest issue of Popular Science has a very good article on this 
kind of cameras. 
Newsgroups: sci.image.processing
From: cychong@magnus.acs.ohio-state.edu (Chi Yin R Chong)
Subject: Need program for converting tiff file to gif file
Organization: The Ohio State University
Date: Thu, 13 Aug 1992 11:54:04 GMT

Hi, every sci.image.processing subscriber,

     Does anyone has the program that can convert tiff file into gif file? I
used a software called DeskScan II in Mac to run the HP scanner and scanned
some pictures which are saved as tiff files.

     Thank you so much for your great help.

Robert Chong
Newsgroups: sci.image.processing,comp.graphics
From: spiff@bert.eecs.uic.edu (Jason Leigh)
Subject: Re: Art gallery image processing
Organization: University of Illinois, Chicago
Date: Wed, 19 Aug 1992 01:51:09 GMT

In article <1992Aug18.214345.25931@unocal.com> stgprao@xing.unocal.com (Richard Ottolini) writes:
>I assume when all the bells and whistles are worked out, some good Asian
>electronics company will figure out how to get the technology cheaply into
>amateur's hands.

And why would it be an Asian company who would do this?



-- 
---------------------------------------------------------  ___
| The opinions expressed above are necessarily those of | \\     \\  | \\
| the Electronic Visualization Laboratory, NAAAT!       |  \\---  \\ |  \\
| Send Replies to: spiff@bert.eecs.uic.edu (Jason Leigh)|   \\____ \\|   \\____
Newsgroups: sci.image.processing
From: dominic@scooter.genie.uottawa.ca (Dominic Richens)
Subject: Re: Frame Grabbers <-> PC RAM
Originator: dominic@
Reply-To: dominic@shamin.genie.uottawa.ca
Organization: MCRLab - University of Ottawa
Distribution: usa
Date: Thu, 20 Aug 92 13:55:05 GMT


In article <1992Aug19.224941.12953@leland.Stanford.EDU>, jeganath@leland.Stanford.EDU (Muthuveerappan Jeganathan) writes:
!Hi, I hope this is the appropriate news group for the following discussion.

Err...well, I think rec.video.production, or comp.multimedia might get you
better results, hence you could cross-post to those groups too.

!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.

The silly ISA bus is the limiting factor.  You are limited to
2MBytes/second in transferring data from a periferal card to the CPU or to
the DMA controller.  Hence for a one million pixel image, you are limited
to 2 frames per second, and that is assuming you are doing 16-bit
transfers.

The May 1990 BYTE magazine had an article on the EISA bus (page 240), which
compares it to the ISA bus for transfer rates, etc..

I, for example, am using a EISA machine, but my frame grabber is an AT
card which essentailly turns my expensive EISA bus into an expensive ISA
bus!

dominic

-- 
!@$^&*)($#$@!@#$^&*()_+_)(*&^$#@!$^&*()_+)(*&^$#@$^&*+_(*&^$#@#^&*()&*$#@(*&+_$!
 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"
From: klamer@mi.el.utwente.nl (Klamer Schutte)
Newsgroups: sci.image.processing
Subject: Re: image processing loops: a c programming question
Date: 19 Aug 92 07:23:34 GMT
Distribution: sci.image.processing
Organization: University of Twente, BSC-El

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

>The basic question is how to program for images with variable sizes. The 
>solution presented by the author here (malloc a linear array of xsize*ysize) is
>imo the best. Those numerical recipies in C readers who propose the famous 
>array of pointers solution are thinking rather 2d. What if you go to 3d: an 
>image of pointers? Which is of course implemented as an array of pointers to 
>pointers. Good luck!

Yes, an 3d image can be implemented as an 2-d array (not image) of pointers.
And a n-d image as an (n-1)-d array of pointers. No problem! Note that the
overhead involved in space typically is sizeof( any * ), for each row.
And since row sizes typically are >> sizeof(any *), there is no big
problem.

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.
Off course you can use a pointer array, and allocate your image memory
continuous -- this will give you best of to worlds! (at the cost of
setting up your pointer array, which typically is of order columnsize,
instead of order columnsize * rowsize for the full operation. So the
overhead is rather small.)

>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;

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

>Make sure the optimizer is on. Else write register pixel *p and register int i;
Very true! Use highest optimizer option (-O4 on sun compilers, -O2 on gcc).
Check best compiler for best performance! (differences easily can be about
25% !)

>Ben Verwer. Below see a real program (coauthored by Henri Vrooman).

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!


Please correct if i am wrong. This kind of discussions are of help to
everybody!

Klamer

--
Klamer Schutte			Tel: +31-53-892778	Fax: +31-53-340045
Faculty of electrical engineering -- University of Twente, The Netherlands
preferred: klamer@mi.el.utwente.nl     SMTP: klamer@utelmi01.el.utwente.nl
Newsgroups: sci.image.processing
From: mathew@elroy.Jpl.Nasa.Gov (Mathew Yeates)
Subject: Re: WANTED: MAximum entropy C source code
Keywords: maximum entropy source
Organization: Image Analysis Systems Group, JPL
Date: Fri, 14 Aug 1992 05:03:21 GMT

sjreeves@eng.auburn.edu (Stan Reeves) writes:

>In article <8134@sirius.ucs.adelaide.edu.au> snoswell@ucs.adelaide.edu.au (Michael Snoswell) writes:
>>I recently read an article on maximum entropy image processing (S.F
>>Gull and J. Skilling, IEE Proceedings, Vol 131, Pt.F, No. 6, OCTOBER
>>1984) and thought it was something that I could use instead on 2D
>>deconvolution.

>>From: mathew@elroy.jpl.nasa.gov (Mathew Yeates)
>>I have written a Khoros Toolbox which contains several image restoration

There is indeed an implementation of Gulls "intrinsic correlation"
scheme in the toolbox. See "Maximum entropy and Bayesian methods,
Cambridge 1988".

Unfortunately, the rules are changing here regarding the release of
code. I'm going to have to jump through some hoops before I can release
version 0.2 but I'm still hopeful. Since version 0.2 will come with
readymade "workspaces" it will be much easier to use. But since 
you were interested in MaxEnt, version 0.1 might work for you.
It's available in the contrib directory of Khoros.

-Mathew

Newsgroups: sci.image.processing
From: dickw@IASTATE.EDU (Richard Wallingford)
Subject: Re: 1: 1 lens wanted
Reply-To: dickw@IASTATE.EDU (Richard Wallingford)
Organization: Iowa State University
Date: Wed, 12 Aug 1992 14:45:18 GMT

In article <1992Aug11.165800.8441@swift.cs.tcd.ie>, mahonj@swift.cs.tcd.ie
writes:
> Could anyone recommend a lens of about 50 mm focal length
> optimised for 1:1 reproduction ratio ?
> 
> This would be used with a c-mount video camera with an image
> sensor size of 8.8 x 6.6 mm so a wide angle coverage is not
> important.  What is important is the ability to resolve at
> least 10 microns (preferably much better than that).
> 
> I have already considered enlarger lenses, but I really want
> something for 1:1 which is outside their optimal range.
> 
> It should have an iris, and ideally a focus mount, but this
> is not critical.  Any fitting could be used.

I recommend the Sigma line of lenses.  They make lenses fitting
all of the popular mount types (with the exception of c-mount).
You might try the Nikon auto-focus mount since I know that 
Nikon-to-c mounting adaptors exist.  The advantage of Sigma is
that they are cheap and every bit as good as the name brands.

I just bought a 90mm f2.8 macro that goes down to 1:1 with the
included life size adaptor lens.  I believe a 55mm version
exists also.  They are about $200 - $250 depending on where you buy
them.

In any case, be sure to specify that you want 1:1 capability
since many macros only go 2:1 or 4:1.  I've even seen
supposed micro lenses that only go 2:1 (figure that out!!)

As for resolution, on an f2.8 lens, the best resolution will
be at f5.8 or f8.  For a decent lens, this is typically in the
80-100 line pairs/mm range.  If you're imaging at 1:1 your resolution
may be limited by your sensor (i.e. 8.8mm /512 = 17 microns).

--
+--------------------------------------------------------------------+
|Dick Wallingford      | Internet: dickw@iastate.edu                 |
|Center for NDE        | Packet  : wd0anb@n0an.ia.usa.na             |
|Iowa State University | "This river don't go to Aintree" - S.H.     | 
+--------------------------------------------------------------------+
Newsgroups: sci.image.processing