HDTenEightyP/NetNews huggingface dataset:
From: dubuf@sicsun.epfl.ch (Hans DU BUF)
Newsgroups: sci.image.processing
Subject: Re: '386 VGA Software for Greyscale manip needed
Date: 21 Aug 92 11:00:30 GMT
Organization: Ecole Polytechnique Federale de Lausanne

In article <1992Aug20.211721.13487@kakwa.ucs.ualberta.ca>, nadine@solstice.ucs.ualberta.ca (Nadine Leenders) writes:
|> Is there any low-cost software available for a '386 PC with VGA
|> that will take two grey-scale images, display one in red, the
|> other in green, except in areas of overlap where the resulting
|> colour is to be yellow?

I don't quite understand your problem.
Just displaying in VGA mode can be done by doing BIOS interrupts,
for example one to change the lookup table and one to display a
pixel. Displaying pixel by pixel is very slow but easy, because
you need only a very small assembly routine to which the data is
passed (from fortran eg) and which puts the data in specific registers
before doing the interrupt.
This is standard and well documented (BIOS calls, registers, codes).

When you are not familiar with this you might look for a local guru.
SuperVGA programming is not very difficult but requires some insight
into lookup table storage and writing an entire image directly in
SVGA memory, plus exact knowledge of SVGA registers.
I developed my own assembly routines which I link with MS fortran
programs. I can display an image in a fraction of a second, fill or
scroll lookup tables in vertical retrace time, etc.
But I am using a ET3000 SVGA, only 256x256 images, and did not develop
a generally applicable software package that can be used on any system.
It's just a hobby package with too much tricks (and traps)...

Look for this book:
G. Sutty and S. Blair
Advanced programmer's guide to SuperVGAs
Brady, New York, 1990

Comes with a floppy with lots of examples for different SVGA boards
and with standard C interfacing. I changed it to fortran interface
and used some other instructions, for example the 'rep outsb' from
the 186 set.

Hope this helps
Hans
Xref: sparky sci.image.processing:447 comp.compression:3011
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: sci.image.processing,comp.compression
Subject: Re: Compressing halftone images
Date: 14 Aug 92 15:57:10 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY


  The only useful thing I've found with halftone is to convert with an
algorithm to greyscale, then JPEG them. Lossy as hell, but they are
small and look good.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: sci.image.processing
From: gahm@tnt.uni-hannover.de (Thomas Gahm)
Subject: Re: Image Processing Packages
Summary: Summary: Colour camera for fluorescence microscopy
Keywords: Summary, colour camera, fluorescence microscopy
Reply-To: gahm@tnt.uni-hannover.de
Organization: Universitaet Hannover, Theoretische Nachrichtentechnik
Date: Fri, 14 Aug 1992 08:38:25 GMT


Here is the promised summary of all the email replys I got (and there were
quite a lot --- many thanks to all the contributors !) on my request
for information about a highly sensitive colour video camera for fluorescence
microscopy.

The whole information can be boiled down to three camera brands:

   - Optronics:  non-cooled camera
                 1 Chip RGB video camera with filter mosaic
                 variable integration time (>5sec)
                 SONY Hyperhad Chip
                 ~ US$ 7.500
                 sensitivity >0.5 lux
                 US Optronics distributer

                 (I am going to have this camera tested, so if anybody is
                  interested in the results, please let me know)


   - SONY:       DXC-930P
                 3 Chip RGB video camera 
                 752(H) x 582 (V)
                 variable integration time (<8sec)
                 ~ DM 10.000 (--> ca US$ 7.000)
                 SONY distributer
                 
                 I was assured by people experimenting with this camera
                 that it could be sensitive enough for fluorescence applications.
                 As the camera head is very small it should also be possible
                 to fit a Peltier cooling device enhancing the sensitivity in
                 that way.


   - Kappa:      CF 15/2
                 1 Chip RGB video camera with filter mosaic
                 460 (H) x 582 (V)
                 Peltier-cooled system
                 sensitivity ~ 0.5 lux
                 ~ DM 17.700 (--> ca US$ 12.000)
                 Tel: 05592 303
                 Fax: 05592 1726, Germany 


