jwb@ksuvax1.cis.ksu.edu (Jeff W. Brogden) (08/10/89)
I posted a similar message earlier, and the response was underwhelming. I
received a total of 2 responses and 2 of them wanted me to forward my
responses to them :-) (i.e. no responses about anyone actually using the
Amiga in a IPS). It was suggested to me that maybe not everyone is
familiar with the term 'image processing'. So, here is a restated request.
I work for U.S. Grain Marketing Research Labs here in Manhattan. We use a
Sun 3/160 and a Kontron IPS system to do some image processing. We
digitize wheat/corn kernals into the computer. Then using some software,
try to determine 1) the kernals area 2) what class the kernal belongs in
based on its a)shape and b)size and c)color 3) cracks, or other
distinguishing(sp?) features that might make some popcorn pop better than
others etc, etc, etc....
The equipment we use is very nice, but VERY expensive (on the order of
$300,000+ I heard somewhere). It occured to me that the Amiga would make a
good platform for an IPS system. It offers multitasking, window, color,
digitizers, genlocks, etc, etc, etc.... Many of the same things our Sun
and Kontron offer. I realize that the Amiga might not be able to give a
high of quality results as the Sun/Kontron, but who knows??? :-) It would
seem to me that the Amiga would be a perfect candidate for a
low-level/budget IPS system.
Question:
Is anyone using the Amiga to digitize images into memory and then
manipulate that image in hopes of getting something useful out of it? Some
of the things I've seen people do (not with Amiga though) are:
Determining the protein level in simulated Pizza crust
Determining the doneness of beef steaks thru color analysis
Determining the quality of popcorn, or what makes good popcorn
pop good
If you are doing anything intresting, let me know by e-mail. Tell me what
your hardware setup is, you startup cost (if you don't mind), what software
you are using, and if your pleased with the results. I will post the
results to the net if the response is good enough.
P.S. Those of you who wanted what I received last time, and want what I
receive this time, send me e-mail again. I lost your addresses. Sorry.
===============================================================================
Jeff Brogden
Internet: jwb@ksuvax1.cis.ksu.edu
BITNET: jwb@ksuvax1.bitnet
UUCP: {rutgers,texbell,atanasoff}!ksuvax1!jwb
===============================================================================chas@gtss.gatech.edu (Charles Cleveland) (08/10/89)
In article <3043@deimos.cis.ksu.edu> jwb@ksuvax1.cis.ksu.edu (Jeff W. Brogden) writes:
)I posted a similar message earlier, and the response was underwhelming. I
) .
) .
) .
)===============================================================================
)Jeff Brogden
)Internet: jwb@ksuvax1.cis.ksu.edu
)BITNET: jwb@ksuvax1.bitnet
)UUCP: {rutgers,texbell,atanasoff}!ksuvax1!jwb
)===============================================================================
Last year at Siggraph I picked up a brochure from some folks out of University
of Lowell. At our Amiga user's group this past Tuesday some stuff from this
year's meeting was passed around and there they were again. The word 'Kernel'
may have appeared in the title, but I'm not sure.
I don't remember the products well enough to describe them, so I was
hoping someone else would speak up first in case my recollections are
completely faulty. I seem to recall that Image Processing was at issue,
that both hardware and software were involved, and that Amiga platforms
were used.
NOW will someone who actually knows what happening at Lowell speak up?
--
"Our vision is to speed up time, eventually eliminating it." -- Alex Schure
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.educmcmanis%pepper@Sun.COM (Chuck McManis) (08/11/89)
I wrote an article for BYTE about using the Amiga as an inexpensive
Image Processing workstation back in March of '88. The response from
the article was mostly "How do I do this on my IBM PC compatible?"
although there were some other good letters, one from a guy in Australia
whose Masters thesis involved using a similar setup (Digiview + A1000)
to look at tooth brushes and reject those that were missing bristles.
The biggest bottleneck was the CPU itself. To run a serious convolution
over a 16 level grey scale image could take you 2 - 3 *hours*. Of course
with an FPU and/or a 32 bit processor you could speed that up considerably.
Some people were even doing fairly wild assembly level stuff that did
all fixed point math. Some really cool stuff is/was going on at ULowell
with Rich Miner. Basically they had built a really whizzy pipelined
Image Processing board that could do Sobels in < 1/30th of a second.
(Took about 30mins to do one with a stock 68000). So the conclusion is
that it is a great box for learning about image processing 'cuz you
can get it inexpensively and you can run all of the classic as well as
you own algorithims on it for doing research. What it isn't good at is
production environments where you need to do things *fast* in which
case you need to throw a little bit more money at the problem and
get an '020 or one of Rich's boards.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"set@xanadu (Scott Townsend) (08/12/89)
I used to work on a contract for a company that builds machine vision systems.
Their box was basically a 256 shade frame grabber driven by a 68000, so it had
similar CPU power to a stock Amiga. They used it for verifying assemblies and
labels. With enough algorithm tricks we were able to get some decent speed
for the problems they were trying to solve: (decent = about 10 parts/sec)
- verify that there are the right number of needles in a needle bearing
- verify the number & location of an assembly's parts
- measure lengths, diameters, angles
- verify a label's orientation and readability (contrast-wise, not hype!)
- other things you can do with binary thresholding and/or edge finding
I did code-up some of the textbook image processing filter algorithms like
3x3 lowpass, 3x3 Sobel, and an arbitrary 3x3 convolution. At 10 MHz (I think)
it did a 3x3 Sobel in under 10 seconds (320x200 resolution) This is pretty
slow, but it was neat to watch.
Anyway, I just wanted to point out that some real-world vision jobs CAN be solved
by something like a stock Amiga, a '020 could help a lot with the instruction
cache, the data cache of a '030 doesn't buy much (with simple minded code
at least)
I should note that the frame buffer for this machine is not bitplane oriented
like the Amiga's graphics. Does anyone know a quick way to go from bit-plane
oriented to pixel oriented graphics data? I'd like to play around at home on
IFF images, but just doing a slew of ReadPixel() calls is awfully slow.
(If that isn't clear, I'll try a different explanation: the Amiga stores all
bit 0's next to each other in one plane, then all bit 1's, etc. For image
processing, you prefer all pixel value bits in one byte -- well, that's not
too clear either, sorry)
When I first looked at the blitter's abilities to do a full-adder in two
blits I thought I could use it for all sorts of image stuff, but you run
out of chip memory way too soon! (at least on my "stock" 1000)
-----------------------------------------------------------------------------
Scott Townsend ...!{cwjcc,decvax,pyramid,uunet}!abvax!set
Polymath Corporation, currently working for (but not representing)
Allen-Bradley Company 747 Alpha Dr. Highland Hts. OH 44143 USA (216) 646-5233portuesi@tweezers.esd.sgi.com (Michael Portuesi) (08/16/89)
In article <822@abvax.UUCP> set@xanadu (Scott Townsend) writes:
Does anyone know a quick way to go from bit-plane
oriented to pixel oriented graphics data? I'd like to play around at home on
IFF images, but just doing a slew of ReadPixel() calls is awfully slow.
(If that isn't clear, I'll try a different explanation: the Amiga stores all
bit 0's next to each other in one plane, then all bit 1's, etc. For image
processing, you prefer all pixel value bits in one byte -- well, that's not
too clear either, sorry)
I think what you're trying to say is that because the Amiga has a
bit-plane architecture, the data for each pixel can be stored in up to
six different memory addresses (the maximum number of bit planes the
Amiga chipset can currently display). Thus, getting a single pixel
(the most common operation in image processing algorithms) from the
display can take up to six memory accesses on the Amiga.
As somebody else pointed out, high-end graphics hardware often has
some provision so that a pixel in a bit-plane oriented display may be
grabbed in one operation. In fact, a recent issue of the _Amiga
Transactor_ contained a proposal for a revision of the Amiga display
hardware to provide this feature.
Anyway, it should be possible to achieve some of the savings of having
pixel-packed data on the Amiga by maintaining a pixel-packed copy of
the image in a memory buffer, and using that for performing image
transformations. The result could be mapped back into bitplanes for
screen display.
The disadvantages of this approach are that it would cost much CPU to
convert an entire image from bit-plane to pixel-packed and vice-versa,
and each image would require twice as much memory (or more, depending
on your implementation) for processing. On the plus side, this
approach would be a big win for image filters which must access each
pixel in the image more than once. And if you are processing an image
with more color bandwidth than the hardware can display (such as an
8-bit monochrome or 24-bit color image), you have to keep a separate
buffer and use CPU cycles to downconvert the image for display anyway.
Finally, it may be possible to use the blitter chip to convert an
image from bit-plane to pixel-packed orientation very quickly. The
disadvantage of this approach is that both versions of the image would
be forced to reside in CHIP memory in order for the blitter to convert
between them. Designing blitter algorithms is not my specialty, so
I'll leave the dirty work to someone else.
--M
--
Michael Portuesi Silicon Graphics Computer Systems, Inc.
portuesi@SGI.COM