Glenn Gombert
ggombert@infinet.com
Mar 1, 1997
I am getting some differences in the image-scales that I have been calculating for some of Tom's Images that are somewhat differnet than those that Michael got when he put togther his TASS Technical Note. I was wondering if anyone had tried to measure these? I am especially interested in this since it directly affects the accuracy of my Astrometic calculation.
The centroiding algorithm that I am using gives better than 1 arcsecond resolution when used on digitized POSS data so I am sure that it is fairly accurate.
Arne Henden
aah@nofs.navy.mil
Mar 1, 1997
Glenn G. wrote about image scale calculations. I did an independent measure in my astrometric note, and got 13.73 arcsec/mm on average.
Which POSS digitized data are you referring to when you quote 1arcsec resolution? And what do you mean by 'resolution'? How are you measuring the accuracy of the centroid? Actually, 1arcsec accuracy for centroiding the POSS plates, if you are working from the original plate material, is not as good as the professional groups are getting. For instance, the PMM is quoting 200mas astrometric accuracy over the entire sky, including all of the bending and optical distortion corrections, and local accuracies higher than this. However, we are probably comparing apples and oranges here! Note that photographic plates DO NOT have gaussian-shaped images as they are inherently non-linear. The PMM uses a Fermi-Dirac function for its fitting.
If you want to test your centroiding, get a series of TASS images of the same region of the sky on different days and test the repeatability of a frame of isolated stars within a section about 3 degrees square. I'm sure someone has already done this, and so please accept apologies if I haven't read the proper emails!
Arne Henden
aah@nofs.navy.mil
Mar 1, 1997
Chris replied to Tom's request regarding file naming conventions. I'm glad someone had the courage to attack the problem and open themselves up to flak!
My strong preference is to continue with the DOS/ISO9660 8.3 filenames. You have to match the lowest common denominator. Chris has done so.
I would prefer that, in any naming convention, the date is contained in the leading characters. This makes sorting and directory listings easier.
TM3GET has a unique idea in using a modified Julian Date in the file name. This saves space, as a 4-digit day number is valid for nearly 30 years! It is a little harder for a human to identify, so my preference is, if enough characters are available, to use the yymmdd format.
Chris suggested using common 3-character extensions like TXT and FTS for the files. If you are compressing a lot of information into the file name, it doesn't seem sensible to be extravagent in the extension and waste characters.
Therefore, here is another suggested naming convention.
yymmddxy.mnn yy year - 1900 mm month dd day x site a-z y filetype a-z m camera 0,1,2 nn sequential file number for that cameraNote that yymmdd could be replaced with jjjj (modified Julian Date ala tm3get), leaving an extra 2 characters that could be reserved at this time.
After flatfielding, I do not see further processing of the FITS frames. All steps following extraction will have astrometry tied to them, so I see no need to keep individual extractions separate; rather, a single star list for a given camera for a given night should be made.
So maybe another file format would be:
jjjjxmnn.ccc jjjj modified julian date x site m camera nn sequential file number (set to 00 for starlists) ccc file type.
Now the file type can be a squandering of 3 characters as suggested by Chris, with perhaps RAW for the raw fits, and RED for the flatfielded fits, and some other extensions for other filetypes.
Chris suggested a 3-digit julian date, which won't work as that only gives you 1000 days before rollover (and it depends on what day you start as to when the rollover occurs).
Just some mutterings. I've been shovelling too much snow lately and I'm afraid my brain has shut down...
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 1, 1997
Chris Albertson wrote:
> One thing to watch out for is that you will be running two programs, > your rsh'ed temperature monitor, and the tm3get11 program. both will > be accessing the same hardware. This is a clasic problem in > computer science. You need some scheeme to insure that this does > not cause problems. Believe me with no such scheeme you will have > problems. (one program sets a register a millisecond before > the next one re-sets it) One easy way is for the highest priority > process (tm3get11) to toggel a flag that controls access by the second > process.It gets simpler than that. tm3get11 is not running when I do a rsh to monitor tass. After enough time has elapsed, I stop issuing rsh to monitor, and issue a three rsh:
Now as far as I understand the configuration (and we have not tested this), TM3GET11 will be running to completion before windows 95 comes back up. There will not be a rpc capability in the system until windows 95 comes back up and starts the rpc task. So there will be no conflicting task asking for status. Since the homepage script is the program that is issuing the rsh for monitoring, we can cut it off until a message is sent from the windows 95 system saying it is up. If the program terminates early, when windows 95 comes up, it will alert the unix system, who will know what time it was expected to come up. The unix system will close the remote doors, and then shut off the power to the TEC.
> I assume the data is showing up on one of the UNIX machine now via > NFS mount of whatever. If it is, why not just read the temperature > out of the raw FITS data file. It is (should be) recorded in one of > high numbered columns of peudo-pixels.At this time, there is no nfs mounted file system or smb file system. The problem is that tm3get11 runs best in DOS mode, and does not run very well under windows 95. I plan to run the program during the boot cycle for windows when it runs stand alone dos utilities.
> > Until we have a Linux version of tm3get11, I plan to copy a autoexec.bat > > The _best_ thing would be to have the driver broadcast the enginerring > data to any client who requests it. I have just about finished this > part of the Linux driver code. I have not heard from Norman in > ages. If anyone does, would they ask him to e-mail me at the address > below on my sig line. > > P.S. What you have is not (if you use common technical terms) a > "remote procedure call (rpc)". It is best called a telnet or rsh > server as that is the protocol used. An RPC is used by a > programmer to call a subroutine or function tha physically resides > on another machine.Chris I agree with your definition of the RPC. I am using the Winsock RSHD/95 utility so I should call it a rsh server. I would much rather be using a linux system, but since I am stuck at home recoverying from surgery, I can't get into the lab to write or debug it.
Arne Henden
aah@nofs.navy.mil
Mar 1, 1997
First, I want to make a point. Most of my messages seem to be negative, and could be interpreted as downplaying the quality of TASS data. This is in no way true! I wouldn't be commenting at all if I didn't feel that TASS had a place in the scientific community and that the final data quality would not be comparable to many professional sites. I'm sure Richmond and Paczynski feel the same way! There are some really bright people associated with this project, am I'm learning new things every day.
Chris asked about the astrometric accuracy to perform a couple of projects.
But TASS is almost there. Factors of 2-4 can usually be made up at this preliminary stage. For example, Tom's camera1 (V) images are far better than the I-band images, and the reported fwhm is poor only because there is trailing on the frames. You may have to stop down the I-band cameras to improve image quality; switch to R-band filters; or use two V-band cameras and one I-band camera. Likewise, once the hardware is adjusted, improved centering techniques using knowledge of the typical TASS camera image profile may increase the astrometric accuracy.
As a professional, I would much rather reported data that had: (1) 0.5arcsec coordinates instead of 3arcsec; (2) 0.01mag photometry instead of 0.10mag photometry. I think both are doable with TASS without major effort.
Tom Droege
droege@wwa.com
Mar 1, 1997
It seems to me that a few arc seconds is quite good enough to do the first (easy) part of this experiment. We only have to do 1) below, that is sort the star measurements. Then we can monitor our strip of sky for a year and find lots of good stuff. Then we can write a paper on what we have found, and wait for a shower of money (or a lot of copy cats) to do it better.
Tom Droege
droege@wwa.com
Mar 1, 1997
I have been running Mike Gutzwiller's star program on two days of "B" fields. I am very pleased with the result.
Running at 5 sigma, I get pretty much the same stars in all six fields. This is very encouraging to me. The astrometry would appear to be good enough to sort the stars, which is all that is needed to make the first pass at analysis for variable stars.
I like to look at data by hand with a pencil and paper. It allows one to see obvious junk in the data that can be missed until the program gets very sophisticated. So I printed out the first 100 stars in the B field from each of the six measurements and looked at them.
Camera 0 + 0.60 to - 2.28 degrees declination Camera 1 + 1.41 to - 1.38 Camera 2 + 1.23 to - 1.46
These fields were determined by looking at the extremes of 100 stars so the edges may not be quite right.
The sigma of the four I magnitudes measurements in general was less than the measurement sigma. With my non statistical background this indicates to me that the systematic errors are less than the measurement error, which is where we want to be. This was more true for the faint stars than for the bright ones, which probably suffer from saturation effects.
If the data gets no better than this, and the analysis gets no better, then we can still do a nice search and catalog experiment. We should find a thousand or more interesting objects. This is just great!
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 1, 1997
Bernie Kluga did a little redesign on the sensor alignment hardware for TASS#5. Marty and I are going to try to get him to document what he did and report it to the group. He replaced some of the mechanical linkage with teflon and other hardware so that it would not be temperature sensitive, and would produce a more accurate rotation of the sensor. The knob now does not have a large dead zone, and is easier to align. Now if the weather would clear I can give you examples of the data. The first run we did February 27 showed two of the three sensors aligned pretty well. The problem was that it was cloudy, and the third sensor could not see anything. We really only got about two files of party cloudy data before conditions closed in.
We are hoping that this will take care of the alignment problems we have been having, and will allow us to collect data for the paper.
Tom Droege
droege@wwa.com
Mar 1, 1997
> First, I want to make a point. Most of my messages seem to > be negative, and could be interpreted as downplaying the quality > of TASS data. This is in no way true! I wouldn't be commenting > at all if I didn't feel that TASS had a place in the scientific > community and that the final data quality would not be comparable > to many professional sites. I'm sure Richmond and Paczynski feel > the same way! There are some really bright people associated with > this project, am I'm learning new things every day.Views of a professional are much appreciated. I see you as someone who pushes us to achieve the best possible limit. This is just great. It keeps us on our toes. But I want to point out (again) the real goal of this project. It is to get people interested in all sky surveys, and go develop a pool of software tailored to the job.
The long term goal is to solve the earh colliding astroid problem with a group of amateurs before the government gets around to making it a big project out of it. There are a lot of other possible goals in between.
So I tend to think a little differently about presenting data from the project. What will make people more excited and get more people working on the project? Fussing too much about the last decimal point, though good science, will turn off some of the adventurous types that might want to join a treasure hunt. Thus I think it will be good to early on find a few variable stars and possibly an asteroid or two and then announce that we have done so.
> 2) To track a discovered solar system object. For near-earth > asteroids, the current 3arcsec accuracy will often be good enough. > Comets, because of their diffuse nature, are always difficult objects > to get highly accuracte coordinates. Distant asteroids require > higher precision; usually, reported coordinates with greater than > arcsec errors are thrown out of the solution.As a survey project, we just have to detect that we have a moving object. Then others (who are interested and have better instruments for the purpose) can follow up.
> But TASS is almost there. Factors of 2-4 can usually be made up > at this preliminary stage. For example, Tom's camera1 (V) images > are far better than the I-band images, and the reported fwhm is > poor only because there is trailing on the frames. You may have > to stop down the I-band cameras to improve image quality; switch > to R-band filters; or use two V-band cameras and one I-band camera. > Likewise, once the hardware is adjusted, improved centering techniques > using knowledge of the typical TASS camera image profile may increase > the astrometric accuracy.Don't get me wrong. I will certainly encourage us to to the best that we can possibly do. But I would like to go in stages. First discover a few things, then learn to perfect their measurement.
> As a professional, I would much rather reported data that had: > (1) 0.5arcsec coordinates instead of 3arcsec; (2) 0.01mag photometry > instead of 0.10mag photometry. I think both are doable with TASS > without major effort.As an amateur, I want to have fun. My temprement is more that of an explorer than that of a precise cataloger. I think science needs both types. The structure of tass (anarchy) is such that any tass member can choose either approach.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 1, 1997
A few thoughts on file names for raw TASS files. My first thought is that Tom's current scheme or something very close to it is reasonable enough. We have "bigger fish to fry", and the FITS header can provide a LOT of information: the filename need not do it all. The names need to be reasonably unique and informative.
*> I assume many people are still limited by DOS's 8.3 filenaming *> restriction.Yes, notibly the manufacturer of the cameras (!). Me too.
*> I will propose a convention very close to what Tom used when *> he posted his data to Storm's incoming directory. *> *> It is still possible to mix up files written by multiple sites *> but isn't that what directories where made for.Yes, until you create other directories and use other people's files and so on. I would encourage a filename format that would encourge each filename to be *unique*. Tom's scheme for filename (ignoring extension) would allow this if you replace the "T" with a site or camera designation, a preassigned letter for each camera (no site has two Mark III cameras). That easily supports 26 cameras, adequeate for the next year or two, long enough.
Tom uses the file extension for fractional date: I'm not so comfortable with that. Chris's alternative has some merits in that way, extensions are needed to identify file TYPES. But Tom's use of it for raw images may be an acceptable exception: raw data will have a numeric extension. Even so, programs that DEMAND a .FTS extension (or .fits) may stumble over raw data with the same filename. This can probably be lived with.
*> One last idea: The file F0789654.TXT would comtain an *> explaination of the contents of F0789654.FTS but one could *> supply a file called FX789XXX.TXT to explain all flat files *> made on day 789.If such info can be put into the FITS header, it should. A simple program to extract such comments and create this .txt file is easily constructed. Fewer files is better.
Glenn Gombert
ggombert@infinet.com
Mar 1, 1997
I have just uploaded to Storm /incoming a file called STARPOS.ZIP which contains the astromertic reduction of the following files:
File Star-List
G0483967.FTS A0483967.CAT
G0483977.FTS A0483977.CAT
G0493669.FTS A0493669.CAT
G0493678.FTS A0493678.CAT
G1493669.FTS A1493669.CAT
G1493678.FTS A1493678.CAT
G1493946.FTS A1493946.CAT
G1493955.FTS A1493995.CAT
G2483921.FTS A2483921.CAT
G2483931.FTS A2483931.CAT
G2493623.FTS A2493623.CAT
G2493900.FTS A2493900.CAT
G2493909.FTS A2493909.CAT
Michael Richmond
richmond@astro.princeton.edu
Mar 1, 1997
There are now two items described near the top of the TASS home page, each chock full o' data.
One is the page containing data from Tom's Feb 1997 collection. You can find the raw images, plus star lists generated by Gutzwiller, Richmond, and Gombert, plus astrometric analysis by Henden, all under
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
The other is a (small but growing) collection of star lists for the special fields "A" and "B" which make up the "Stupendous Man Scan Plan", or SMSP for short. Mike Gutzwiller has provided star lists from 4 different nights, and I'm hoping that Tom Droege will send some data he has mentioned. You can find this data under
http://www.astro.princeton.edu/~richmond/tass/smsp/smsp.html
Again, anyone who has data or analysis on either dataset, please contact me directly so that I can continue to add more material to these pages.
Tom Droege
droege@wwa.com
Mar 1, 1997
I have put a dozen files up on storm under incoming. They are
S30t0504.714
.723
505.714
.723
s31t0504.677
.686
505.668
.677
s32t0504.677
.686
505.677
.686
Neither day was particularly good. The moon was right there and
so were some thin clouds. These were all recuced with Mike G.s
sigma setting at 3. This gets down to mag 13 + which I want to
see for political purposes. I think a cut on position will sort
things out nicely from the noise. But what do I know about
statistics, so I will recompute these with the setting at 5 if
you all wish.
I compared one of Mike's files to one of mine by printing out a 100 stars. The two lists look much alike. The stars found on both lists all compared within the stated error (well within 3 sigma).
I continue to be encouraged.
George Turner
turner@bigbang.astro.indiana.edu
Mar 2, 1997
> So maybe another file format would be: > > jjjjxmnn.ccc > > jjjj modified julian date > x site > m camera > nn sequential file number (set to 00 for starlists) > ccc file type.Arne's suggestion is a good one; I have thanked the stars so many times that we decided to use JDs with our RoboScope data. It is a very powerful tool to be able to manipulate large amounts of data in a numerically sequentially way. You've got to keep in mind that computers will be dealing with the data much more than humans in a one on one way Often times a simple sort of filenames gives me the sequence for input data further down in the data reduction pipeline. I would however move the sequence number to after the MDJD to be able to take advantage of this sorting ability; How's about :
jjjjnnmx.ccc jjjj modified julian date nn sequential file number (set to 00 for starlists) m camera x site ccc file type.I also have swapped the camera & site because all filenames will have a certain predefined value that has the same meaning at all sites; the site variable will be different to everybody by definition. Simple MJD to local time conversion programs can easily makeup for any handicap resulting from humans not being able to decipher the filename.
Usually when a human wants to look at the data, it'll be because you want to go to that frame to find out what went wrong in the data reduction pipeline. Your data repository will be very much like a library; think about going to the library card catalog, getting the address of the data you want then going to that location and looking at the data. You'll often want to compare data from that point both forward and backwards in time. The simplest way would be to take the MJD of the time the file is opened . Since it's a drift scan, the length of the file will give you some sense of time with each row representing some kind of cosmic tick of the TASS clock.
(With RoboScope running on VMS & Un*x systems we use the full JD out to 7 decimal places with the decimal used as a period in the filename; this gives you 1/100 of a second which is the limit of most computer systems clocks. Setting your clock to that accuracy will be the topic for another discussion.)
Another idea is to use hex numbers for the sequence number; that'll give you 255 numbers instead of 99 and computers can easliy deal with them. Heaven forbid someone has enough trouble in one night with the thing starting & stopping that much; but hey, RoboScope can very quickly generate tremendious amounts data, mail messages, filled disks, overflowed buffers and other computer disconcerns when things don't go right.
Arne Henden
aah@nofs.navy.mil
Mar 2, 1997
Looking back over my emails, I think that I am replying too quickly and often without thinking. I am going to make it a policy to hold off 24hrs before answering a mail-list comment/question to give others a chance to voice their equally valid opinions, and to give me time to better compose messages that might be taken incorrectly!
Glenn G. wrote:
> The centroiding algorithm that I am using gives better than 1 > arcsecond resolution when used on digitized POSS data so I am sure that it > is fairly accurate.I replied:
> Which POSS digitized data are you referring to when you quote 1arcsec > resolution? And what do you mean by 'resolution'? How are you > measuring the accuracy of the centroid?...This dialog might be construed to mean that I think Glenn's results are poor. He has been getting results as good as anyone else! The POSS comparison is a good reality check, and shows that his centroiding is in the right ballpark. The point I was making is that the POSS material is considerably different than TASS images, and that to refine your centroiding, you need to compare TASS images with other TASS images. However, I am genuinely interested in the questions presented above...they were not meant to badger!
Once the quality of the images has improved (or at least everyone agrees to leave them in one state or another), then I think an investigation into different centroiding schemes could be valuable. The best article I've seen on centroiding techniques is Ron Stone's (AJ,97,1227,1989). We've found that most techniques work well on mid-brightness stars; they differ for saturated objects, extended sources, and stars near the sky level.
Arne Henden
aah@nofs.navy.mil
Mar 2, 1997
Tom wrote:
> ...But I want to point out (again) the real > goal of this project. It is to get people interested in all sky > surveys, and go develop a pool of software tailored to the job.Thanks for properly reminding me of the second letter in TASS! With the results from Tom's posted images, it is clear that you can cross-match star lists, get 'ok' astrometry and photometry, adequate for many projects and personal interests. I forgot to mention the obvious in replying to Chris' comment about what quality of data was necessary -- you don't need high quality astrometry to discover moving objects.
At the same time, if a couple of nights of effort can improve the quality of the images, you win big-time, even for the asteroid problem. For example, changing the 3.4 pixel fwhm to say 1.2 pixel fwhm:
Chris Albertson
chrisa@wavenet.com
Mar 2, 1997
> At the same time, if a couple of nights of effort can improve the > quality of the images, you win big-time, even for the asteroid problem. > For example, changing the 3.4 pixel fwhm to say 1.2 pixel fwhm: > (1) a sharper peak makes star detection easier.One of my questions was "Can you do this?" Assuming the lens resolves 80 cycles/mm at the center and we use 9um pixels.
What _should_ this lens be producing? Remember it is far from defraction limited. The 80 figure is just a reasonable guess but the figure could be between 60 and 100.
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 3, 1997
>*> FWHM in x and y for each. The software then finds the median FWHM in x and >*> y for all the candidates and assumes this is the FWHMs of a "typical" star. >*> The software then throws out any of the candidates from the first step >*> whose FWHM in either x or y varies by more than 25% from the median. This >*> throws out spurious peaks, **saturated stars**, etc > > Does this account for the lack of bright stars (> mag 8 or so) in your list: > they've saturated some pixels and are rejected?Most of the bright stars are rejected because I mark as invalid any pixel at 32767. No peak is allowed to have an invalid value so almost all bright stars are thrown out apriori. The brightest stars detected in an image are in the mag 6.5 to 7.0 range.
>*>> Along these lines, some figure of merit for "best astrometic fit" to all >*>> the appropriate catalog *positions* would be useful. >*>> .... I can probably get you a good >*>> PROCEDURAL example from the (radio) Ohio (State University) Survey >*>> publications in the Astrophysics Journal: let me know. >*> >*> A good idea. There are lots of other figure of merit as well, such as >*> constantness of the sky background, etc. In general in any halfway decent >*> image all SAO stars are seen unless they are too >*> bright and saturate the CCD or A/D converter. > > Hmmm. The implied question by my comment is: how good is your determination > of RA and dec for this image? You've used the SAO catalog, and "fit" some > of the stars in it to corresponding stars in the image. How good is the > fit? (I'm not presuming in this you are using the MAGNITUDES from the SAO, > incidently: for example, Michael Richmond does not use this information > in his location/astrometric algorithms. That would be another kind of > "fit", I think.)Unfortunately the fit to the catalog varies from image to image depending on the vagaries of the star matching routines and the distribution of the brighter stars. If the image and the test section of the catalog overlap only in a corner but enough stars overlap for a good match to occur then the stars in the opposite corner have poorer RA and Dec determinations than usual. Even in these cases though the RA and Dec should be good to about 1/2 pixel.
Arne Henden
aah@nofs.navy.mil
Mar 3, 1997
George Turner suggested some good mods to my second cut at filenaming.
I originally suggested using a sequential file number (00-99) in the filename rather than julian day fraction because: (1) I didn't see any need to know the starting day fraction of an exposure since each row in the frame has a different time tag; and (2) it was easier for me to identify the stored file at a later date. If it had a file number of 06, then I knew that there were 5 earlier files. 99 files seemed to be a reasonable number based on the 15-minute intervals in each FITS file.
After thinking about it, I'm not sure that approach is best. The starting julian day number will often change during a night (for Arizona, it changes just before dawn; for Europe, it changes after dusk), and then how do you handle a sequential file number? Perhaps it would be best to use the day number and day fraction like tm3get and Roboscope. Or, alternatively, take the approach that many observatories use: keep the julian date as the starting julian date for the entire scan, even if it rolls over during the scan.
If you use the day number and fraction, then you run out of characters without modifying the extension. For example (Henden v3),
jjjjfffm.xcc
where
jjjj Julian Date -2450000 fff JD fraction m camera x site cc file typeor, if you are happy with 14.4 minute granularity for the date (Henden v4),
jjjjffmx.ccc
or, like George mentioned, you could make jjjj, ff or both into hex or
base-26 (a-z) to save a digit or two at the expense of human readability.
I currently like version 4, as it works with the current TASS scanning strategy. It has the limitations mentioned by George (such as when you are starting/stopping with greater frequency than the current 15-minute file intervals), but meets the 8.3 spec. If you find it constricting, then use base-16 or base-26 to encode the date/time.
Our filenaming with FASTT is quite different. We use the year, daynumber, and sequential file number like
y97d053.105
primarily due to historical reasons and to keep commonality between all
of the CCD systems (stare as well as drift scan). Also, FASTT does more
than TASS-like drift scans, as it has a shutter and can move in declination.
Therefore, a typical night's observing includes a variety of projects, from
scanning long strips to looking at single objects as they transit. This means
that coming up with a good file-naming convention for TASS is just as new to
me as it is to you!
Michael Richmond
richmond@astro.princeton.edu
Mar 3, 1997
Following Arne Henden's suggestion, I have created a new subset of the HST Guide Star Catalog for TASS data-munchers to use. It contains one star per 20x20 arcmin grid, all the way around the celestial equator, covering Declinations -4 to +4 degrees. The stars range from 8 < V < 13.
The file has a simple ASCII format, to allow easy access. It contains 26,653 stars, and occupies 1.14 Megabytes. You can download the ASCII version, or zip'd version which is about 336K.
You can find a more complete description on the "TASS Catalogs" page,
and also download the catalog from that page.
I'm at work making comparisons between the various posted lists
of identified stars from one of Tom's test images g0483.967 (an
I band image at RA 200 to 206, decl -3.0 to 0.0). Richmond will put the
results on the Web page as I complete them. They are not fancy, simply
"do your stars look the same and are in the same place as my stars?"
for one of Tom's many files. I'm a little frazzled as this involves
printing sorted lists and matching stars by trial and error; and
hand calculations of many little numbers rather than writing programs
and using spreadsheets. My sample is small, too: the first 50 or so
stars out of hundreds, for one file out of several. So far, I'm looking
at position and magnitude for comparison. I hope to uncover any catastrophic
problems between these list: a "reality check", not much more.
One question arises in this process: To M. Richmond, M. Gutzwiller,
G. Gombert (two Michaels's here force this name convention):
What are you guys using for an absolute magnitude reference in your
posted star lists? Richmond I believe is using the Landolt stars, where
such appear in the image field. If they don't, what do you do? (My
image file of choice apparently has no Landolt stars.). Gutzwiller, are
you using the SAO magnitudes - my file of choice has about 40 of them
in it, but it was not obvious to me they "appear" in your output lists
as matching identified stars. Seems all these are close enought that
there is *some* effort to use absolute candles!?!
Simple results:
MAGNITUDE: Richmond
offers both "instrumental" and "abs. magnitude" values: I ignore the
former for comparisons, he says they differ by a constant from the latter.
Gutzwiller and Gombert provide magnitudes. Richmond's and Gutzwiller's
seem more consistent (over my sample, within +/- .2 mag) than
Gombert's (over my sample, Gombert's varies from about half a magnitude higher,
with occasional highs to one magnitude).
POSITION: using Richmond's findings as a reference, Gutzwiller
RA varies from Richmonds by +/- .0015 or so; Gutzwiller's dec varies by a
similar value roughly. Gombert uses pixel positions only: his X value
(column) is 15 pixels higher than Richmond's, his Y value (row) one pixel
higher. Additional variance is about .1 pixel in column and a little more
in row.
REFERENCE STAR LISTS:
As noted above, for one file the SAO offers 40 stars, the Landolt zero.
More clever calculations of distributions and noting exceptions can
be done by the principles, or by me at a later time. (Whew!)
Here is a man after my own heart. One who actually prints out data and
then looks at the numbers and adds things up with a pencil and paper.
Well, Herb, there are not many of us left.
I have been doing the same thing. First I printed out a few star lists,
then I wrote a QBASIC program which helped with the process so now I can
have it find all the data for a star and put it up on the screen. It is
easy to see on the screen when you look at the data that the high sigma is
due to one funny point from anothe star in the data.
The two of us with our hand methods will keep the big computer program
users honest. I have seen such efforts in physics turn out complete
nonsense until some of us actually looked at the real data. (Reactions
in the target shielding were producing off track events. The big programs
were confused, but as soon as one hand plotted a few raw events you could
see what was happening.)
Does anyone have a good clean and deep image that overlaps
one of more of the TASS fields that were posted. The Palomar
survey is now published on a set of eight CD-ROMS. Would
this work or has the compression algorithm killed the data?
I would like to be able to answer two questions about a list
of objects reduced from a TASS frame:
I know there are other ways to do 1 and 2 (especialy 2) but
I'd still want a clean image that goes a mag or two deeper then
TASS.
aah@nofs.navy.mil wrote (with edits):
I can probably come up with an ST-6 image taken with a 16 inch F/4.5
Newtonian that might be useful for comparison purposes. I will check my
"image archive" and see.
The "Real_Sky" data takes up a LOT of space ~15 megabytes for a 1
degree square field (thats the largest area the software will let you select).
You have made an excellent suggestion, one that we should try to
make some measurements/comparisons on...
Rick White did a paper on hcompress (available on the net) that
references some studies on image quality for Astronomical data. His
conclusion was that Astrometry is hardly affected by compression of
modest ratio's (20:1), and degrades for higher ratios.
The DSS is available on the net, however, it is in very small field of
view. Do you have access to the actual CD-ROM's?
in a later message
The URL to the Digital Sky Survey is:
http://stdatu.stsci.edu/dss/dss_form.html
There are other methods for retreiving the data. Take a look at xephem
3.0. I have not been able to get it working yet, but it is supposed to
read fits files, and retreive the DSS of the matching area.
The first half of my March observing run occurs this weekend, and so
far long-term forecasts look good. My intent (along with other projects)
are to provide 3 photometric sequences in each of the SMSP-A and SMSP-B fields.
The ones in SMSP-B are at:
The SMSP-A sequence centers have not been determined, but they will be
at roughly the same relative location (but centered on known variable stars).
Note that the CCD images for these sequence fields can be obtained from me
after Monday if you want high-quality images in the SMSP fields, and I can
probably provide CCD images from FASTT for the SMSP-A field at any time
(I just have to restore them from a tape archive).
Key to authors:
All in all, I'm still a little *amazed* that there is not a better established
list of reference stars. Having been around astronomy for awhile, I'm
not *surprised*, however.
According to my notes, the pixel size is given by
Using this, the drift scan rate on the equator is given by
Tom was getting 0.9178 for his Feb12 scans, considerably different than
the numbers above. I trust that the pixel size is probably very close to
9 microns, so my guess is (and assuming Tom has done his arithmetic right)
that the true focal length of the lens is more like 134.5 mm.
What are the scan rates that other sites are coming up with?
Also, a related site-specific question: for those sites actively scanning,
what fwhm are you finding for the 3 cameras? I'm curious as to whether the
3.4 pixel fwhm from Tom's February data is comparable to other sites.
Anyway, my basic question with regard to the software your running is why
stop with eight characters?
If you're using Win95, DOS itself (exit to DOS) will handle long file names
without any problem. I don't run Linux (we use NT in the shop for a
variety of reasons) but I would think it should be able to handle long file
names.
As an introduction: I'm a software developer with an interest in Astronomy.
My major strength is 3D real time graphics on PC's. I have to admit I
haven't been keeping up with the list, more or less just download a few
notes now and then.
I have thought about taking a look at some of the software mentioned on the
list .. I use a very fast DBMS system (CTree) that could help with some of
the routines I think, but I'm pretty busy at this point getting my next
software contract.
Since several people have asked for a "deeper" image of one
of Tom's fields, I've created some GIF pictures from the
Digitized Sky Survey CD-Rom. You can find them on the
page dealing with Tom's dataset,
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
The GIF images are a portion of the field visible in images
g0493946 and g2493909, two I-band images at high galactic
latitude.
If people find this useful, I can make available the FITS data
for this area, and/or create a GIF image for an area covered
by some V-band scan in Tom's set.
Bohdan Paczynski kindly provided a subset of the General Catalog
of Variable Stars, selecting stars with declinations (1950)
between -3 and +3 degrees. I have slightly re-formatted the
information, and precessed the coordinates to equinox 2000.
You can download this ASCII text file containing 386 stars
from the "Catalogs" sub-page under the TASS home page:
http://www.astro.princeton.edu/~richmond/tass/catalogs/catalogs.html
I have heard that the positions in the GCVS aren't very precise,
so don't be surprised if they aren't where you expect...
I tried running tm3get11 under a dos window in Windows 95. It couldn't
keep up. I don't have the tass control card installed in a linux system
yet (I am waiting on the linux version of tm3get11 before I install
linux on the TASS computer.)
I just couldn't find anything that was free and sufficiently high
performance, so that's why I went with CTree. There may be other
solutions, I was just brainstorming.
Because I've got a dark sky site and, due to work, lot's of computers
standing around, I've thought I could be a good site for a TASS setup after
things get settled down. I'm in Upstate NY. However, we've had three days
of starlight since December :-(
The 135mm f/2.8 should be about 50mm in diameter, which gives a
diffraction limit of
Bottom line: I still think you should be able to get 1.2-1.5 pixel fwhm
with the TASS cameras.
Chris wrote:
Michael noted that the coordinates for the General Catalog of Variable
Star objects are rumoured to be not very precise. My findings, in looking
at several hundred of these stars over my career, is that the coordinates
are within 20arcsec or so of the true position about 95 percent of the time.
There are some real outliers, but they are rare.
What is more common is misidentification, both in terms of whether the
star is even variable and in determining the variability type. Do not
believe that a star listed as an eclipsing binary is a binary...it could
equally easily be an RR Lyrae or Cepheid variable. Periods are often
aliases of something shorter.
Also, note that the GCVS has 386 stars in the +-3 degree zone. We found
in our variable star survey a statistical 4000 variables in 1/10 of that
zone, so there are about 100 times as many variables in the +-3 degree
zone as are currently known.
I was confused by Nick's recent message about Win 95, restarts, changing
autoexec.bat, etc. etc. until I saw this:
I want to make it clear that the reason we are playing with rsh, windows
95, and restarting is not to monitor temperatures remotely. We want to
run the data collection remotely. An ideal solution is a linux version
of tm3get11. What I am setting up for the APL TASS camera is a stop gap
procedure that we will throw out after the linux version comes on line.
The Tass Monitor task will let one unix computer monitor a DOS machine
prior to a data collection run.
For those of you interested in detecting asteroids in the TASS frames,
especially in the SMSP field A, there is an interesting paper by
D. L. Rabinowitz, "Detection of Earth-Approaching Asteroids in Near
Real-Time," 1991 AJ 101,1518. He describes the algorithms used by
the Spacewatch telescope to detect 'streaks' (fast motion in a single
frame) and 'motion' (slower movement between frames). He also gives
an indication of the magnitude of motion you should expect for asteroids
at different distances.
I played a little bit with different 135mm f/2.8 lenses on my KAF-400
based camera and found that most lenses are of very bad quality when
used without narrow band filters... they generally show a large blure
around a pretty sharp core... my guess is that is comes from chromatic
abberations...
I took some images using one of the lens that Tom uses and found that
It will give some very good images when used with a narrow (10nm) band
H-Alpha filter...
I still think that a high quality lens could improve the detection
by nearly 1 magnitude...
For reference, the fwhm with the 10 nm filter was 1.2 pixel.
The solution for TASS, as mentioned earlier, is to set up our own reference
frame, tied as closely as possible to the Landolt standards. Then, hopefully,
only a zero point will be necessary to compare TASS results with other
observers in the future.
While I still had the data on the hard disk I went through and
calculated the "average" FWHM of the detected objects in each of Tom's
images. Here are the numbers that I came up with:
I will try and repeat the same measurements from some of the data
taken here in Dayton over the weekend.
I have seen the same thing using standard 35mm camera lenses on a Cookbook
camera. I don't think the problem is limited to cheap lenses. One of my
lenses is an Olympus lens that ought to be pretty good. The problem is
that the designers never considered having to color correct these lenses
out to 10000 Angstroms.
Benoit wrote that he achieved 1.2pix fwhm with a 10nm filter, which sounds
reasonable to me. The 1.2pix number comes from the fact that the error
budget for imaging is less than one pixel, but you _never_ measure fwhm that
is only 1 pixel; it always gets spread a little.
Chris wrote:
My guess on this is as follows (and I mentioned it before):
A few variables (like Mira) _do_ change be enough that they would still
stick out -- but not many.
We've got to make our own photometric catalog, I think.
On Feb 19, 1997, Tom Droege wrote:
A quote from CCD Astronomy's Final Issue (last page, by Leif J. Robinson):
Folks, forgive a really dumb question:
is there a reason that TASS doesn't just use some kind of RFT Newtonian? A
wide angle Newtonian, with the imaging chip placed at the focal point
(non-visual) would be fairly well color corrected, wouldn't it? I'm
thinking that a short F ratio conventional Newtonian would have less
contrast due to the size of the secondary, but you could reduce the
secondary by putting the CCD in the tube, couldn't you?
If it's a dumb question, flame me privately and I'll go away
Don't get me wrong, so far, the project sounds really important and
superbly run. I hope to eventually be able to provide a site, as dark
skies and computing hardware is in abundance here, but so far we've had
only about four clear nights all winter :-( I'm in Upstate NY and lake
effect clouds seem to be the norm in the winter (this one's been
particularly bad).
Hi Tom -
I've been watching on the sidelines for a long time
but have been completely absorbed with my SNe studies.
But I thought that the CCD comment was the ULTIMATE complement.
TASS is representative of true 21rst century agressive
astromony done with pure guts and dedication and little money.
If nothing else comes of it other than the proof that
such cooperative effects can be done,
then you have been an immense success.
You should be very proud that you have had the
capabilities to keep this moving and flowing.
Not many people have these qualities. Congratulations!
Looks like I again got a bunch of pretty good data last night.
Boy, it is a struggle to get it processed and up in a timely
fashion.
I have been trying to put the star lists together and make sense
of them. One thing is clear, however bad the astrometry is, it
is good enough to match stars. The photometry is the big problem.
Some runs are much better than others when you compare the photometry.
Out of the seven runs I was studying for the V filter, three were
pretty good matching to about 0.1 mag at mag 12, three were so so,
matching to about 0.3 mag at mag 12, and one had 1 mag variations.
I purposefully don't say what I mean by "matching" above.
It is obvious we need lots of data. It is also obvious that we have
to adjust/select each star list as is is "added" into the "sum".
This all takes a lot of discipline. More than I have, since I am
doing a lot of other things. I will concentrate on taking data and
hope one of you can make good sense of it.
I encourage everyone else to take all the data they can. Particularly
the B field before it goes away (soon).
All questions are acceptable. It is not easy to say what is dumb.
The problem with the Newtonian is that if you have 135 mm focal length,
then you you get only a 34 mm dia lens at f/4. Putting a 3" diameter
CCD camera in the tube does not leave much light gathering ability. ;^)
At f/4 you have a chance to get the camera outside the tube, so it
can be done. But you can't begin to match camera lenses for possible f/
ratios.
The problem all comes from the size of available CCD's and the desire to
cover a large angle in the sky. To cover 3 degrees (and we want to cover
more per camera) the focal length is determined by the radius that forms
a 3 degree angle with the CCD width. This is close to the "standard"
135 mm focal length telephoto lens.
There are other problems with reflectors. If we had big CCDs, then it would
still be hard to get big reflectors because it is hard to get a large flat
field. This can possibly be done with Schmidt cameras, and we are exploring
that. But at the moment, the cheap and easy solution seems to be camera
lenses.
Tom and Mike G. so far have been gathering data on SMSP-B and posting that
data on Michael R.'s computer. Both of these sites have been using Mike G.'s
extraction software.
I would like to encourage these sites to archive their raw scan data.
There is still some discussion regarding how to properly flat-field these
frames, and much discussion as to the proper way to extract the data and
apply astrometric and photometric corrections. If the raw data still exists,
then we can go back and try different techniques.
Also, regarding Mike G.'s package, I would request that he add a couple
lines of code and output the fwhm in x and y for each detected object.
I know that he applies some shape parameter cuts before accepting an
object as real, but there will be many blended objects that pass such
tests and adding shape information to the output file will help us in
determining how to handle such objects.
I think the reason for using the 135mm lenses was one of cost and field-of-
view. I don't think it would be possible to buy mirrors (or more correctly,
mirror-lenses) of that focal length. You may get a better answer from some
of the other guys on the list. Tom?
I have been enhancing the "star" program and in the process discovered a
systematic error that, for once, is actually good news. I had created a
catalog for the "star" program based on the mini-GSC files Michael Richmond
created a while back. This was for both astrometric and photometric
considerations. Hopefully the astrometric values are better in the GSC and
since it went deeper in magnitude I could match more stars.
The new version of "star" will adjust the magnitude scale of the list to
best match the catalog. While testing the software I found the amount of
shift in magnitude increased as the catalog I was using went to fainter
magnitudes in the GSC. By the time the catalog got to mag 12 the shift
stopped moving though and the shift was the same for a mag 13 catalog and
the mag 14 catalog. Looking at the data by hand I discovered that brighter
stars were consistently measured below their GSC values. To illustrate
this effect I have uploaded an Excel spreadsheet to:
storm.fnal.gov/incoming/graph669.xls
The graph is a scatter plot of GSC magnitude vs. the difference in
magnitude between the star list and the GSC magnitude in Tom's g1493669.fts
image taken to 3 sigma. The graph shows a flat distribution for all stars
between mag 9.0 and mag 13.5. A notch appears beyond mag 13.5 when the
limiting magnitude is approached. From the graph I estimate the limiting
magnitude at 14.5 (50% efficiency).
For brighter stars (mag < 9.0) a systematic error begins to take effect so
that the magnitude error increases as the GSC magnitude decreases. The
effect is such that a matched star with a GSC magnitude of 7.0 is typically
measured at 8.0 in the list.
I believe what's happening is that bright stars which have TASS V or I
magnitudes lower than the GSC magnitudes (B?, P?) are preferentially
selected since they are bluer and do not saturate the A/D converter as
easily. ("star" ignores any star which has a saturated core.)
The end result is that the magnitudes published by the "star" program based
on its (100,000 ADU = mag 8.5) baseline are about 1 magnitude too low. I
now estimate the TASS 3 sigma limit to be near mag 14.5 as a result.
Arne wrote:
I seem to be good at this kind of dogwork, so I'll continue on it.
Richmond is posting my reports on the Web page (under Tom's "original"
set of images and further analysis"): I encourage comments.
Meanwhile, one comment not yet in my reports. Richmond and Gutswiller
apparently use the same pixel coordinates in their starlists: they
report the same stars in the same places. But Gombert's star lists
(the two I've checked) are consistently reporting "X positions" or
pixel column values 15 pixels greater; and "Y positions" or pixel
row values 1 pixel greater. Mutual agreement would be convenient.
After gathering ~160 megabytes of data last nigth (still unreduced)
I have outfited one of the "I" band TASS cameras with an infrared blocking
filter that I use with my ST-6. It should block any wavelength's longer than
about 0.7 microns. I am interested in finding out how the PSF varies as the
near-infrared is removed from the "W" TASS camera.
I will calculate the mean PSF that I have calculated from the data
run taken last night and compare the two it should be a very interesting
experiment. It may help to sort out how the wavelenght transmission through
the lens varies as a functions of wavelenght for the TASS triplets.
I will post a raw image or two on Storm when I get some data taken
(tonight if the weather clear's up).
Iam *very* curious as to where the "offset" is coming from, after
matching up numerous stars to postions measured on the image I get < +/- 1
pixel variation from the "raw" image to the postion shown in the star lists.
It would be nice to get to the "bottom" of this. There should be little
variation between the three technqiues (especially on btighter stars's X & Y
positions)
I have posted several example(s) of this in the last several weeks
and will show this in the TASS Technical Note that I am putting together on
astrometric and photmetric data reduction.
An interesting thing to try :
since a good deal of the star light is spread over n pixels, reducing
the aperature of the lens might actually improve star detection when
the camera is used in light poluted areas...
The core of the star image might stay about the same while the background
level would go down.
Glenn G. wrote:
Regarding pixel addressing: The 15 pixel offset is of course because one
program ignores the beginning blind pixels (i.e., only uses the true image
area) and the other one includes them. Likewise, a +-1pixel error usually
is due to whether the program is counting rows starting at 1 (like Fortran
and IRAF) or at 0 (like C).
I have yet another request for folks writing the extraction programs.
You list the RA,DEC,x,y,mag, etc., but you should also include the UT or
JD for each object (since they are not identical). This is the only
way we can properly handle variable stars. The UT can be calculated by
using the beginning UT for the frame and adding the 0.91sec/row offset.
This is a very tough practical problem.
The location of my reports on the Web page is described in another TASS
mail message today. I would be encouraged by any suggestions as to how
to make additional and useful stellar magnitude comparisons. The "astrometrics"
of location seem to be a solved problem.
It's occured to me that another way to reduce saturation is to use a
rotating mask, that is to block the field of view for some percentage
of the time. Since we do a row shift every .9 seconds, a half-moon
circular mask rotating at, say several rotations per second, would
reduce starlight by 50%. In effect you are sampling the stellar field
at a rate much faster than the shift rate. This scheme would preserve
the focal ratio and other optical parameters in use - an easy camera
modification for most of us. (Keep the motor away from the camera.)
But we need 9th magnitude or better to find asteroids and other objects,
so this scheme is at best a way to calibrate to brighter, better-known stars.
The intent is to use only and IR blocking filter and not an "I"/"V" band
filter(s) to use all the visible light shorter than 0.7 microns. Then
conpare this to see what kind of effect this has upon stellar FWHM in as
compared with "I" band images.
From my perspective, I read those comments as congratulations
more than anything else.
I am however puzzled by the position of Leif Robinson. Indeed
there is a lot of new astronomy that can be done using CCD
cameras, and TASS is only a small aspect of it all.
I'd then appreciate if Sky and Tel would show less amateurs
pushing glass, and guiding nice astrophotos, and more amateurs
doing astronomy instead. If Sky and Tel is not showing the
way, then who's role is it ?
When the average John Doe starts astronomy, he looks in sky and tel
to see what the others are doing, and usually he does the same,
he starts looking at NGC0001 and stops at NGC9999, then photographs
the same. Hasn't done much astronomy in the end, and Sky and Tel
is ( to my opinion ) partly responsible of this state of
affairs. CCD cameras are changing the way we do astronomy only
if people are shown that this can be the case. Reducing the
CCD camera to a faster way of making nice images of the sky
is in the end ( taking into account all that's left for amateurs
to discover ) quite pityful.
Sky and Tel ( since CCD astronomy does not exist anymore ) should
open a new regular page on amateurs doing astronomy. And there are enough
of them to make a full page in each issue. I am aware of those
amateurs discovering variable stars, novae, supernovae, following
satellites, following asteroids, doing spectrographic studies,
surveying the sky with blurry 135mm cameras ;-), you name it.
So Leif, put the paper where your mouth is :-)
( I hope this remark is as mild as I hope it is, cross my finger
that this translation is not agressive ! ).
Sky and Telescope is attempting to reach a common denominator, as an
observer rather than a industry leader. This gets into the fuzzy area of
the role of the journalist as a maker of the news instead of the
reporter. I feel that you are correct in that by not showing amateurs
crossing the line into professional research they are not reporting the
whole story. You may also be correct that by limiting what the amateur
sees as a scope of effort, S&T may also be implying that extending the
state of the art is not the realm of the amateur.
I think it may be useful to forward this thread to Sky and Telescope.
Their e-mail address is:
(This is listed for General editorial inquires. There is a long list of
e-mail address at:
http://www.skypub.com/s_t/s_tmail.html
Well, I finally gave in and bought a second ZIP drive to move
data from the basement to the 2nd floor data analysis machine.
The problem was that the 2120 in the basement was only slightly
compatable with the TR3 drive on the analysis computer. It would
loose about 1 file in 10. A real pain. So I thought the Zip would
be easier. ;^(
Installing the ZIP took all morning. The Zip software would just
hang the computer when it got to the program that loaded the program
that found a drive letter for the Zip. This lead to the standard
problem. Something in autoexec.bat was hanging the computer but I
coulden't edit autoexec.bat because it was hanging the computer.
Now where is that DOS boot disk when I need it.
I finally got it going after extensive excercising of my four letter
vocabulary. It turns out that the Zip drive did not like mouse.com
in the autoexec.bat file. Now just why should that be?
In any case, I am now set up to send 100Mb data sets out to data
munchers that don't have a telescope. I am preparing a disk for
Arne, perhaps he will pass it on to someone else that wants it.
Herb's point is well taken that the lack of good "standards" make it
difficult to make good photometric calibrations of TASS images. I have added
a "Tech Note" to the Dayton TASS Camera Home Page, as well as asking Michael
to add this to the TASS Home Page on photomertic calibration using the image
of M67 that I posted to storm several weeks
ago.
(http://www.infinet.com/~ggombert/tass.html)
It was taken with a 16 inch Newtonian telescope and SBIG ST-6 ccd
camera with a "V" band photometric filter. The image has 11-12 well known
reference stars in the image that have well published photometric magnitudes.
Dr. Mattei at the AAVSO was kind enough to supply a copy of the
AAVSO cailbration chart for the M67 region that was very helpful in
calibrating the catalog output for the image.
I carefully tried to set the "zero point" of the Sextractor program
and then checked the magnitudes that were generated for the other 11
reference stars in the image. It is an excellent way to compare the
photometric accuracy of any method for generating star-lists. I have shown
the star-list output as well as the photometric magnitudes for 11-12
refernece stars (with comments out to the side).
It looks like a few percent photometric accuracy should be possible
on a routine basis with careful calibration. The other star magnitudes in
the GSC/SAO catalogs are just not accurate enought (as Arne has pointed out
several times). This makes it very difficult to tell how accurate
photomertic magnitudes as being calculated in TASS images.
I would be happy to supply as set of the AAVSO M67 field reference
data upon request. (Just give me a mailing address). I think that this image
should prove useful in evaluating various ways of calculating instrumental
stellar magnitudes.
Ya know, the Japanese have a real astronomy magazine. It puts S&T to shame
as an instructional device for observational astronomy.
The following is a report on my cross-comparisons of three star
lists of Tom's image S31T0493.669; list made of course by Richmond,
Gutzwiller, and Gombert. Michael Richmond, please archive this as file
"rpt1493.txt" in the area of the Web page with my other report. It's
short enough that I thought I'd simply put it out on the maillist.
(Note: the report exceeds 80 columns of text.)
I'll make no further astrometric comparison reports, as it seems
we have no problems there. I'll do no further photometric reports until
I come across "better" catalogs. As Glen Gombert noted, the catalogs
in hand are not sufficient. - Herb
THe "pretty pictures" explanation is the only way to account for the
photos of star trails in the astronomy magazines.
As a member of a number of astronomy clubs, I can personally confirm
increased public interest: we have larger memberships, more people
come to our events, star parties are bigger and there are more of them.
As for your comments that all this is "not real astronomy": well, again
my amateur experience is that very few amateurs engage in scientific
data collection. I recall, for instance, an amateur who has set a goal
of being the person to have seen the most asteriods. He does this
by charting where they will be, and then he looks at them on successive
nights (to confirm their motion) and then he makes a simple diagram in
his notebooks. *However*, to my surprise, he does not bother with efforts
to note the *exact* time of his observations, nor does he bother to determine
exactly *where* in the sky the object is. Thus, his observations have
little scientific value. But he *is* #2 in the world now in "counting
asteroids".
The point is, it is futile to argue about what "real astronomy" is or
should be. The point is to do it, as best you can, and to report results
and "spread the word" that even simple but CAREFUL observations can make
a difference - and can be fun at the same time. Asteroid occultations
are brief events, but even with a telescope and stopwatch they can
be EXTREMELY important in establishing asteroid orbits and size, as
well as determine very close double stars.
As we report on our observations
and how we do them, someone else will be inspired to do more careful
work. That's how *I* got into all this. But we must all work harder to
write up and report our results. Write a paper; give a talk; post
results and methods on a Web page. Most astronomy clubs and Web sites
are BEGGING for original work!
As for the public interest in pretty pictures: well, the public provides
donated funds for many of our astronomy clubs, and their taxes pay for
many government-funded astronomy programs, so there that is.
I would not suggest complaining to Sky and Tel; I'd suggest writing
articles, and *encouraging* these magazines when they PUBLISH original
AMATEUR work of scientific merit. Just my opinions of course.
And of course we also need "better" reference catalogs, if such can
be found or made.
I *would* encourage a sequence number for all lists, to make references to
individual stars easier. Then of course any computed information can
be easily added to a secondary list crossed by sequence number.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 3, 1997
Tom Droege
droege@wwa.com
Mar 3, 1997
Chris Albertson
chrisa@wavenet.com
Mar 3, 1997
Chris Albertson
chrisa@wavenet.com
Mar 3, 1997
> If you use the day number and fraction, then you run out of characters
> without modifying the extension. For example (Henden v3),
> jjjjfffm.xcc
> where
> jjjj Julian Date -2450000
> fff JD fraction
> m camera
> x site
> cc file type
>
> or, if you are happy with 14.4 minute granularity for the date (Henden v4),
> jjjjffmx.ccc
Just a few comments.
Glenn Gombert
ggombert@infinet.com
Mar 4, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 4, 1997
> Does anyone have a good clean and deep image that overlaps
> one of more of the TASS fields that were posted. The Palomar
> survey is now published on a set of eight CD-ROMS. Would
> this work or has the compression algorithm killed the data?
I think I can answer your question about compression on the Digital Sky
Survey. The algorithm was designed by Rick White at Space Telescope
Science Institute. It is the hcompress algorithm using the haar wavelet.
Rick did a study that evaluated different compression ratio's. There is
loss, but in the region that we are working, I don't think the loss will
be noticable. The DSS plates are digitized to 25 microns at a precision
of 15 bits. (I am reading from the Guide Star Sampler), The Digital Sky
Survey Home Page says that the first generation was 1.7 arc seconds, and
the second generation plates were 1 arc seconds. The compression
algorithm distorts this somewhat, but if the data were reduced to the
accuracy that we see with TASS, the effect of compression should drop
out. The compression algorithm gives higher accuracy to low pass data
(reduced resolution of the image) (that assumes that hcompress works
like a conventional wavelet.)
Arne Henden
aah@nofs.navy.mil
Mar 4, 1997
8:49:00 +01:15
8:52:50 -00:10
8:50:00 -01:15
And each is 11 arcmin square. These sequences will have +-0.01mag errors
at V=17, and so should be good for both additional calibration stars over
and above the available Landolt standards, and for determining limiting
magnitude and precision at faint magnitudes. I will provide the data at
both the 12arcsec aperture size that Landolt used, as well as a huge 50arcsec
aperture size that the current TASS images seem to require.
Arne Henden
aah@nofs.navy.mil
Mar 4, 1997
> Does anyone have a good clean and deep image that overlaps
> one of more of the TASS fields that were posted.
Chris, do you mean one of Tom's fields? I have FASTT scans covering
most of these fields (except g1493946 and g1493955) that go to R=18 or so.
They are stored as 2048x2048x16bit FITS images (8MB each, 50x50arcmin).
The resolution (3 arcsec artificially blurred seeing) may be poorer than
the Digitized Sky Survey, but the relative photometric accuracy will be
better. What do you want to do with the 'clean and deep image'? If you
just want something pretty, then the Digitized Sky Survey will be better.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 4, 1997
*>> Herb
*> Mike Guztwiller
*>> What are you guys using for an absolute magnitude reference in your
*>> posted star lists?
*>
*> The 8.5 and 100000.0 were determined to give approximate matching of the
*> calculated magnitudes and the SAO catalog.
OK, thanks for the details.
*> At this point a more interesting question might be how the
*> relative magnitude
*> varies between the lists. If all the programs were consistent then the
*> magnitudes calculated between two lists should differ by a constant for all
*> stars.
Lacking at the moment a reliable and extensive absolute reference list, and
seeing as we need to present findings of position and magnitude for this
AAS paper(s), I first chose to look at self-consistency among the lists.
The SAO list gives only 40 candidates, but I'll try them next as a reference:
at least they'll force me to look over different parts of the image.
*> Since Michael R. is using the GSC and I'm currently using the SAO the
*> varience [in position] between our lists is expected. I plan to use the
*> GSC or possibly the USNO-SA1.0 instead of the SAO soon.
...such radical changes being the reason I don't spend more days on a more
exhaustive review. If I can automate it I might. Meanwhile, is the varience
*small enough* that it can all be attributed to differences in lists (and
different PSF, and dark and flat correction, etc. etc...)?
Arne Henden
aah@nofs.navy.mil
Mar 4, 1997
scale (arcsec/pix) = [206.265*p]/f
where p=pixel size in microns, f=focal length in mm
for the 135mm lens and the 9micron pixels, this gives a scale of 13.75 arcsec/mm
assuming 135.0mm focal length and 9.000micron pixels (neither of which is
probably true, and probably not constant between the lenses and/or V-I
focal points).
time (sec/pix) = 86164.09 (sec/sid day)
-----------
[[360*3600 (arcsec)]/13.75(arcsec/pix)]
or 0.9142 seconds/pixel. This changes to 0.9143 at 1 degree, and 0.9147
at 2 degrees off the equator.
John Gwinner
gwinner@northnet.org
Mar 4, 1997
> I'm still learning this terminal emulator at home, so sorry
> about the errors in the last mailing!
> Continuing, with corrections:
Pardon me for jumping in; my first post so there's a brief intro at the
end.
Michael Richmond
richmond@astro.princeton.edu
Mar 4, 1997
Michael Richmond
richmond@astro.princeton.edu
Mar 4, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 4, 1997
> There is an ADC on the Data Board and a DAC on the Control Board.
> It is not necessary to load the DAC unless you are trying to change the
> set point of the temperature controller, or the frequency of the
> drift scan.
>
> It sounds like Norman's routine will do just what you want. However,
> I notice that Norman's program does not set the temperature DAC until
> it completes the clear process and starts ramping up. What I do at
> home is to start Norman's program, and wait until it completes the
> clear. Then I abort the run and delet nnnnnn.tm3. Then after things
> have stabalized, I start the run again.
>
> It looks like you will have to find the place in Norman's code where
> he loads the temperature command value into the DAC. Then you can load
> it up. Or you can just do what I do and after a power on start and restart
> the program.
>
> Note the DAC will hold it's set point until the power is turned off. With
> the VCO not very good, it may pay to keep the computer on all the time.
You raised some interesting points. Let me go over the way we will
operate the system:
Any comments?
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 4, 1997
> > 7. I will either periodically ping the system (it should not respond
> > until windows 95 comes back on line). As an alternative, I will try to
> > execute a remote shell, that should not work until windows 95 comes up.
> > That will be my signal that the program has finished. The program has
> > failsafe measures that shut it off if the temperature goes bad. I may be
> > able to tie a serial I/O line into the system to send critical data back
> > to the home page system. Has anyone tried to run tm3get with I/O stored
> > on a NFS or SMB (samba) system?
>
> Could you place a program in the Win95 "start up" folder that would
> notify the UNIX system when Windows has come back up? Maybe even
> place an rsh command in the startup folder?
>
> Did you ever try to run tm3get under dosemu with Linux? Just wondering
> if it would work.
I will have to look into a rsh from Windows 95 to unix, that would be
easier and cleaner.
John Gwinner
gwinner@northnet.org
Mar 5, 1997
> You are right. Every major operating system being sold today can handle
> long filename. Problem is some people are still using older systems.
Well, we could also backdate the software for 286 computers too :-) My
bias: I'm an upgrade bigot, at least you'll know that from the start!
> Also many DOS and even windows programs, cannot accept long filenames
> even though the OS can.
True, 16 bit programs will not; 32 bit programs will, unless special effort
is made in the software to screw things up.
> If it where me making decisions I'd use longer more desciptive names on
> the archive and let people with 8.3 systems rename the file _after_ they
> are downloaded.
That would work .. changing file names is required for Web work anyway.
> Is this database Free or covered by the GNU or GPL style lincense?
> That is the problem with many DBMSes. If you require our users to
> buy a DBMS product you code is not so popular.
True. I guess it depends on what we're doing; I had in mind compiling the
routines in and distributing the compiled code, but if we are all compiling
at home, then we'll need something free of course.
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
>One of my questions was "Can you do this?" Assuming the lens
>resolves 80 cycles/mm at the center and we use 9um pixels.
9um pixels is 110 pixels/mm. 80 cycles/mm means 160 resolution elements/mm,
so roughly the resolution should be about the same as a pixel. Since
seeing is <14arcsec, then theoretically, the TASS images should have
fwhm of <1pixel. I don't know for sure what the quality of the Aubel
lenses should be. One way of checking would be to take a lens of known
quality (something that has been lab tested in Modern Photography or
something) and put it on one of the TASS cameras.
difflim (arcsec) = 0.252 * lambda(nm)/D(mm)
or 2.5arcsec for the V bandpass. So you are right: if the resolution is
100 l/mm, then the lens is not diffraction limited. That is ok, since
the pixels undersample the diffraction pattern anyway.
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
> (1) The convention of using the last three characters is so old and
> entrenched
> that it is not likely to go away. The dot-three part of 8.3 goes way
> back and pre-dates DOS or even CP/M. I'll bet 11 characters fits real
> nicely into the word size of some very old computer. I think we are
> stuck with "ccc".
I think we are stuck with 8.3 because of the ISO9660 standard for CDROMs
(I know, there are extensions, but lowest-common-denominator again) and
DOS x.x. I am not so certain that the dot-three needs to have any special
format as each program has developed their own extension. Witness WORD
with .doc and .rtf; AUTOCAD with .dxf, etc. There is nothing unique about
these three characters, just the 8.3 format itself.
> (2) file names only have to be unique within a directory. What will be
> mixed in one directory?
The problem arises when datasets are combined from different sites. George
touched on this. For example, it may make more sense to keep the merged
(but raw) nightly star lists separate from the photometrically calibrated
star lists, so the directory tree may look different at the reducer's
site than at the camera site.
> (3) I picked jjjfff as the unique id because it is easy to derive from
> the filename written by tm3getxx. You just drop one "j". I can write a
> simple script to do this but more complex mapping require a program to
> do the filemane changes from tm3get's convention.
Note that George Turner's mods and my mods and your suggestion are all
similar. George and I moved the julian date to the front of the filename
for sorting ease. We use a 4-character julian day number so that you don't
get rollover as quickly. Also, why use a script to do the mapping -- there
is nothing preventing the modification of tm3get to output the agreed-upon
file name.
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 5, 1997
*> 3. At this point I really want to monitor temperature to see if we are
*> in trouble. Is there any harm constantly resetting the temperature DAC,
*> or should I leave that alone and every minute, run a task that just
*> reads the temperature and voltage?
Aha! Some time ago I suggested to Tom et al that an overtemperature
circuit, a single chip, can detect excessive Peltier temperatures
and cut them off before they cook themselves. I've sent Nick the details
for further consideration. I'd do it myself, if I had a camera in hand.
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 5, 1997
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
Benoit Schillings
benoit@be.com
Mar 5, 1997
Arne Henden
aah@nofs.navy.mil
Mar 5, 1997
> All in all, I'm still a little *amazed* that there is not a better established
> list of reference stars. Having been around astronomy for awhile, I'm
> not *surprised*, however.
All-sky photometry at the 0.01mag level is truely difficult. That is
why there are only a handful of astronomers pursuing the task of setting
up standards. Space missions, where you get above the atmosphere, are
the obvious solution, and the Hipparcos/Tycho results are anxiously awaited
(even though they didn't choose true B & V passbands!).
Glenn Gombert
ggombert@infinet.com
Mar 5, 1997
File: SkyBackground(ADU) RMS Sky FWHM(Average)
G0483967.FTS 11167.6 55.4055 3.61
G0493669.FTS 11698.1 97.5382 3.88
G0483977.FTS 10926.8 49.9414 4.02
G0493678.FTS 11753.2 95.8544 3.81
G1493995.FTS 11439.9 52.8192 3.62
G1493669.FTS 13155.8 63.7128 2.66
G1493678.FTS 13154.2 62.4993 2.91
G1493995.FTS 11705.8 52.7644 3.44
G2483931.FTS 99972.7 45.9182 4.23
G2493623.FTS 12642.9 96.1175 5.49
G2493900.FTS 10704.7 49.7170 4.08
G2493909.FTS 10772.3 50.5891 4.10
Allen Gilchrist
gilchris@ipxpress.aws.waii.com
Mar 6, 1997
Arne Henden
aah@nofs.navy.mil
Mar 6, 1997
> Why is this? My 80 l/mm estimate was based on tests done with
> photographic film. The film's spectral sensitivity acts like Benoit's
> narrow band filter.
I thought photographic film was polychromatic and therefore does _not_
act like a narrow band filter. Lenses are usually achromatic and, like Chris
said, only perfectly corrected at two wavelengths, but these wavelengths
are chosen so that the lens is almost perfectly corrected throughout the
wavelength range of color film.
Allen wrote:
> I have seen the same thing using standard 35mm camera lenses on a Cookbook
> camera. I don't think the problem is limited to cheap lenses. One of my
> lenses is an Olympus lens that ought to be pretty good. The problem is
> that the designers never considered having to color correct these lenses
> out to 10000 Angstroms.
Allen, were you talking about using the lens unfiltered, or at least
without a red blocker? Then I can fully understand poor image quality.
Allen makes the very valid point that photographic lenses are not
color-corrected at 1000nm. In fact, the 'IR' marking on most of these
lenses refers to 650nm or so.
(1) the camera with best focus is #1 (V). For Tom, it was 2.8pixels
fwhm or so. Michael R. told me earlier that he has seen 1.8pix
fwhm on his camera1 without careful focussing. No one else has
given me any image quality data for their TASS cameras, so I
don't know the spread in this measurement.
(2) the cameras with worst focus are the I bandpass. Few camera lenses
expect the user to have film sensitive to 800nm light, and I doubt
they correct their lenses out here.
(3) Benoit showed that the Aubel lenses work ok at H-alpha (650nm),
essentially at the R bandpass.
Therefore:
(4) I think better focus can be achieved at V than you are currently
getting. You may want to try an experiment of using a red blocker
with the V filter to remove any hint of long-wavelength aberrations.
(5) I think for the 'I' bandpass you are either going to have to stop
the lens down to remove some of the aberrations, or else switch
to an R filter to get back into the 'corrected' range of the lens.
Stopping the lens down, using a red blocker and using an R filter should be
easy tests that don't have to be done by all sites. Paying careful attention
to focus should be done by all sites, preferably on cameras pointed at the
equator and then only for the middle columns.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 6, 1997
*> All-sky photometry at the 0.01mag level is truely difficult. That is
*> why there are only a handful of astronomers pursuing the task of setting
*> up standards...
*> The solution for TASS, as mentioned earlier, is to set up our own reference
*> frame, tied as closely as possible to the Landolt standards.
A "wholesale" approach might be to use a large set of stars that, in the
aggregate, have sufficient precision in magnitude. I suspect, however, that the
distribution of errors is not uniform, and of course it begs the question to
determine it. I've noticed that some star catalogs are many decades old:
would an average (mean? mode?) of readings across the decades, hopefully
at similar passbands, provide a better value for a given star; or at least
remove some long-term variables?
Michael Richmond
richmond@astro.princeton.edu
Mar 6, 1997
> I've noticed that some star catalogs are many decades old:
> would an average (mean? mode?) of readings across the decades, hopefully
> at similar passbands, provide a better value for a given star; or at least
> remove some long-term variables?
No, I don't think so. For the great majority of variable stars,
the amplitude of variation is small enough that systematic differences
between different stellar catalogs would swamp any true variability.
That is, a catalog made in the 1930s, based on photographic measurements,
and a catalog made in the 1960s, based on photoelectric photometry,
will have effective passbands which are far enough apart that individual
stars which DON'T vary, in truth, will still appear to have different
magnitudes, simply due to the passband mismatch.
Peter McCullough
pmcc@astro.uiuc.edu
Mar 6, 1997
> Hmmmm! What does it mean when the last page of the last
> issue of a magazine says you are an arrogant maverick?
> I like it! It comes very close to meeting a particular
> goal of mine. - Tom Droege
From that I was left with the impression that the article
was uncomplimentary (although T.D. felt it was a compliment).
In fact, the article was a compliment in the traditional
sense too. Below I attach the paragraph for those without
CCD Astro Magazine.
> ...The Amateur Sky Survey (TASS)...aims to keep 1,000 square
> degrees of sky under continuous electronic surveillance to
> magnitude 15. (You can find out more at
> http:/www.astro.princeton.edu/~richmond/tass/tass.html.) Comets
> and variables stars are obvious prey, but it's the promise of
> the unforeseen -- gamma-ray bursters,perhaps -- that excites
> my gray cells. I'm sure [Fritz] Zwicky would have loved the
> arrogance of this observing project.
So it wasn't T.D. that was said to be arrogant, but the TASS
project itself, and in a very complimentary, positive way.
John Gwinner
gwinner@northnet.org
Mar 6, 1997
Mike Schwartz
pfactors@ix.netcom.com
Mar 6, 1997
>Sometimes my sense of humor gets me into trouble. ;^)
>
>I did not really mean to mis-quote the article.
Tom Droege
droege@wwa.com
Mar 7, 1997
Tom Droege
droege@wwa.com
Mar 7, 1997
Arne Henden
aah@nofs.navy.mil
Mar 7, 1997
Allen Gilchrist
gilchris@ipxpress.aws.waii.com
Mar 7, 1997
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 7, 1997
Michael Gutzwiller
Michael_Gutzwiller@AICI.COM
Mar 7, 1997
> Tom and Mike G. so far have been gathering data on SMSP-B and posting that
> data on Michael R.'s computer. Both of these sites have been using Mike
> G.'s extraction software.
> I would like to encourage these sites to archive their raw scan data.
> There is still some discussion regarding how to properly flat-field these
> frames, and much discussion as to the proper way to extract the data and
> apply astrometric and photometric corrections. If the raw data still
> exists, then we can go back and try different techniques.
I have archived all my runs on tape going back to October 1996 and will
continue to do so. I too believe in keeping the raw data including dark
images for reanalysis with better techniques. This tendency probably goes
back to my high energy physics days where teasing 20 events out of 3 months
of data was considered a horn of plenty for my thesis.
> Also, regarding Mike G.'s package, I would request that he add a couple
> lines of code and output the fwhm in x and y for each detected
> object. I know that he applies some shape parameter cuts before
> accepting an object as real, but there will be many blended objects
> that pass such tests and adding shape information to the output file
> will help us in determining how to handle such objects.
I cringe whenever somebody asks for "a couple of lines of code" but in this
case it actually won't be more than about 10 lines since I already
calculate FWHM while creating the PSF. It will be in the next version of
"star" coming out next week.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 7, 1997
*> I have been trying to put the star lists together and make sense
*> of them. One thing is clear, however bad the astrometry is, it
*> is good enough to match stars. The photometry is the big problem.
This is my impression also, as I'm working on a second set of
star list comparisons. We can find stars, across all three sets of lists.
The two who are determining RA and dec (Richmond and Gutswiller) seem
to correlate well: I'm still looking at SAO and GSC catalogs to see
where those stars fit in. But magnitudes are another matter.
Glenn Gombert
ggombert@infinet.com
Mar 7, 1997
Glenn Gombert
ggombert@infinet.com
Mar 7, 1997
Benoit Schillings
benoit@be.com
Mar 7, 1997
Glenn Gombert
ggombert@infinet.com
Mar 7, 1997
> but there will be many blended objects that pass such
> tests and adding shape information to the output file will help us in
> determining how to handle such objects."
Arne has made a point I think that is critical to accurate data
reduction. I have seen several examples in the last couple weeks where a
faint background star is in the aperature of the star that is being
measured. I think that a way to detect this and make sure that it can be
identified for each star that is being measured is very important for
accurate results...
Arne Henden
aah@nofs.navy.mil
Mar 8, 1997
> After gathering ~160 megabytes of data last nigth (still unreduced)
> I have outfited one of the "I" band TASS cameras with an infrared blocking
> filter that I use with my ST-6. It should block any wavelength's longer than
> about 0.7 microns. I am interested in finding out how the PSF varies as the
> near-infrared is removed from the "W" TASS camera.
I hope that this is a misprint, or that Glenn did not include a couple
of key words! If you put an IR blocker along with an I filter, you will
get zero throughput, since the I filter peaks around 8500 A. The IR
blocker should accompany the V filter ONLY.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 8, 1997
*> The new version of "star" will adjust the magnitude scale of the list to
*> best match the [GSC] catalog.
*> While testing the software I found the amount of
*> shift in magnitude increased as the catalog I was using went to fainter
*> magnitudes in the GSC. By the time the catalog got to mag 12 the shift
*> stopped moving though and the shift was the same for a mag 13 catalog and
*> the mag 14 catalog. Looking at the data by hand I discovered that brighter
*> stars were consistently measured below their GSC values. To illustrate
*> this effect I have uploaded an Excel spreadsheet to:
I don't have Excel up at this time. I'd appreciate a simple plot of
magnitude vs. this shift you mention, maybe exported as a .GIF file or
whatever is reasonably universal. This shift begs a question: is it an
artifact of the GSC? My discussions with Richmond on the GSC suggest it
is not a good *photometric* reference: for instance, when a given area
of sky has "enough" reference stars, the list ends for that area - so the
GSC is not a random or "complete" sampling.
*> I believe what's happening is that bright stars which have TASS V or I
*> magnitudes lower than the GSC magnitudes (B?, P?) are preferentially
*> selected since they are bluer and do not saturate the A/D converter as
*> easily. ("star" ignores any star which has a saturated core.)
Interesting....of course this is a statistical argument and also dependent
on galactic location.
*> The end result is that the magnitudes published by the "star" program based
*> on its (100,000 ADU = mag 8.5) baseline are about 1 magnitude too low. I
*> now estimate the TASS 3 sigma limit to be near mag 14.5 as a result.
Odd. My reports, on the first 50 or so stars between you and Richmond,
did not show a 1-magnitude difference between the two of you. My sample was
small however (and with an I band image. I'm now looking at a V band image.)
Are you saying "one magnitude too low *relative to the GSC*"? Richmond tells
me the GSC magnitudes, as determined from the Paliomar Survey
E band plates, are closer to V band results than I band results: so using
the GSC magnitudes for the I band is even less appropriate.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 8, 1997
*> since a good deal of the star light is spread over n pixels, reducing
*> the aperature of the lens might actually improve star detection when
*> the camera is used in light poluted areas...
*> The core of the star image might stay about the same while the background
*> level would go down.
There would be fewer saturated star images with a reduced aperture, and
some dim stars would be lost, so the range of *detected* magnitudes would
shift to the brighter stars. This might be a plus in terms of finding
reference stars as there seem to be brighter stars available in
some lists. As it stands now, we need a 9th magnitude or better catalog!
Glenn Gombert
ggombert@infinet.com
Mar 8, 1997
Alain Maury
maury@ocar01.obs-azur.fr
Mar 8, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Mar 8, 1997
> So Leif, put the paper where your mouth is :-)
>
> ( I hope this remark is as mild as I hope it is, cross my finger
> that this translation is not agressive ! ).
Tom Droege
droege@wwa.com
Mar 8, 1997
Glenn Gombert
ggombert@infinet.com
Mar 8, 1997
Bob Goff
goffaxe@azstarnet.com
Mar 8, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
---------------------
Comparison of star list magnitudes of Droege S31T0493.669 image
Herb Johnson March 9 1997
Image is V band. GSC catalog stars from E plates of Paliomar Sky
Survey plates. SAO is ??
SAO
---
SAO catalog for RA 117.4 to 117.999, dec 0.X to -2.4999
Richmond .AST stars for same area, by Richmond number and .AST magnitude
(Radius R of 3.5 pixels).
Gutzwiller stars for same area, by magnitude
Gombert stars for same area, found via Richmond .AST and .PHT lists only,
by Gombert number and magnitude
SAO RA dec mag Richmond Gutzwiller Gombert (via Richmond)
135145 117.4584 -2.0664 8.5 30 8.343 7.992 59 8.4326
135150 117.4934 -1.4697 9.0 46 9.608 9.232 90 9.6976
135154 117.5285 -1.6822 8.0
135157 117.5583 -1.4593 8.2 76 8.062 7.725 146 8.1444
135161 117.6426 -1.6099 8.5 107 8.075 7.698 226 8.1587
135171 117.7191 -2.4953 8.3 142 8.329 267 8.5695
116019 117.7222 0.0792 6.6
135175 117.8137 -0.4750 9.0 8.850
135176 117.8221 -0.4620 9.1 8.896
116031 117.8242 -0.1050 9.0 195 9.213 8.850 350 9.3497
135178 117.8348 -2.0626 8.6 199 8.256 7.906 366 8.3489
116040 117.8938 0.3830 8.7 222 8.215 7.878 400 8.3967
GSC
---
GSC stars RA 117.4 to 117.999, decl -0.0 to -2.4999
Richmond .AST stars for same area, by Richmond number and .AST magnitude
(Radius R of 3.5 pixels).
Gutzwiller stars for same area, by magnitude
Gombert stars for same area, found via Richmond .AST and .PHT lists only,
by Gombert number and magnitude
GSC RA dec mag Richmond Gutzwiller Gombert (via Richmond)
GSC0483201258 117.5306 -0.3429 10.74 62 10.304 9.947 109 10.3989
GSC0483601452 117.5929 -2.2431 10.77 90 10.571 10.171 162 10.7619
GSC0483200773 117.6202 -1.3077 11.62 100 11.681 11.316 175 11.7486
GSC0483600053 117.6446 -2.0127 11.23 108 11.245 10.930 203 11.2856
GSC0483200475 117.6488 -1.6444 9.37 110 9.426 9.066 227 9.0574
GSC0483200400 117.6892 -0.0030 11.69 125 10.982 10.624 234 11.1109
GSC0483201504 117.7124 -0.9779 10.95 140 10.638 10.302 263 10.7166
GSC0483200700 117.7204 -0.6528 10.76 145 9.995 9.645 269 10.1181
GSC0483200544 117.9566 -0.6752 11.94 256 11.519 11.213 448 11.6452
GSC0483201812 117.9848 -0.3181 11.98 11.223
GSC0483600017 117.9922 -2.0378 10.00 268 10.362 10.012 476 10.4492
Other stats:
-----------
Richmond's list: 1400 stars (to #268 identified on GSC; #222 id'ed on SAO)
Gutzwiller's list: 2182 stars (to #388 identified on GSC; #322 id'ed on SAO)
Gombert's list: 2207 stars (to #476 identified on GSC; #400 id'ed on SAO)
No overlap for the 12 SAO and 11 GSC stars in this range of .6 degree RA
and 2.5 degrees in dec (1.5 degrees square).
Methods
-------
All files sorted by RA.
Catlog file (SAO, GSC) edited for stars of RA 117.X, stars out of dec
range removed from list.
Richmond .AST file manually searched for matching RA and dec to about +/- .02.
Gutzwiller file manually searched for matching RA and dec to about +/- .02.
(In most cases, the most adjacent stars are off by much more than this.)
Matching stars in Richmond .AST list found in Richmond .PHT list by
Richmond number; pixel address converted to Gombert pixel coordinates;
(add 1 to Richmond row address; add 15 to Richmond column address)
corresponding Gombert star found.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
*> I'd then appreciate if Sky and Tel would show less amateurs
*> pushing glass, and guiding nice astrophotos, and more amateurs
*> doing astronomy instead. If Sky and Tel is not showing the
*> way, then who's role is it ?
*> When the average John Doe starts astronomy, he looks in sky and tel
*> to see what the others are doing, and usually he does the same,
*> he starts looking at NGC0001 and stops at NGC9999, then photographs
*> the same. Hasn't done much astronomy in the end, and Sky and Tel
*> is ( to my opinion ) partly responsible of this state of
*> affairs.
As my uncle used to say, "don't blame the cow for sour milk". My
impression is that Sky and Tel (and Astronomy magazine also) is
following the popular trend in (American) astronomy: a growing public
interest due to major celestial events and upgrades to the Hubble Space
Telescope. The events (comets and Jupiter impacts) have increased interest
in observing, and general interests in astronmical stuff. The Hubble
repairs, and subsequent pretty pictures, have "raised the level" of
expectations for pretty astronomical pictures. Related events include
lunar and martian space probes, and the growing use of CCD cameras to
produce even *more* pretty pictures. Also, growing Web use by the
public as supported by NASA and HST Web sites with, again, lotsa pretty
pictures.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
*> Herb's point is well taken that the lack of good "standards" make it
*> difficult to make good photometric calibrations of TASS images. I have added
*> a "Tech Note" to the Dayton TASS Camera Home Page, as well as asking Michael
I'll read this most carefully. Thanks!
*> It looks like a few percent photometric accuracy should be possible
*> on a routine basis with careful calibration. The other star magnitudes in
*> the GSC/SAO catalogs are just not accurate enought (as Arne has pointed out
*> several times). This makes it very difficult to tell how accurate
*> photomertic magnitudes as being calculated in TASS images.
I presume this assumes that the seeing is consistent and clear for the length
of the run. I don't think the problem will be "calibrating" the camera,
although that also needs to be established over long periods. The problem
we won't have obvious data on, or control of, will be the less-than-perfect
skies. As amateurs, we can make a signifigant contribution in my opinion
if we can work around (or through) this. The professionals of course
simply throw out data from bad skies at otherwise perfect sites: we
don't have that luxury.
Herb Johnson
hjohnson@pluto.njcc.com
Mar 9, 1997
*> I have yet another request for folks writing the extraction programs.
*> You list the RA,DEC,x,y,mag, etc., but you should also include the UT or
*> JD for each object (since they are not identical). This is the only
*> way we can properly handle variable stars. The UT can be calculated by
*> using the beginning UT for the frame and adding the 0.91sec/row offset.
I don't want to argue, but if the UT can be easily calculated, then
why add it to the lists? It would have some error anyway, unless Tom
was very careful in recording the start of data collection; and unless
there is no odd drift or roundoff error in the timer used to shift the pixel
rows. [Incidently, how good IS that shift clock timer anyway, Tom? ;) ]
Shorter list files are better.
Chris Albertson
chrisa@wavenet.com
Mar 9, 1997
> *> I have yet another request for folks writing the extraction programs.
> *>You list the RA,DEC,x,y,mag, etc., but you should also include the UT or
> *>JD for each object (since they are not identical). This is the only
> *>way we can properly handle variable stars. The UT can be calculated by
> *>using the beginning UT for the frame and adding the 0.91sec/row offset.
>
> I don't want to argue, but if the UT can be easily calculated, then
> why add it to the lists? It would have some error anyway, unless Tom
> was very careful in recording the start of data collection; and unless
> there is no odd drift or roundoff error in the timer used to shift the pixel
> rows. [Incidently, how good IS that shift clock timer anyway, Tom? ;) ]
> Shorter list files are better.
Most Database Systems (even Microsoft Access) have the concept of a
"computed field" This is a kind of column that is derived as a function
of other data. Is is not stored on the disk but none the less may be
printed or even sorted or used as part of a selection criteria. It will
not be to long before these lists will be stored in databases rather
then
files when this happens you will have your UT column or maybe some
other column.
John Gwinner
gwinner@northnet.org
Mar 10, 1997
> *>I'd then appreciate if Sky and Tel would show less amateurs
> *>pushing glass,
>
> As my uncle used to say, "don't blame the cow for sour milk".
Interesting, as the ATM list generally feels that less attention is given
nowadays to making good optics, and instead the general lack of quality
optics in commercial scopes is ruining some amateur's experiences.
> As we report on our observations
> and how we do them, someone else will be inspired to do more careful
> work. That's how *I* got into all this. But we must all work harder to
> write up and report our results. Write a paper; give a talk; post
> results and methods on a Web page. Most astronomy clubs and Web sites
> are BEGGING for original work!
I generally don't see that much on what observatio