There were also a lot of suggestions about high sensitive black and white video
cameras (e.g. Photometrics, Hamamatsu, Kappa, ...). Nearly every company 
producing video cameras has nowadays also a high sensitive device by either
cooling it (Peltier or nitrogen cooling) or using high integration times or
both or adding an intensifier module.  The special interest of this enquiry, 
however, was on colour cameras. 
 

Thomas           

______________________________________________________________________________________

Dr. Thomas Gahm                           Tel.: 0049 511 762 5320
                                          Fax.: 0049 511 762 5333

                                          email: gahm@tnt.uni-hannover.de
Newsgroups: sci.image.processing
From: rap2@vuse.vanderbilt.edu (Alan Peters)
Subject: Binary morphology with morph
Followup-To: sci.image.processing
Summary: How to use one-bit rasterfiles with morph.
Keywords: morph software, mathematical morphology, Sun rasterfiles
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: Thu, 20 Aug 1992 15:58:31 GMT

Linh Huynh worte to me as follows:

	It seems all binary operations do not work on binary images.
	For example I tried to erode binary image called ccitt-1.ras  using 
	this command

		berode < ccitt-1.ras > out.ras plus

	It reports:
	GetRasHeader: Input image must be 8 bits/pixel
	This one is 1 bits/pixels

This person's email address bounces back at my mailer daemon so I am
replying here. (Moreover, others have probably experienced the same
problem with my morph software.)



My programs operate only on 8-bit rasterfiles. Of course, the programs
would be better without that restriction. It should not be terribly
difficult to modify the routine ReadRasterFile in morph/utils/rasterio.c
to read 1-bit rasterfiles. In the meantime you can use pbmplus, zcat,
and compress in conjunction with the binary morph operators to do what
you want as follows:

	zcat ccitt-1.ras.Z | rasttopnm | pnmdepth 255 | pnmtorast -standard \
         | berode plus | rasttopnm | pgmtopbm | pnmtorast -standard \
         | compress -c > ccitt-1-erode.ras.Z

The "\"'s simply escape carriage returns.

I have tried this with the ccitt image and it works.

Be aware that you need a lot of memory to do this since the ccitt-N.ras.Z
images are very large.

Let me know if you have any other problems.

Alan Peters


-- 
Newsgroups: sci.image.processing,rec.photo,rec.video
From: alien@essex.ac.uk ("Adrian F Clark")
Newsgroups: sci.image.processing
Subject: Re: WANTED: MAximum entropy C source code
Date: 13 Aug 92 11:18:17 GMT
Organization: University of Essex, UK
In-reply-to: hanisch@stsci.edu's message of 12 Aug 92 15:31:10 GMT

In article <1992Aug12.153110.15062@stsci.edu> hanisch@stsci.edu (Bob Hanisch,N406,4910) writes:

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

