Re: Common and uncommon goals and software

[hjohnson@pluto.njcc.com (Herbert R Johnson)]

On Fri, 3 Nov 2000 18:09:35 -0700 , "Creager, Robert S" <CreagRS@LOUISVILLE.STORTEK.COM> wrote:
*>
*>>      
*>>        - in what language would it be written?
*>>        - under what platforms would it run?
*>>        - what sort of graphics would it support?
*>>
*>Well, your getting my point, but then going beyond it (I think).
*>.....  This software crunches data automatically once set up
*>correctly.  Visualization would be done on the data generated with
*>pre-existing packages.  If the code is kept conceptually simple, the porting
*>won't be difficult between platforms.

I think there is disagrement among TASS members about the "concepts"
themselves in our data reduction. There is legitimate differences between
various methods of accessing point-spread functions, of methods
of matching to star catalogs, of determination of magnitude limits, and
other considerations of any image-processing package. These were issues
with the Mark III, and they were discussed at length at the time. It
took TWO RUNS of the raw data (using seperate pipelines) to get a
consensus that the results were acceptable. And Michael Richmond took
two runs at his TenXcat catalog, and he is not completely satisfied with
those results. Check Tech Notes #57 for my review of the Mark III processing,
and Richmond's TenXCat Tech Note for his processing efforts. Other
Tech NOtes are informative reviews of Mark III results.

In the end, the methods in the code MUST be defenseable by those who produce
the data. Use in publication, or use by others in the field, depend on
strong knowledge and confirmation of those methods. Beyond that are
issues of ease of use and graphical presentation. While ease is not as
critical as the methodology, it contributes to whether a person will
select the software.

*>Here's were some idealism and lack of specific knowledge comes in.  If we
*>have algorithms which detect stars, match them against lists and
*>appropriately scale and such, why couldn't they be run on Joe's data for the
*>purpose of advancing our desired database?  He may not want to use the data
*>generated, but since Podunk U has idle computing machines, he doesn't mind
*>crunching data to help our cause.

Not all "detect stars" algorithms are created equal. Andrew Bennett has
said this over and over again. It's not an arguement that can be resolved,
because (I might suggest) Andrew wants to evaluate more stars per image
than some other methods in use or as suggested - notibly saturated-image
stars. Also, I believe he has suggested his methods would improve astrometry.

One problem in evaluating conflicting methods for Mark IV data, is that
Mark IV data has evolved in quality over the last few years. Andrew's
methods had some advantages when we had comatic images; now that images are
not comatic, fixed aperture methods - a "conceptually simple" method compared
to an adaptive aperture - will be adequate (for many anyway). My apologies
to Andrew if I've not represented his points well, but my point is not
to delineate the differences in methodology among TASS members but simply
to underscore it can be *signifigant*. Those differences are not easily
resolved and are NEVER eliminated.

*>I'm not proposing a package which does everything for everyone, just the
*>ability to do the same thing to all the data in a manner which would benefit
*>a goal which requires having lots of observational data.  Like Tom's
*>variable star database, or something else.
*>
*>Cheers,
*>Rob

Seems to me that, to do as Rob suggests, there are two options.

1) Make it VERY EASY for one or more sites to offer raw data - or star lists -
to someone who would run this "package" of his suggestion, and which
would generate some results. That means excellent raw image data compression
as Tom will point out the tedium of creating many CD-ROMS a night of data
PLUS sending copies out. This is not a very viable option, until writable
DVD's are fast, cheap, and reliable. (Among engineers we regard those
criteria as "choose any two".) So this option probably means the distribution
of star lists in the near term.

or

2) Make it EASY for one or more sites to install and run this data reduction
"package" on raw images, which would generate more compact data that could be
easily sent to a central site for results. If such a package were, quite
frankly, not a pain to install or tedious to operate, a site may be
convinced to operate it and to send off the results.

But in either case, one or more people will have THEIR idea of what the
goal is, and what methods will be used to reduce the data to achieve that
goal. Seems to me this is ALREADY the present situation: different people,
different goals, different methods. We are back to square one with respect
to the "consensus" Rob initially proposed. Meanwhile, before I could
read a day's discussion of his "consensus" comments, the discussion has
shifted to at least a consensus on a feature of my point #1, namely
some standards for the star lists so they can be more easily processed
in a reliable, defendable way.

Again, my Tech NOte #57 quotes some discussion
in the case of Mark III as to how processing criteria for THAT raw data.
It should be informative on  similar criteria for Mark IV image processing.
That is why I wrote it, so we could remember our past history as a guide
for future development.

Herb Johnson


Herbert R. Johnson              http://pluto.njcc.com/~hjohnson
hjohnson@pluto.njcc.com         voice 609-771-1503, New Jersey USA
             amateur astronomer and astro-tour guide
           S-100 computer parts, manuals as "Dr. S-100"
    reseller of 68K Macs & accessories for your computing pleasure