From: huff@mcclb0.med.nyu.edu (Edward J. Huff)
Newsgroups: news.groups
Subject: Re: RFD for new IMAGE PROCESSING newsgroup
Date: 11 Apr 92 04:01:33 GMT
Organization: NYU Chemistry Dept

I expect that there will be an official RFD arriving for this group
soon.  Since discussion is already under way, here is my opinion.

There were a couple of negative comments about this idea today, suggesting
that comp.graphics and comp.graphics.visualization would be suitable
forums.  See below.

I also point out that various replies to my queries have suggested
comp.ai.vision, which is mainly a gateway for VISION-L digest.
This is not so far off the mark, but many areas of image processing
are not related to artificial intelligence or even computer vision.
More below.

There is also comp.soft-sys.khoros, which has me seriously considering
obtaining a Unix box in order to use the package discussed there.  But
it is about that one package, and not much image processing is discussed.

And there is comp.dsp, mostly about sound processing, although you can
use digital signal processors to do image processing.

My remarks about today's postings:

>Please consider reading the "List of Active Newsgroups" in
>news.announce.newusers before you attempt to reinvent the wheel:

>comp.graphics           Computer graphics, art, animation, image processing.
>Ellen Keyne Seebacher            elle@midway.uchicago.edu

There is too much traffic in comp.graphics.  I don't want to have to read
so much.  Most of it is completely irrelevant to what I want from
an image processing newsgroup.  I don't care about 3D rendering.
I looked at comp.graphics just now, and out of over 100 postings, there
were only 2 or 3 of interest to me.  Yes, my newsreader does display
the subject lines, but I still have to read them to decide if they
are relevant.  The poster knew, and if there were an IP newsgroup,
he would post or crosspost there only if the article is about image
processing.  I wouldn't have to guess from the subject line.

There was one very interesting article, from mccreary@sword.eng.hou.compaq.com 
(Ed McCreary).  Thanks.  I saved it.  But I wouldn't have even read it
if I wasn't researching this post.

I'm not the only one who thinks comp.graphics is too big:

>[from a post on comp.graphics about the references server:]
>Questions?  Email me as I don't have time to read this group anymore.
>--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov

Please don't bother him on my account...


The other negative comment today:

>What's wrong with comp.graphics.visualization?  Isn't it pretty similar
>to what's been defined for Image Processing?

>Tim Eckert

Scientific visualization is a different subject from image processing.
You do different things, the questions are different.  Often, with
visualization, you start with numbers and want to synthesize images,
while with image processing, you start with images and want to get numbers.
(Not always...).

Here are some excerpts from the "what is it?" thread in that newsgroup:

(These quotes were not written for the discussion of an image processing
newsgroup, but on a slightly different slant.  Please keep that in mind).

[...]
>I think it is more than just advanced computer graphics.  It also
>involves being able to visually represent data in ways that make
>sense and perhaps in ways that will enhance it's meaning.
>It also involves manipulation of the data to enhamce understanding.
>A good example of this is protein folding.  In many cases it is not
>known how a protein is folded even though you know what makes up the
>protein.  So you visualize the protein and play a whatif game and see
>the results.  Much better than drawing on paper all the possibilities.
>[...]
>--king@presto.ig.com

Image processing is different from this.  The images are scientific data,
and often, you calculate answers from the images.  They aren't necessarily
intended to look at, but rather, to count objects, or measure lengths, etc.
Admittedly, I would be interested actually in comp.graphics.ip.microscopy,
but just separating image processing from graphics would be a big help.

>As far as visualization is concerned, it has nothing to do with computers
>or graphics.  For example, a plastic model of a molecule is a visual
>representation of that molecule (no computers needed there).  I think
>the reason graphics and visualization are so tightly interwoven is that
>it is usually cheaper to draw it on a computer than build a physical
>model.  Also, some physical models cannot be build (as in visualizing
>relativity).
>--dallen@eng.auburn.edu (David J. Allen)

Again, image processing is more like taking a plastic model and measuring it
than taking the numbers and building the model.


>Something is missing in the definition of visualization that is developing in
>this thread. I do agree that visualization really has little to do with 
>graphics. Visualization should be thought of as a tool that facilitates the 
>interpretation of scientific data. The operative word is data. Much of what
>goes on in visualization is data processing and manipulation rather than 
>graphics or IMHO should be. 

>Scientific data pass through several levels of interpretation. 

>Raw/Sensor data : raw values obtained directly from the measurement device

>Calibrated data: raw physical values, corrected with calibration operators

>Validated data: Calibrated data that has been filtered through quality 
>	assurance procedures( visual techniques could be used here)

>Derived data: frequently aggregated data, such as gridded or averaged data

>Interpreted data: derived data that is related to other datasets (most graphics
>	goes on here but there still is quite a bit of data processing here) 

>I submit that if a visualiztion environment claims to facilitate the
>interpretation of scientific data then it should support all of the above
>operations as well as the final yard, rendering the data.

>My point is that any definition of scientific visualization should include
>the data processing requirements. This is where visualization differs from
>graphics. 

> -ethan alpert [(alpert@alumni.cs.colorado.edu)]

Image processing applies in cases where the sensor produces an image,
so that the raw data is an image.  Only in those cases where you want
to visualize this image (not in my case) would the discussion belong
in comp.graphics.visualization.  (Alpert's remarks about inclusion were
directed toward what belongs in a full featured software package, not 
what belongs in the newsgroup.)

Back to comp.ai.vision.  This looks like a gateway for VISION-L, which
is a mailing list that posts numbered summaries.  Today I just saved
VISION-LIST digest 11.12, and I have previously saved a few earlier issues.

Computer vision seems to be concerned more with the special case of
image processing where the image is from "the real world" rather than
from a scientific instrument like a microscope.  The questions relate
to reconstructing the 3D shape from a 2D image, etc., the sort of things
that happen in human or animal vision.  

--
Edward J. Huff   huff@mcclb0.med.nyu.edu   (212)998-8465
Keck Laboratory for Biomolecular Imaging
NYU Chemistry Deptartment, 31 Washington Place, New York NY 10003