While MEM -- and particularly the MEDC package -- seems to be pretty
effective for astronomical imagery, I'd like to raise a small word of
warning regarding MEM for general restoration applications.  MEM works
by taking a uniform image and `pulling' non-uniformities out of it
only where there is statistical evidence for doing so.  Unfortunately,
the staistical models used by all the implementations of MEM that I've
seen only work well for pulling bright regions from a dark
backgrouond.  Given a image with the opposite contract (e.g., a
bright-field electron micrograph) I've yet to see a good job.

If anyone can:

   - take an image
   - work out the MEM restoration
   - invert the contrast of the image
   - work out the MEM reconstruction of the contrast-inverted image
   - invert the contrast of this reconstruction

and get similar results I, for one, would be most interested!

--
 Dr Adrian F. Clark                                   JANET: alien@uk.ac.essex
 INTERNET: alien%uk.ac.essex@nsfnet-relay.ac.uk          FAX: (+44) 206-872900
 BITNET: alien%uk.ac.essex@ac.uk              PHONE: (+44) 206-872432 (direct)
 Dept ESE, University of Essex, Wivenhoe Park, Colchester, Essex, C04 3SQ, UK.
Newsgroups: sci.image.processing,comp.graphics
From: IMAGING.CLUB@OFFICE.WANG.COM ("Imaging Club")
Subject: Art gallery image processing
Organization: Mail to News Gateway at Wang Labs
Date: 18 Aug 92 12:35:31 EST

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: IMAGING.CLUB@OFFICE.WANG.COM ("Imaging Club")
Newsgroups: sci.image.processing
Subject: Wang document-imaging strategy interview
Date: 19 Aug 92 17:37:10 GMT
Organization: Mail to News Gateway at Wang Labs

If anyone would like a copy of that Advanced Imaging interview
this month with Wang Marketing VP David Goulden on the Wang
document-imaging strategy, please let me know.


----------------------Michael.Willett@OFFICE.Wang.com-------------
Newsgroups: sci.image.processing
From: raveling@Unify.com (Paul Raveling)
Subject: Re: image processing loops: a c programming
Organization: Unify Corporation (Sacramento)
Date: Fri, 14 Aug 92 20:08:12 GMT

In article <1992Aug13.125001.25563@bmw.mayo.edu>, agl@mayo.edu (Al Larson, 1-159 Med Sci, 4-4147) writes:
> In article 92Aug13120523@vulcan.essex.ac.uk, alien@essex.ac.uk ("Adrian F Clark") writes:
> >
> >In article <1992Aug10.221247.8016@cfa.harvard.edu> alberto@cfa.harvard.edu (Alberto Accomazzi) writes:
> >
> >
> >  dp = data;
> >  for (y = 0; y < ysize; y++)
> >    for (x = 0; x < xsize; x++)
> >      *dp++ = ...
> 
> ... If its speed your after, and who isn't.
> 
> dp = data;
> xy = ysize*xsize;
> while(xy--) *dp++ = ...

	That was true on some piece of gear that I benchmarked
	in the past -- maybe a 68K-based workstation -- but it pays
	to check your particular hardware & software.  On a Sun IPC
	tests based on the two code fragments below produced the
	results shown on the right in three trials (1 million iterations
	each of 3 similar loops):...

				Using cc:
i = MAX;			1.6u 0.4s 0:02 95% 0+1368k 0+0io 0pf+0w
while ( i-- )			1.6u 0.4s 0:02 95% 0+1368k 0+0io 0pf+0w
    *bp++ = *ap++;		1.6u 0.4s 0:02 96% 0+1376k 0+0io 0pf+0w

				Using gcc:
				1.5u 0.4s 0:01 101% 0+1400k 0+0io 0pf+0w
				1.4u 0.4s 0:01 98% 0+1400k 0+0io 0pf+0w
				1.4u 0.4s 0:01 100% 0+1400k 0+0io 0pf+0w

				Using cc:
for ( i=0; i < MAX; ++i )	1.3u 0.5s 0:02 76% 0+1340k 0+0io 10pf+0w
    *bp++ = *ap++;		1.2u 0.4s 0:01 100% 0+1316k 0+0io 0pf+0
				1.3u 0.4s 0:01 98% 0+1320k 0+0io 0pf+0w

				Using gcc:
				1.5u 0.5s 0:02 79% 0+1404k 0+0io 3pf+0w
				1.4u 0.4s 0:01 100% 0+1396k 0+0io 0pf+0w
				1.4u 0.5s 0:02 95% 0+1384k 0+0io 0pf+0w

	So finding the absolute optimum even on a single piece of
	hardware is an exercise in exploring both code and compiler.
	Allowing the compiler to change between versions, and adding
	the variable of different types of hardware, and it's not
	very practical to look for an absolutely optimal choice.


------------------
Paul Raveling
Raveling@Unify.com
From: page@nosc.mil (Ward C. Page)
Newsgroups: sci.image.processing
Subject: Re: image processing loops: a c programming question
Date: 20 Aug 92 19:07:17 GMT
Followup-To: page@cod.nosc.mil
Distribution: sci.image.processing
Organization: Naval Ocean Systems Center, San Diego

In article <stefang.714225838@isy> stefang@isy.liu.se (Stefan Gustavson) writes:
>
>I recently wrote a convolution routine with only pointer indirection
>and addition for addressing and no sissy extra loop increment variables.
>Incomprehensible but fast. It _does_ make a difference.
>No hard feelings - just getting things straight.


Please post this code.  It would be very useful.


Ward Page
NCCOSC RDT&E
San Diego, CA
page@cod.nosc.mil

-- 
Ward Page
Naval Ocean Systems Center
San Diego, CA
page@cod.nosc.mil
Newsgroups: sci.image.processing
From: singer@ll.mit.edu (Matthew R. Singer)
Subject: Blobs....
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Date: Thu, 20 Aug 92 14:56:56 GMT


--
Can anyone suggest better ways....

I have an application what is looking at a 64x64 pixel image of space objects
(starts, satellites, junk...etc)...  I need to be able to associate pixels
that are above a given threshold into a probable object so that I can point
a telescope at them.  Currently, the method is to just take pixels that have
no "off" pixels between them and call them an object.  Several alternatives
are:

Scanning the image with a quad-cell centroid seeing when thing come above
a given power and error level.

Looking at local maxima...

Any other reasonable alternatives that can be done with a small amount of
compute?


-----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
-----------------------------------------------------------------------------
From: dubuf@sicsun.epfl.ch (Hans DU BUF)
Newsgroups: sci.image.processing
Subject: PhD student position available
Keywords: see above
Date: 18 Aug 92 14:14:14 GMT
Organization: Ecole Polytechnique Federale de Lausanne


OPENING FOR A PhD STUDENT IN IMAGE PROCESSING
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I have an opening for a PhD student, starting 1st of October, for 2
years now but with the possibility of a prolongation, probably to 4
years in total. The project is funded by the Swiss National Science 
Foundation. The subject concerns the development of a multiscale image
analysis system which produces a syntactical/geometrical representation
allowing for a very precise image resynthesis. Keywords are: scale space,
2D quadrature filtering, phase responses, line/edge/vertex detection,
response interferences, ambiguities, and context processing.

The candidate *must* have followed courses in signal and image processing,
and preferably done his master's project in this domain. Some insight into
visual psychophysics and/or visual neurophysiology wouldn't be bad.
Programming: FORTRAN is a pro, C not per se, maybe some experience with
LATEX, MATHEMATICA, or MATLAB. UNIX of course.

The starting salary is about 60K SwissFR per annum, which makes somewhat
less than 4K (3750, say) net per month, depending on age.

The Signal Processing Laboratory of the Swiss Federal Institute of Tech-
nology is well equipped with powerful workstations, quite some software
packages, and for the heavy jobs we have our CRAY-2 and Y-MP on campus.
There is not a real campus because we lack student lodging (all students
and up live in Lausanne and nearby villages). Lausanne is situated at what
is called the Swiss Riviera, with a view on the Geneva lake and the French
alps. See your nearby tourist office for more details. One important
detail: Lausanne is located in the French-speaking part of Switzerland.
The language in the lab is English because of the many nationalities, but
we advise taking French courses which are provided by the Institute.

Send your resume and possible questions as soon as possible by snail mail,
please NOT by email because I will be off to two conferences, to:

Dr. J. du Buf
Signal Processing Laboratory
Swiss federal Institute of Technology
EPFL-Ecublens
CH-1015 Lausanne
Switzerland

If possible, provide an email address and/or fax number!
Newsgroups: sci.image.processing,rec.photo
From: ka1gt@cbnewsm.cb.att.com (robert.m.atkins)
Subject: Re: 1: 1 lens wanted
Organization: AT&T
Distribution: na
Date: Wed, 12 Aug 1992 22:51:21 GMT
Followup-To: rec.photo

In article <1992Aug12.094518@IASTATE.EDU>, dickw@IASTATE.EDU (Richard Wallingford) writes:
> 
> 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).
> 

The aerial resolution (i.e. lines/mm in the focal plane (surface) of the
lens) should be much more than 80-100 lp/mm for any reasonable lens. The
80-100 lp/mm figure is for the lens+film combination, where the film is
always a limiting factor. A halfway decent lens at f8 should resolve 
around 200 lp/mm (depending on your definition of "resolve"). Resolution
would drop to 100 lp/mm somewhere between f11 and f16.

===============================================================
Bob Atkins  AT&T Bell Labs  email (direct)  att!clockwise!rma
===============================================================

Newsgroups: sci.image.processing
From: agl@mayo.edu (Al Larson, 1-159 Med Sci, 4-4147)
Subject: Re: image processing loops: a c programming
Reply-To: agl@mayo.edu
Organization: Mayo Foundation
Date: Thu, 13 Aug 92 12:50:01 GMT

In article 92Aug13120523@vulcan.essex.ac.uk, alien@essex.ac.uk ("Adrian F Clark") writes:
>
>In article <1992Aug10.221247.8016@cfa.harvard.edu> alberto@cfa.harvard.edu (Alberto Accomazzi) writes:
>
>> A far as making the loop tight and fast, if you are only accessing your data
>> in a sequential way, the best thing to do is increment the pointer as in:
>> 
>> function (DATATYPE *data, int xsize, int ysize)
>> {
>>   int x, y;
>>   DATATYPE *dp;
>> 
>>   dp = data;
>>   for (y = 0; y < ysize; y++)
>>     for (x = 0; x < xsize; x++, dp++)
>>       *dp = ...
>> }
>> 
>> Inner loops can be written in a similar fashion.  As far as I know, this
>> will be as fast as you can get.
>
>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.
>
>

If you compared assembler output, I am pretty sure the code would look
identical for both the above cases. If its speed your after, and who isn't.

dp = data;
xy = ysize*xsize;
while(xy--) *dp++ = ...

==============================================================
Al Larson                      Internet:   agl@mayo.edu
Biomedical Imaging Resource      
Mayo Foundation                Talk:       (507)-284-4147
Rochester, MN 55905            FAX:        (507)-284-1632
===============================================================

Newsgroups: sci.image.processing,rec.photo
From: awpaeth@watpix.uwaterloo.ca (Alan Wm Paeth)
Subject: Re: 1: 1 lens wanted
Organization: University of Waterloo
Date: Thu, 13 Aug 1992 01:08:56 GMT

>In <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 ?

Another approach -- buy a double-threaded 49mm (or 55mm or whatever) filter
ring and attach two 50mm SLR lenses "head to head". This produces a symmetric
1:1 system that relays very flat, colour corrected image (24mm by 36mm format)
onto the film plane. Such rings are made for this purpose -- they are NOT the
same as reversing rings. Conventional C-mount or T-mount plumbing then puts
the assembly on the video camera or SLR body.

I would go with fast "prime" optics but would avoid using a superfast (f/1.2)
aspheric objective. The slower stock 50mm lenses are increasingly easy to buy
at camera shops -- many 35mm SLR buyers now opt for bodies only (so I guess
they are "non-objective buyers" :-) ) and then add a zoom as their first lens.

   /Alan Paeth
   VE3AWP/KD3XG
Newsgroups: sci.image.processing
From: mathew@elroy.Jpl.Nasa.Gov (Mathew Yeates)
Subject: Re: Hoping to find some morphology software
Organization: Image Analysis Systems Group, JPL
Distribution: world,local
Date: Fri, 14 Aug 1992 05:14:11 GMT

CHAMBERS@hacks.arizona.edu (Jeremy Chambers) writes:

>> I'm writing this on behalf of somebody who iisn't email or USENET-oriented
>> yet, but is in search of some morphology software.  He is looking for
>> something that will do form recognition and morphological analysis.

>... stuff deleted

>Since you're located in Canada, try this company:

Why not Khoros? It comes with bunches and bunches of morphology
routines as part of it's standard distribution.

-Mathew
From: M.L.Cook3@lut.ac.uk (Vaxaholics Anonymous)
Newsgroups: sci.image.processing
Subject: TIFF? file format
Date: 12 Aug 92 14:53:32 GMT
Reply-To: M.L.Cook3@lut.ac.uk (Vaxaholics Anonymous)
Organization: Loughborough University, UK.

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

Bye for now,


    /|  /|   __    ___  _/_  ~ ___       JANET:    M.L.COOK3@UK.AC.LUT    
  /  |/  |  / |   /    /   /  /  /       Internet: M.L.COOK3@LUT.AC.UK
/        | (__(_ (    (_  (  (  (.       Phone:    -
------------------------------------------------------------------------------
    Martin Cook, Department of Computer Studies, Loughborough University of
      Technology, Loughborough, Leicestershire, LE11 3HT, United Kingdom.
------------------------------------------------------------------------------