Michael Richmond
richmond@astro.princeton.edu
Feb 1, 1997
The US Naval Observatory has just released a gigantic new astrometric catalog, A1.0, which covers the entire sky. It is based on scans of several Schmidt-plate sky surveys, and includes stars down to close to the plate limit -- i.e. down to around 18 in red, 20 in blue.
Brian Skiff sent me a nice description of the catalog, so
let me quote him here:
As some of you may know, the U. S. Naval Observatory in Flagstaff has
produced a colossal star catalogue called "A1.0". The catalogue contains almost
500,000,000 detections, including stars, galaxies, etc. The data will not in
general be available except for scientific use, and cannot be used in
commercial applications. The general Web site describing the catalogue can
be found at:
The site includes links to two third-party search utilities, one from
Doug Mink at SAO/CfA and the other to the Lowell Observatory site.
Since Lowell Observatory folks will making use of the catalogue for
various purposes, Bruce Koehn of the Lowell staff has made a Web page with a
form for searching small areas of the A1.0 catalogue. The URL is:
http://asteroid.lowell.edu/cgi-bin/koehn/webnet
This is the top page for various asteroid-related products. Included is Ted
Bowell's 32,000+ asteroid orbital element database, asteroid search routines,
and other goodies. There is also a link to "refnet", which is the star
catalogue search form.
The search form includes access to the full A1.0, the "SA1.0" faint
astrometric subset (for use with small CCD fields, for instance), and also
the complete PPM catalogue (480,000 brighter stars). The search inputs
include RA/Dec, search area, magnitude, and so on; the output can be sorted
by RA, radius from search center, etc.
The output itself includes the A1.0 position (equinox 2000 at epoch of
the POSS-I blue plate used for the scans, i.e. about 1950-1955), the red and
blue magnitude, the radius from the search center, and the position angle. At
the moment the p.a. runs the wrong direction (i.e. sweeps around from north to
_west_), but this will get fixed eventually. The magnitudes have been adjusted
only very approximately, and possess zero-point errors of up to a couple of
magnitudes. The colors inferred from the red/blue magnitudes can likewise be
completely non-physical---I've found stars with "blue minus red" colors of -3
to -5, which cannot occur in the real world except in blue jeans and lapis
lazuli. I'm finding the blue magnitudes are closer to reality than the red
ones.
The form defaults to a search area 10 arcminutes square. Unles you are
well outside the Milky Way, this results in very long star lists. I would
advise changing this to at most 1'-3' (60 or 180 arcseconds on the form).
Like other catalogues built from scans of photographs, there are gaps
around bright stars (often including the bright star itself), bright galaxies,
bright globular clusters, etc., where the plates were simply black and the
star-finding algorithm couldn't operate. By "bright", I mean stars brighter
than mag. 10-12, and galaxies with total V magnitudes brighter than mag. 12
or so---stuff that's completely saturated on the Schmidt plates.
Have fun with it!
Tom Droege
droege@wwa.com
Feb 2, 1997
While I was taking a dark run, camera #7 just died. Norman's program just said, "I'm too hot" and turned off. I would prefer that it said "I'm too hot", made some terrible noise, turned off the second stage cooler (which is the only thing it can do to reduce the heat) and kept taking data. In this case, the camera has died and one is cut off from the only source of information one might have. Just a comment of philosophy of alarm systems.
It just happens that I was watching the temperature indication and so I knew it was not actually too hot. I just dug out the diagnostic program (tass1c.bas) and started looking. This program has a TEST and an ADCTst button that allows checking each of the channels into the ADC. The first thing to check is the +/- 5 volt power supplies. These read the correct +1.6 and - 1.6 volts. The temperatures both read something crazy like -80 C.
The temptation with a problem like this is to frantically change out all the parts for different ones. One can quickly shuffle so many different parts so that soon one has introduced 2 or 3 new troubles. I did my best to remain calm and tried to use my head. Eventually I found that the problem was due to a pin pulling out of the connector to the center camera. It just happened to be the +15 volt power that feeds both of the thermisters that are in the center camera. This caused the ADC to read 0 volts for these temperature sensors which is interpreted as a "very cold" temperature by the program. I guess Norman does not differentiate between very hot and very cold. Note that I had visually inspected the connectors through the inspection windows on the connector. It was not until I started pulling on each wire that I found the loose pin.
All this has a point. Glenn Gombert has told me that one of his runs shut down with an over temperature reading a few hours into a run. Norman, if you shut down on a single hot reading, you might cause a run to abort from a noise pulse. Like the refrigerator turning on at just the wrong time in the data cycle. As I imply above, there is no sense in stoping the program. There might be some useful diagnostics that result from later read out. Slowly watch as it melts down. I assume that we mostly won't be watching. I start a run and go to bed. Even if it made noise I would not hear it.
I would recommend a little more complicated strategy. Wait until a few successive readings confirm that it is really over temperature. Then set the TEC command to 1 Volts or so to turn off the second stage. Note that the temperature cannot jump suddenly. A quick back of the envelope computation indicates that about 0.1 C per second is about as fast as the water temperature can rise. This assumes dry running with the water just blown away somewhere. The CCD temperature can move a little faster, particularly with a backwards power supply connection. But a 1 degree change between readings is almost impossible.
All this is being improved on the Mark IV. I am designing so the computer can turn on the pump and the TEC power supply. At the moment I am pondering (Are you pondering what I am pondering Pinky?) how to prevent plugging the pump into the TEC power supply and vise - versa. I would like to use these with their factory plugs, but the solution may be just to put AN plugs on them with different shells.
Nick Barnes
nickb@harlequin.co.uk
Feb 3, 1997
> All this is being improved on the Mark IV. I am designing so the computer > can turn on the pump and the TEC power supply. At the moment I am pondering > (Are you pondering what I am pondering Pinky?) how to prevent plugging the > pump into the TEC power supply and vise - versa. I would like to use these > with their factory plugs, but the solution may be just to put AN plugs on > them with different shells.I suggest small daubs of differently coloured paint. Or daub one and leave the other undaubed.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 3, 1997
> All this has a point. Glenn Gombert has told me that one of his > runs shut down with an over temperature reading a few hours into a > run. Norman, if you shut down on a single hot reading, you might cause > a run to abort from a noise pulse. Like the refrigerator turning on > at just the wrong time in the data cycle. As I imply above, there > is no sense in stoping the program. There might be some useful > diagnostics that result from later read out. Slowly watch as it melts > down. I assume that we mostly won't be watching. I start a run and > go to bed. Even if it made noise I would not hear it.I would like to second Glenn's comment. We ran Camera #5 on Jan 29, (more to get oriented and to calibrate the system than to collect meaning data). In addition to showing us getting very close in the alignment, and imaging Mars (thus verifying our location (Dec wise), the data collection shut down due to a strange event. The program eventially shut down due to a temperature reading of 135 degrees (which I don't think actually happened.) The data curve at that point was just a momentary spike. The strange event was a sudden drop in CCD temperature and a complete saturation of the CCD array (all three arrays). It seems that the controller card had locked up somehow. We were able to rerun the program and it seemed to operate correctly.
> I would recommend a little more complicated strategy. Wait until a few > successive readings confirm that it is really over temperature. Then > set the TEC command to 1 Volts or so to turn off the second stage. Note > that the temperature cannot jump suddenly. A quick back of the envelope > computation indicates that about 0.1 C per second is about as fast as the > water temperature can rise. This assumes dry running with the water just > blown away somewhere. The CCD temperature can move a little faster, > particularly with a backwards power supply connection. But a 1 degree > change between readings is almost impossible.I am going to put two data files at storm, showing the frame when data collection went bad, and the frame (short one) when the system shut down. It show a sudden spike in temperature. The two files are called 0479983.FTS and 0479992.FTS and they are being put in the incoming directory. 0479992.FTS shows the spike in temperature.
I would like some comment (from anyone) as to what happened during the data collection. All three camera files are identical to this one. I think I should also point out, that it was getting light at this time (but the cameras did not see the sun!).
I did notice something rather odd when we imaged mars. The mars image was so bright, that we saw some effects in all three camera each time one of them passed in front of mars. The only time that did not happen was when it seemed to get a little cloudy. I will upload two image files a little later that show the effect.
Tom Droege
droege@wwa.com
Feb 3, 1997
On the subject of mis-mated plugs, you are talking to someone who has seen a 120 pin AN male connector mated to a 120 pin AN male connector up inside the wheel well of an S2F on a carrier deck. Since the only way this could have been done was standing on a ladder ane putting them together over ones heat it had to require the strength of a gorrila to do this. But it was done. Fortunately we discovered this on a pre flight check or there would have been one more order for Grumman for a replacement. A little paint does not even slow them down. It has to be easy and obvious.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 3, 1997
The APL-TASS observatory ran some test data on January 29, and we were fortunate to image Mars during the test run. I noticed that the flare from the image was visible on all three cameras. I'm not sure what might be causing that.
One posibility was due to the use of optical windows in the telescope housing. All three cameras imaged Mars, and on two of those cases, duplicate flares were seen in the other CCD images. The only time that did not occur was during poorer seeing conditions (slight clouds). We don't think there was a reflection path between the primary CCD (the one that saw Mars) an the CCD's. Is there a electrical or software path?
A comment on quality: We just moved the camera pointing angle up to 0 degrees DEC (it was 10 degrees low), and we have not yet adjusted VCO. We see that alignment on the two outer CCD's need some tweaking. A request to Tom: The alignment hardware has been a source of some difficulty. It has been very difficult to home in on the exact setting. If you are working up a similar arrangement for the Mark IV, please look at making a course and fine adjustment.
Glenn Gombert
ggombert@infinet.com
Feb 3, 1997
I have uploaded a TASS image (30T0478.642) to the 'incoming' area of storm.fnal.gov that shows an asteroid trial in the lower left hand corner. I thought that folks might find it interesting..
Glenn Gombert
ggombert@infinet.com
Feb 4, 1997
I have just uploaded to storm an image (M42V.tif) that was made using Software Bisques "TheSky" and "ImageLink". It shows part of the Belt of Orion area with a TASS Image overlayed with data from "TheSky". The variable stars in the image are identified with little "v's" and the suspected variable stars are identified with "v's" and a question mark "(?)". The variable stars are easy to identify in the TASS image. Once this is done it is easy to make differential photometric measurements using reference star(s) in the same image. This image was taken using a "V" band filter. This is the TASS imag showing the three stars in the Belt of Orion from the Dayton TASS Camera Home Page. I will try to post a "how-to" on this subject on the Dayton Home Page in the next few days.
I thought that this subject might be of interest as I seem to remember some "contest" that was discussed here in the last several days :-) :-) :-)...
Glenn Gombert
ggombert@infinet.com
Feb 5, 1997
I would like to "throw out" some ideas on TASS data analysis based on the "mountain" of data that I have collected here in Dayton and the lack of a "good solid" procedure for getting some good solid data analysis from all the data that has been collected. And see how this might pertain to Tom's "Variable Star Contest".
Due to the huge amount of data that is collected from one single TASS camera one easily sees the need for automated analysis of the data. This has been the focus of much of the effort by folks on the list for the last few month's . A lot good solid work has been done by a number of individuals, but few good solid measurements have been generated from all of the data that has been collected. I think that this probably has a discouraging effect on those people operating camera's who lack good solid techniques for getting results from the data that is collected.
It might make sense to "backup a step" and use more conventional methods to make differential photometric measurements from TASS images and compare these with published measurements for known stars, and then to use these measurements to validate the automated data reduction techniques that we are in the process of being developed. With the large field size of TASS images (3 X 3 square degrees) it will probably be relatively easy to find reference stars in each TASS image that is taken. It seems that perhaps making a number of measurements manually (from each TASS Image) using a known reference star(s) in each image as the basis for the measurements is a straight forward process and has been used successfully by amateurs for a number of years. Also getting in the habit of matching up TASS images with conventional star charts or sky atlas programs is probably a good thing to get in the habit of doing anyway.
The above is probably a good "first step" to compare automated measurements against as they are performed and probably be done on a regular basis. In regards to Tom's Variable Star contest it might be a good idea to make at least some of the measurements at each site using differential photometric techniques, especially if the data is going to be presented by Tom at the AAVSO meeting. These sort of measurements can then be used to verify more sophisticated automated measurements.
Several software packages exist to make differential photometric measurements from FITS format images which use reference stars in the image to compute the magnitude of "unknown" stars. Also many good "sky atlas" programs are in general use that allow TASS star image fields to be found along the path of 0 degree declination where most TASS images are taken. This also might serve as a good way to start to compare and correlate data that is taken at different TASS Camera sites.
The above represents some suggestions that I would like to "throw out" for consideration, they are based on proven techniques for making differential photometric measurements. This is what I plan to do for the next several months here in Dayton as well as to contiune the development of automated technqiues. Hopefully this will help in the overall analysis efforts as well as enable lots of good variable star measurements to be collected as well.
Tom Droege
droege@wwa.com
Feb 5, 1997
> As a first thought, it seems to me that the winner will almost by > definition have fairly good equipment already. If you are designing a > contest, why not design one such that the winners will get something they > very much NEED, rather than something that only > improves opon what they already HAVE?The purpose of all this is to start a serious measurement program that will result in a larger variable star catalog. The winner most likely will not have a camera of the quality I plan to offer as a prize. The contest is a test to see that the winner is seriously interested in the science to be done. The proposed prize is equal 30 tass cameras in chip area and to 11 in pixels. So it is a large step in performance.
I also plan to have two divisions. One for tass camera holders and one for people running with LX-200s and the like.
Tom Droege
droege@wwa.com
Feb 5, 1997
> I think that you actually might possibley make TWO different > catagories of awards (not necessarily with the same prizes) the first is for > the number of variable star observatoions, the second might be for > "technical achivement"... That is the most inovative, additions to the TASS > data analysis suite of tools over the next two months. It could we be used > for the contest of course but would be of benifit to the overall TASS > efforts in helping to process the mountain of data that is going to result, > both now and in the future.... > > You of course would make the determination of how all this adds to > the TASS effort.First I want to point out that this is a "measurement" contest and not a variable star finding contest. The idea is to publish something as close to the raw data as possible. The raw data is just too large. So I am asking for measurements and the proceedure used to make them. Later someone can use this data to do a scholarly analysis looking for variable stars and other interesting stuff.
I tried to cover Glenn's "technical achivement" comment below with my section 7)
>> 7) This is intended to be a friendly and cooperative competition. All >> are encouraged to freely exchange their measurement techniques and >> software. The Management reserves the right to award more than one >> camera system if heroic work is detected.I am in fact going into production on the Mark IV cameras. We will find a way to get one to everyone that is willing to do the work required and has a sustained interest in this topic. The contest is just a way to sort this out. If it works, we will probably run one every year until we have a network that can measure everything and detect earth colliding asteroids. I figure that this will take about 100 years.
Tom Droege
droege@wwa.com
Feb 5, 1997
I tried to clean up storm incoming last night and found that I did not have the necessary permision. I believe this has now been changed so that anyone can write and delete files in storm/incoming.
I would like to ask you all to police your own files. It is fine to leave stuff there for a while, but I don't want to attract attention by filling the disk of a computer that is being made available as a courtesy to me.
Tom Droege
droege@wwa.com
Feb 5, 1997
Chris Albertson commented to Tom about the contest...
> you could make life easyer for yourself if you required anyone > accepting data to pass that data on to another person if requested. > This could cut your work by at least half. I have almost stoped > thinking about analysis for lack of a steady source of data to > analyse. This could get me working again, well after that client/ > server stuff goes out the door to Norman.Good, I like your idea about passing on the data. I will send the tass home base data to the first person that asks for it, under the condition that he pass it on to the next person that asks ...
> One more comment: It would be good if the lists where written out > in FITS table format. This is good because it is self documentingI agree with your FITS format for data. I was about to send mail to our resident FITS expert, Jure Skvarc, to see if he wants to take on the job of the format specification. Are you listening Jure?
> If you call this "raw data" then I agree it does not > need to be further processed but it is unpublishable most places. > > If it where processed to corelate multiple measurements of stars and > to assign catalog numbers to stars then it would be more usful to > others. Well maybe in 1999?As to how to format the catalog. I have mixed feelings. If we muck about with it too much, then it may not be possible to unfold it back to the raw data. For example, how will one decide that two measurements are of the same star? It may not be so easy. Various analyzers may want to make different cuts. This is a good point for discussion by the resident professionals??? I think I lean as stated. We publish measurements by observer, with a full disclosure of what was done to process the raw data to a star/ magnitude list.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 6, 1997
Of course, I can try to write a specification for output files. I understand from your post that Chris has written some wider proposal what to do. You cite a part of his message, but I could not find the original in my mailbox. Probably it was sent directly to you only. It would help me a lot if you (or Chris) forward it to me.
One more thing. Some time ago I proposed that we establish a small library of test images so people could test and compare their software on them. I think we still need this, located on some permanent location. If disk space is a problem, I think I could find 100 MB or so on one of computers here. However, do not expect fast data transfer.
Tom Droege
droege@FNAL.GOV
Feb 6, 1997
We can still use Storm as a relay point as long as we don't let the files grow without bound. I think we are good for 50 Mb or so. It will move in about a month, but I think it will be available for the next year. After that, I hope to have a site set up at Princeton. We are presently working on a proposal which would provide for this.
It appears that I was successful in getting the permission set up so anyone can load and delete files in storm/incoming. This will require some discipline. Possibly one of you can take on the job of managing the files there, cataloging them, and deleting the obsolete stuff.
Chris, can you send Jure your ideas on the contest FITS format?
Michael Richmond
richmond@astro.princeton.edu
Feb 6, 1997
I can offer several hundred MBytes of disk space on a machine with good Internet connections, so people who wish to donate images to an "Image Library", please contact me directly.
It strikes me that the library will be more useful, the more annotated each image is ...
Jure Skvarc
SKVARC@eros.ijs.si
Feb 7, 1997
OK, I will think about FITS tables and output files during this weekend and then post my conclusions.
Michael Richmond
richmond@astro.princeton.edu
Feb 7, 1997
Glenn Gombert is planning to use his camera to make "conventional" differential measurements of a few variable stars per TASS image, rather than trying to deal with hundreds of stars at once. He asked me some questions, and it seems to me that others may be interested in the answers. Oh, and if I send material to the TASS mailing list, it is archived for future reference, so I don't have to re-type it :-)
If you want to do differential photometry, it would be _best_ to include a star of known brightness, to set the zero point properly. As you point out, the Landolt stars are too sparsely scattered to appear in any image on the equator.
If you want to _try_ including stars of known brightness, you could check to see if one of the Landolt stars, or one of the stars from Skiff's complilation
http://www.astro.princeton.edu/~richmond/tass/refs/skiff_photom.html
just happens to appear in your field. If so, fine!
Whether or not there _is_ a star of known magnitude in your field, you should choose more than one "standard" per field. If you include 5-10 "standards", you can check to make sure that no "standard" is itself a variable; you also can measure the precision of your measurements by calculating the internal scatter among the "standards".
By choosing "standards" which span the width of an image, you will notice if variation in the PSF across the frame causes any change in precision; by choosing standards which span the length of an image, you can check for variation induced by changes in the sky brightness or transparency (all this assumes that you make measurements of these "standards" on a large set of different frames).
It is good practice to make sure that at least 2 "standards" are close to the target star, so that they should have roughly the same sky background and PSF.
Well, this depends on your goal. If you are studying a star which is known to vary by several magnitudes (like Mira), then a precision of 0.1 magnitude may be fine and dandy for your purposes. If you want to measure variations in a star which is known to have a tiny amplitude, you'll need even tinier errors.
So, decide on your goal, and act accordingly. Perhaps you might start out by including ALL the stars, even the faint ones with big errorbars. After several days/weeks/months, you might assess your work, and decide that you really want measurements with errors smaller than X percent; well, you can throw out all the others. It's harder to go in the other direction :-)
TASS Technical Note #19 describes some measurements I made of stars in fields with known standards; comparing my measurements to each other, and to the known standards, both yielded about 5% accuracy for stars brighter than V=12. I suspect one can do a bit better.
Even if MOST of your images don't include any known standard stars, I plead with observers to include at least a FEW fields with known stars. By comparing your magnitudes to the standard ones, you can
Yes, I have :-) This is an excellent point, and a source of worry. But there _is_ something you can do; by following the plea in item 3 above -- taking images of some Landolt fields -- you can at least check your V magnitudes to see if they vary significantly with stellar color. If you discover that, indeed, redder stars are systematically brighter than bluer stars in V, you at least KNOW the problem exists, and you have some idea for the SIZE of the problem.
Famous last words: I plan to make an observing run next weekend. Just watch a giant storm system cover the Northeastern US from Feb 13-17 :-)
Herb Johnson
hjohnson@pluto.njcc.com
Feb 7, 1997
I now have more time for TASS stuff. I like asteroids...
Glenn (?) recently offerred a TASS image which included a trail of an asteroid. I downloaded it (via a pointer on the TASS site, thanks Michael!). Since I don't have reliable FITS viewers around, I've exhumed a old program of mine to create .gif files, and I modified it to convert the file to .gif in order to display the "asteroid" image file on my MS-DOS/Windows system. Doing this "cold", I'm not up on all the background of TASS image format. But the file appears to have been processed by another program to create a FITS file. My questions and comments may be instructive so I'll post them.
It appears to have a FITS like header which is correct, sort of. It would seem that the data in the file has an offset of around 0xAB00 rather than 0x8000 (32768); or the sky background is signifigant! I was able to "image" the file sufficiently to see the apparent asteroid trail in the lower right hand portion of the screen. Unfortunately it goes off the edge of the field of view.
Knowing when the scan initially imaged that portion of sky, you could determine location. Knowing the rate of pixel advance (the column clock rate), and the angular size of the pixel row, you could determine sidereal rate of motion. With the raw data and knowledge of ADU count vs magnitude, and allowing for the integration across the observed path, you could regenerate the average magnitude. Monitoring the ADU's pixel by pixel, you can monitor the magnitude per scan time, to see if there is a cyclic rate of rotation. I'd have to do my homework on the Mark III constants (not included in this file's header) to obtain these values, presuming the data in this file is not "processed". Is the raw TASS file available with this other data I've mentioned, including observation times? Are the stars identified in the field near the asteroid? Etc.
An interesting note is that the asteroid apparently went near or across a star: such information is very useful for asteroid orbit determination. That bit is beyond me, but others can do that better than I. This would call for knowing the site's geographic location. Given the long interval of pixel clocks (tens of seconds as I recall), unfortunately any occultation shadow information would not be resolved: you can't likely determine the diameter of the asteroid with a Mark III camera!
Neat, eh?
Bill Dillon
bdillon@houston.geoquest.slb.com
Feb 7, 1997
Herb Johnson wrote in part:
>I now have more time for TASS stuff. I like asteroids... > > An interesting note is that the asteroid apparently went near or across a > star: such information is very useful for asteroid orbit determination. > That bit is beyond me, but others can do that better than I.
I like asteroids too, and have an account with the Minor Planet Center. If you can supply the time and RA and Dec, I can identify which asteroid it was (and how bright it was suppose to be).
Norman Molhant
molhant@ERE.UMontreal.CA
Feb 7, 1997
I have again some time to put on the LINUX version of the data collection program, so I'm back at work on that still buggy piece of software.
Chris, did you finish the client/server code, and if so, where can I download it from? If you haven't, don't worry, I have found some sample client/server code I could use instead... although it is on paper. :-(
Herbert wrote:
> Glenn (?) recently offerred a TASS image which included a trail of an > asteroid. > ... > But the file appears to have been processed by another program to create > a FITS file.Which program appears to have somehow removed most of the important FITS header data. Why, Glenn?
> It appears to have a FITS like header which is correct, sort of. > It would seem that the data in the file has an offset of around > 0xAB00 rather than 0x8000 (32768); or the sky background is signifigant!Glenn?
> Knowing when the scan initially imaged that portion of sky, you could > determine location. > Knowing the rate of pixel advance (the column clock rate), and the angular > size of the pixel row, you could determine sidereal rate of motion.All these infos were in the raw data file header.
> With the raw data and knowledge of ADU count vs magnitude, and allowing > for the integration across the observed path, you could regenerate the > average magnitude. > Monitoring the ADU's pixel by pixel, you can monitor the magnitude per > scan time, to see if there is a cyclic rate of rotation. > I'd have to do my homework on the Mark III constants (not included in > this file's header) to obtain these values, presuming the data in this > file is not "processed".What kind of processing was done on it, Glenn? Nice image, by the way.
> Is the raw TASS file available with this other data I've mentioned, > including observation times? > Are the stars identified in the field near the asteroid? > Etc.
> An interesting note is that the asteroid apparently went near or across a > star: such information is very useful for asteroid orbit determination. > That bit is beyond me, but others can do that better than I. > This would call for knowing the site's geographic location.Which info was also included in the raw data file header.
> Given the long interval of pixel clocks (tens of seconds as I recall),No, it's a tad below one second per row.
> unfortunately any occultation shadow information would not be resolved: > you can't likely determine the diameter of the asteroid with a Mark III > camera!In fact, you could, if you were driving the row clock too fast, so as to get trailed stars: the star trail and the asteroid trail would cross over a number of rows, with a dip in the amplitude of the pixels where the asteroid did occult the star. You could, for instance, drive the CCD at twice the sidereal rate, thus getting a bit less than 0.5 seconds per row and enabling you to time the occultation down to better than half a second. This would, however, require comparing the trailed image with an untrailed one taken at the same time, hence using two Mark III cameras together.
> Neat, eh?Indeed!
Glenn Gombert
ggombert@infinet.com
Feb 7, 1997
The file was processed (dark-frame subtracted) with a "beta-test" version of CCDSoft it is Software Bisques new 32 bit image processing program that I have been Beta testing. It does destory most of the information in the FITS header. I have talked to Tom Bisque about this and they are going to fix the problem before it is released to production.
Having said that I can try and locate the source image again if it is of interest and reload it onto Storm. (I just cleaned a number of files off of there per Tom's request)
Glenn Gombert
ggombert@infinet.com
Feb 7, 1997
For Herb (and all those that may lack a good DOS FITS viewer) I can recommend Herb Raab's Astrometric Program that can be found at:
http://mars.planet.co.at/lag/astrometrica/astrometrica.html
It does quite a nice job of diplaying TASS FITS images as well as being able to perform simple scaling as well as blinking several images together.
It also has a very handy feature that you can plot a selected region from the Hubble Guide Star Catalog by specifiying a center RA and DEC and a field size. Once the region is plotted it can be rotated and scaled to match the comparison ccd image. All VERY useful for identifying the exact fields that TASS images are taken from.
The program is normally used to supply asteriod observations to the Minor Planet Center. It is shareware and can be downloaded (along with instructions) from Herb's Home Page. If you use it regularly (like it do mine) Herb asks for a $25.00 fee to become an "offical" registered user.
All in all it serves as a good basic program for viewing and doing basic analysis of TASS images.
Herb Johnson
hjohnson@pluto.njcc.com
Feb 8, 1997
*>> Glenn (?) recently offerred a TASS image which included a trail of an *>> asteroid.Apparently this image is reprocessed TASS data, and Glenn has addressed this in a subsequent message. Glenn will hopefully have the original image and data. I appreciate that he's offerred the image to gauge interest. I hope he has the original data on hand, I'd like to do things with it as I suggested.
*>> unfortunately any occultation shadow information would not be resolved: *>> you can't likely determine the diameter of the asteroid with a Mark III *>> camera! *> *> In fact, you could, if you were driving the row clock too fast, so as to *> get trailed stars...Point being, if the TASS camera did not follow the sidereal rate, you'd have many more exposures of the asteroid. However, it would be lost in the star trails unless it were in relative motion at some angle to the equinox (i.e. the earth's plane of rotation). The Mark III camera's intention is long exposures of a broad path of sky. Certainly, other "missions" for it make sense to me. I suggested as much for the Mark IV recently. I'm getting "itchy" to do some asteroid observing for myself!
Tom Droege
droege@wwa.com
Feb 8, 1997
I should remind everyone that one sees lots of these trails. Every evening and morning I get a few from satelites. There is also one from time to time in the middle of the night. Then there is the airplane, not always so bright. People who want to look at moving stuff will not be disappointed. But I think moving stuff is harder to sort out. I guess everything is hard. For variable stars one must be much better calibrated. I guess we will also see meteors.
That is why I am so interested in doing this. There is lots of stuff to see, and not many are looking.
Glenn Gombert
ggombert@infinet.com
Feb 8, 1997
I uploaded the "asteroid" image again to storm.fnal.gov: 30t0478.642 It is the "raw" image without any processing done to it so the header data should be intact. It has not been dark-frame subtracted. As Tom pointed out it may not be a asteroid but it seems to be an interesting image to anayze since there is obveously something moving in the frame.
Glenn Gombert
ggombert@infinet.com
Feb 9, 1997
I just uploaded to Storm a "finder chart" that shows where Brian Skiff's standard field stars are located with respect to the zero degree declination angle that the TASS camera's image along. It is called "skiff.prn" and should be able to be printed on any laser / inkjet printer. It is meant to be "copied" to the printer output to be printed. As can be seen, it looks like there should be enough standard field stars along the line of zero degree declination to get some idea of the photometric qualities of each TASS camera.
I also create a "sky database" containing the information from Brian's list if anyone is interested I can upload it as well. You would need "TheSky" Level IV software to be able to use it.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 10, 1997
Recently Tom announced a contest which purpose is, as far as I can see, to encourage people to actually build databases of star data obtained by CCD cameras and image analysis software. Chris proposed to (loosely) define some format in which the information is stored. Indeed, without some definitions one could hardly guess what those files actually mean and it is rather difficult to imagine how would data about individual stars be extracted. I started to build an outline of output file format which would be useful not only for the purposes of the contest but also for regular TASS operation. So, here it goes:
This message is about output files produced by image analysis programs. The basic content of output files will be a list of objects found on images produced by CCD cameras. There will be some additional information to make observations useful for TASS purposes. The final destination of objects will be some database. The format of files should be FITS using tables.
To simplify matters, let's exclude from output files any extended objects: galaxies, star clusters, the Moon, the Sun, mother ships, birds, as well as trails from planes, satellites and meteorites. This leaves us mostly with stars and asteroids.
All objects coming from the same image share a lot of information. I will name at least some of them:
It seems that items under a) are quite essential and should be included in every output file and items under b) can be useful but are not so critical. Most of these information is already present in the original image file (by "the original image file" I mean a file taken by image analysis program, not a file produced by aquisition program). Image code should unambiguously identify image. The best place for all the information above is in a FITS header.
As far as I can see, there are only few values specific for every object in the list. They are:
This can be very important and useful, although it is possible to live without it. By ID I mean star numbers from catalogues (such as PPM or GUIDE) and asteroid designations.
These three numbers exist for every object at some moment during the image analysis. In a long run they may provide useful information. For example, it may turn out that all objects from camera 5 and x-coordinate range between 100 and 200 have their brightness 0.5 magnitude lower than for other coordinates.
These two are also useful but I am not so sure whether it is possible to give some reliable estimates for every individual measurement. All in all, only the first four values (RA, DEC, MAG and image code) need to be present, others are optional.
So, with this definition we can build a FITS file containing all of the measurements from a single image. But we want to have a database of all measurements. Since we still don't have any suitable database program working for us I propose two possible provisional solutions.
The first is to do nothing: each output file can be treated as a large record. If somebody wants to search for certain objects, he has to check coordinate range given in every FITS header and proceed with search only if wanted object falls in this range. (It may be a good idea to sort records in every file according to magnitude).
The second is to make a primitive database consisting of two (types of) files: one with image descriptions from FITS headers and another with object information as defined above. Files would be in plain ASCII, with comma delimited fields and newline delimited records. I guess that many database programs would take this and it would be easy to write a perl or awk program to manipulate with data. With the second solution we loose flexibility of FITS but we gain flexibility of simple ASCII, what is not negligible.
This message is already too long so I will conclude for now. The basic idea here is that all the people who have image analysis programs should adapt them to output their results as a FITS file or write a filter program which will transform program output to FITS. Detailed format with keywords will be defined after we come to some agreement about the database fields proposed here. I welcome your suggestions and comments.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 10, 1997
I have some concerns about data quality TASS cameras will produce, especially about photometry. Mark III has rather large field of view and it is quite likely that some gradient of camera sensitivity occurs because of clouds and maybe other reasons. I think we should take term "data reduction" quite literally and reduce the amount of data by throwing away images if we have any reason to believe that photometry can not be done up to some standard we define. Currently I don't see how is it possible to do any acurate photometry without comparing reference stars from the image with those from some catalog. So, I propose to reject every image where comparison of reference stars gives too large a discrepancy or where it is not possible to do a comparison. The amount of data produced by TASS, although reduced, will still be large but the quality will be highly increased.
Glenn Gombert
ggombert@infinet.com
Feb 10, 1997
I think that you point is well taken, however if we perform "differential photometry" then the check and reference stars should have roughtly the same magnitudes if taken from the same frame of data the results should not be too bad. With the large pixel sizes for Mark III the limit of accuracy is probably about 5% or so. this agrees with TASS Technical Note #19 written by Michael Richmond. I have been doing some differential photometry on several TASS images today and have been able to get reasonable results down to about 13.5 magnitdue with the tools that I have been using. After that the stars are difficult to accuratley identify and the photometric results become much more uncertian. But using differnetial techniques helps to minimize the variaition from one TASS frame to the next..
Martin Pittinger
PittiMJ1@central.ssd.jhuapl.edu
Feb 10, 1997
I uploaded an image of a jet trail (Feb. 4) to STORM (Jet.fts) and a text file w/ information (jet.txt) about this image.
It appears that the sharp horizontal line at the end of the trial seems unusual for an asteroid. I've seen the same feature for jet trails (Re. Jet.fts), especially near-by jets.
I hope this information helps with the determination of this object.
Herb Johnson
hjohnson@pluto.njcc.com
Feb 10, 1997
*> ...because of clouds and maybe other reasons. I think we should take *> term "data reduction" quite literally and reduce the amount of data by *> throwing away images if we have any reason to believe that photometry *> can not be done up to some standard we define..... *> Jure Skvarc
While this is a reasonable consideration, it ignores the possibility of DETECTING events and objects, even if they cannot be resolved photometrically to a given level of resolution. I suspect in the end data archiving is limited by a site's capacity to both collect and archive data. Perhaps other sites can be found to retain "discarded" data for later analysis. Meanwhile off-line storage costs (tapes, CD's, etc.) drop by the month.
Establishing standards, however, is valuable in its own right. One issue is the ability to "qualify" a given TASS image to some level of consistancy and quality. The unique problem of the Mark III camera is that parts of the image are progressively "older" and may suffer from changing sky effects; rather than representing a literal "snapshot" of the sky. Other than monitoring the sky background and standard stars (which begs the question during the star recognition process), how do we know the "state of the sky" at any point of the image?
Glenn Gombert
ggombert@infinet.com
Feb 10, 1997
I just created a "skiff.gif" file and uploaded it to Storm with the same information, hopefully folks will be able to read it OK. The "prn" file wasn't a good choice for people to be able to read.....
Chris Albertson
chrisa@wavenet.com
Feb 10, 1997
Norman,
I put a snapshot of the client/server code on ftp.logicon.com/open/chris/Sockets.tgz
I resisted the temptation to clean it up before posting it. In fact some files may not even compile. I use RCS for revision control and have included the RCS directory, so you also have all previous versions of all my files. I have had the system up and running but went through another round of adding features and as of now am not finished.
You can look at what I have and we can talk about what to do next. I do intend to finish this. I can work on the part you need first first. Let my know what that is.
I could also do testing here. How hard would it be to create a test version of your linux kernel driver that always returns a constant or some other kind of test patern. It would at least let me test everything downstream of where you introduced the test patern and could let work on a client start sooner.
Tom Droege
droege@wwa.com
Feb 11, 1997
My computer is moving today at Fermilab. Best that you contact me at droege@wwa.com until I say I am back up.
There is more evidence that the mail list is cranky. If you make a post and don't see it echo to you, then try again. I have no better solution at this time. We hope to solve this in the future by moving the whole thing to a University some where.
Arne Henden
aah@nofs.navy.mil
Feb 11, 1997
Jure raised the question regarding photometry through clouds, and Glenn correctly replied that differential techniques can be used. With our FASTT telescope/drift scan, we can do reasonable (2percent) photometry under pretty awful conditions. Unlike a stare-mode frame, the drift scan frames are not exposed at exactly the same time and you do suffer some sky extinction problems along the strip. However, if you select your comparison stars nearby the program object, they do have almost simultaneous exposures and the ensemble gives a good differential value.
As far as photometric standards are concerned, I am willing to both cull the literature (such as the Mermillod catalog) and take extra VI data to generate a set of 8-12mag standards along the equator for the proposed 'contest'. This can also be used as a calibration set for learning the proper techniques for drift-scan photometry.
As far as using the TASS cameras for variable star work, since the images are pretty rotten you actually might do pretty well in uncrowded regions. I would not be surprised if 2-3percent photometry were possible in these cases. We certainly do better than that with the 8" FASTT telescope. As part of my variable star survey along the equator, I have many new large-amplitude variables such as Miras that could be used as test cases. Even 10percent photometry is useful for these stars since their amplitudes are large and what you are primarily looking for are periods, light curve shapes and color changes during the pulsational cycle. If anyone is interested in these, I can provide coordinates, a rough idea of magnitude and period, and finding charts.
Glenn Gombert
ggombert@infinet.com
Feb 11, 1997
After a short conversation with Tom he felt that we should stay focused on automated measurements from TASS images (and not try to make manual measuremnts). This is especially true since the next generation of cameras's will collect a LOT more data and any type of manual measurements would be counter-productive (except perhaps to calibrate the measurements that are made using automated techniques)....
Over the weekend I was able to get precise center of the field locations for 10-11 TASS images and also measure (manually) several stars in each image. This will be very useful for calibrating the output from several of the programs that are used to produce automated star lists. It does not appear to be an objective of the "contest" to measure specific variables in the images but to calibrate (RA, DEC, and magnitude) measuremnts that are made from the TASS camera images. And to perhaps to quantify (with some sort of error-term) the magnitude estimates made from automated means.
Perhaps Tom could further expand on the above and help use to use the "contest" to further the TASS data reduction techniques to the greatest extent possible in the next several month's.
Arne Henden
aah@nofs.navy.mil
Feb 12, 1997
It is often better to walk before learning how to run. I'd suggest working with 'constant' stars at this stage of the game and make sure that you can do repeatable photometry on them. That gives you a handle on how well you can do photometry on various parts of the chips and under varying sky conditions.
The Landolt standards tend to be faint and often in crowded regions. Due to our drift-scan survey for variable stars, I have R-band photometry on some 1M stars near the equator, and can search the database to locate a subset that (1) are constant; (2) are reasonably bright, like V=9-10; (3) are in uncrowded regions. I'd suggest picking a half-dozen regions along the equator and providing several stars in each region. That gives you an idea as to repeatability for isolated stars, and also how well you can do differential photometry in a smaller area.
If there is interest in this exercise, I'll generate the list and post it on Mike Richmond's web site.
Ed. note: the list now appears under the Catalogs section of the TASS home page. MWR, Feb 14, 1997
Glenn Gombert
ggombert@infinet.com
Feb 11, 1997
Well... I think that I have made a major beakthrough tonight in being able to measure PRECISE astrometric and photometric properties from TASS Images (or any other ccd image for that matter) and do this in an (almost) automated fashion. Tonight I was able to determine how to calibrate the new version of the "Sextractor" program to give VERY precise photometric measurements from ccd images by "tuning" the "magzero_point" parameter in the configuration file.
The test image that I used was an image of NGC891 taken with a SBIG ST-6 and a 16 inch F/4.5 Newtonian telescope. The brightest star in the image was "GSC 2839:969" which had a GSC magnitude of 10.1 the measured magnitude from Sextractor was "10.3033". The faintest star in the image (that was found in the GSC data) was GSC 2839:302 with a HGSC magnitude of "14.9" the MEASURED magnitude from Sextractor was "14.9040". Right on the money! About 15 - 20 other stars in the image were compared with similar results the magnitude was usually within +/- 0.2 magnitude. With better reference stars and more careful calibration I am sure that better results can be obtained! All these measurements were made automatically once the parameter file was set up correctly. This should allow a whole nights run of TASS images to be processed AUTOMATICALLY once the appropriate parameters have been set up.
The procedure that I have come up with is outlined below:
That's it! The procedure that I have outlined above works and the only thing that costs $$ is Software Bisques "TheSky" program. The rest of the programs can be downloaded with links from the TASS Home Page. I hope to repeat the same procedure with a TASS image in the next day or two and post the results on Storm for people to review.......
Glenn Gombert
ggombert@infinet.com
Feb 12, 1997
I just uploaded to Storm an example image and catalog output from my first attempt at TASS Photometry using the method that I described in the eariler message. The image that I uploaded was 31t0457.636 and the photometric catalog that was generated was 1t457636.cat. In the Star-List are 8-10 GSC and SAO Stars and their GSC Magnitudes for comparison purposes. This is the first time that I have tried this with a TASS Image and the results don't look to bad. I am sure with more careful calibration much better results could be obtained. I left the X / Y posiitons (not RA and DEC) so folks could relate the photometic measurements to the image for comparison purposes. I will try and upload a better example over the weekend.....
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
Glenn wrote that he was getting +-0.2mag for photometry off of his TASS image of NGC891. While he considers this precise photometry, Mike has indicated that 5percent (0.05mag) photometry is possible, and my experience with drift scan systems sez that 0.01mag precision is within the realm. I think the major part of your error is in using the GSC magnitudes, since these are photographic and have +-0.3mag precision at best. I would repeat the same exercise for one of the Landolt fields. Still, the goal is fully automated results and your solution is certainly one approach that shows promise!
You didn't report the astrometric precision. Depending on the image profile, you should be able to achieve 0.05 pixel centroiding accuracy, or something around 0.5-1.0arcsec if you use a fair reference frame of GSC or higher accuracy stars.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 13, 1997
Calibration work is continuing on the APL TASS camera (#5). The last run we made (Feb 9) shows some continuing alighment, and VCO problems with CCD0 and CCD2. Based on the star charts, we determined that the centerpoint in Declination for the three camera were:
CCD0 -0 deg, 2 min, 59.97 sec CCD1 0 deg, 19 min 19.73 sec CCD2 1 deg, 29 min 50.79 secThese numbers are derived from slightly out of focus, with VCO problem images, so they may be inaccurate. We are showing CCD2 as pointing more than 1 degree above the other camera. Tom can you suggest any adjustment that we can use to fix this problem?
CCD1 shows the cleanest results, with CCD0 and CCD2 requiring additional adjustment for alignment.
We will be reporting on more results from the Feb 9 run.
Tom Droege
droege@wwa.com
Feb 13, 1997
Nick asks how to align the cameras in declination. My original plan was to shim them. On the roughly three inch base, A one mil shim should be about a minute of arc. Just slip a shim between the mounting plate and the bar below. Possibly washers under the screws.
One might ask, why care? Just take data where they are pointing. This will result in a distribution of the tass data. Since most cameras will cover the equator, we will get a lot of measurements there. Out at the wings there may be only one camera looking and we will get less data - but of different objects. Might be a good plan to understand what we want to do in the future.
What does everyone think???
Tom Droege
droege@wwa.com
Feb 13, 1997
I wonder if I could get a show of hands from those that are interested in entering the camera contest with the present rules. So far, I don't feel I have a strong response. I have been thinking instead to offer the prize for the first person to submit a public domain program that takes a data file and Norman's log file and automatically processes a star list from it.
Since Glenn has been working on this using a piece of commercial code (The Sky) I think it would be OK with me if this is not too expensive.
What do you all think? So far I have been mostly underwhealmed by the response.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
I have been working on just such a public domain program myself. Actually the "star" program I published at the Cincinnati TASS site has all the steps with the exception of matching x and y to RA and Dec. I hope to fold in Michael's "match" program to the next verion of "star" to provide the last piece. I will enter my data into the contest as soon as that last piece is in place.
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
> One might ask, why care? Just take data where they are pointing. This will > result in a distribution of the tass data. Since most cameras will cover > the equator, we will get a lot of measurements there. Out at the wings there > may be only one camera looking and we will get less data - but of different > objects. Might be a good plan to understand what we want to do in the > future.Correct me if I am wrong in the following statements -- I certainly have not been as deeply involved as the rest of you!
My assumption was that two cameras used I-band filters so that false detections could be removed (if not seen in both images). One camera used a V-band filter so that you then had two colors, and therefore a color index, for all objects. This being the case, then you would want all three cameras to see the same strip. Errors of an arcmin or so only affects the outer few columns, but you want this loss to be as small as possible. Likewise, if you all intend to scan the same region (namely the equator), then I'd suggest that all TASS systems would be aligned to the same central declination as well to maximize the overlap.
I haven't seen any description of rotational alignment (so that stars track down the same column)...I'm sure its there, but someone might enlighten me off-line.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
> Glenn wrote that he was getting +-0.2mag for photometry off of his TASS > image of NGC891. While he considers this precise photometry, Mike has > indicated that 5percent (0.05mag) photometry is possible, and my > experience with drift scan systems sez that 0.01mag precision is within > the realm. > I think the major part of your error is in using the GSC magnitudes, since > these are photographic and have +-0.3mag precision at best. I would > repeat the same exercise for one of the Landolt fields. Still, the goal > is fully automated results and your solution is certainly one approach > that shows promise! > You didn't report the astrometric precision. Depending on the image > profile, you should be able to achieve 0.05 pixel centroiding accuracy, or > something around 0.5-1.0arcsec if you use a fair reference frame of GSC or > higher accuracy stars.
I have done a little hand matching of stars in the images I have acquired to date. The best I've done is about 0.015 mag from one night to the next for the same camera. For different cameras with the "same" filter this degrades to about 0.020 mag. I'm getting about 0.15 pixel position errors.
These values are all for relatively bright (mag 8-9) stars. The photometric values are all differential measurements.
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
I wrote:
> Glenn wrote that he was getting +-0.2mag for photometry off of his TASS > image of NGC891. While he considers this precise photometry, Mike has > indicated that 5percent (0.05mag) photometry is possible, and my > experience with drift scan systems sez that 0.01mag precision is withinThen Michael Gutzwiller wrote:
> I have done a little hand matching of stars in the images I have acquired > to date. The best I've done is about 0.015 mag from one night to the next > for the same camera. For different cameras with the "same" filter this > degrades to about 0.020 mag. I'm getting about 0.15 pixel position errors.Sorry -- I was referring to Michael Richmond and TN # 19, not any results that Michael Gutzwiller has achieved. Please excuse any confusion that my 'Mike' comment may have caused. Gutzwiller is getting close to the number that we get with the FASTT telescope, with the exception of degraded centroiding. This may be due to the different image profiles between our telescope and the TASS cameras, or it may be due to different centroiding algorithms. How are these positional errors calculated? Differentially between common stars in two frames, or from an astrometric catalog, or just the sigma of the fit in the centroiding?
Glenn Gombert
ggombert@infinet.com
Feb 13, 1997
"Count me in" either way I would be interested in the "contest" whichever way you would like to run it. When you mentioned a "star list" I assume that you mean RA, DEC and Stellar Magnitude, NOT X, Y, and Instrumental Magintude!
I use "TheSky" to find the center of the field of a TASS images accurate to several arcseconds. IF someone has a better way to to this presently I would be most interestd. I the value that Normand calculates is not accurate enough for good Astromerty soulutons.
Arne Henden
aah@nofs.navy.mil
Feb 13, 1997
You guys are going to get tired of my postings!
I have a concern with the new concept for the contest. It leaves out those who may not have sufficient programming experience to write such a program, and gives an unfair advantage to those who have already started writing an equivalent program. It is difficult to come up with a good contest! Even the earlier version, looking for variables (or at least counting stars), gives an advantage to those in darker sites or that have better weather.
I would rather see you folks working together to create the best possible system, perhaps with outside 'judges' or at least the use of test regions and calibration data, to ensure that you get the maximum return and that your data might be useful to professionals as well.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
> ... Gutzwiller is getting close > to the number that we get with the FASTT telescope, with the exception of > degraded centroiding. This may be due to the > different image profiles between > our telescope and the TASS cameras, or it may be due to different > centroiding algorithms. How are these positional errors calculated? > Differentially between common stars in two frames, or from an astrometric > catalog, or just the sigma of the fit in the centroiding?The astrometric errors are the RMS difference between the RA and Dec computed by Michael Richmond's match program and the RA and Dec of the matching stars from the SAO catalog.
Tom Droege
droege@wwa.com
Feb 13, 1997
Chris Albertson wrote:
> Maybe a prize should go the the first person who could reduce 100 > frames of TASS raw data "hands off" and to some defined quality > standard. Say 10% photomety. By "hands off" I mean you enter > only one command or make only one mouse click and the whole process > is "automagic" you get a set of FITS format tables with star lists.I think I agree with you 110%. I have been thinking along these lines.
This really allows everyone to enter. We would put up some frames of tass data, and everyone could have at them.
As you may know, the program that Norman Molhant writes many 1.4 Mb overlapping (20 lines each way I remember) files. It also writes a log file with information about all the files. So I would like to see a program that took the log file as input, and just produced a measurement list as the output. Jure Skvarc is, I believe, working on a spec for the output file format. Then I assume, it would also write an exception file. Something funny in frame 17, too many clouds frame 34 to the end., etc..
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 13, 1997
> As you may know, the program that Norman Molhant writes many 1.4 Mb > overlapping (20 lines each way I remember) files. It also writes a > log file with information about all the files. So I would like to > see a program that took the log file as input, and just produced a > measurement list as the output. Jure Skvarc is, I believe, working > on a spec for the output file format. Then I assume, it would also > write an exception file. Something funny in frame 17, too many > clouds frame 34 to the end., etc..The only caveats to this is the necessity of specifying (and many times generating) the dark and flat vectors needed to process the files. We should be able to get to nearly automagic processing but for now I like "seeing" the steps along the way.
Joe Ronchetti
jronchetti@earthlink.net
Feb 14, 1997
I agree with Tom in this matter as it is the first time I have seen the contest available to those with out cameras.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 14, 1997
I just saw the following posting on the comp.os.linux.announce newsgroup. I think it may be useful for the linux version of the control software.
> ----- > > R J Gerharz: Timer Hook Patch for Linux Kernel Fri, 14 Feb 1997 > 03:36 > > I have placed my timer hook patch and some usage instructions at: > http://www.erols.com/rgerharz/Linux/ > > This patch allows, for example, data acquisition and control device > drivers to obtain control at precise, periodic intervals. > - -- > Reinhold J. Gerharz > http://www.erols.com/rgerharz/ >
Herb Johnson
hjohnson@pluto.njcc.com
Feb 14, 1997
*> I wonder if I could get a show of hands from those that are *> interested in entering the camera contest with the present *> rules. So far, I don't feel I have a strong response. I have *> *> What do you all think? So far I have been mostly underwhealmed *> by the response.I myself am more interested in asteroids these days. With a TASS camera, I'd support other work including variables and I'd support (but not offer online) an archive of raw data. I might get "drawn in" to variable work, or at least do some blink comparisions to look for flare stars. But my personal response is that there are a number of people better than I at variable star work and I've presumed they would win before I.
But it's funny how that works. I've found many amateurs just want to do what they want to do, and will not consider taking other people's equipment, offers for assistance or for collaberation. Astronomy is often - but not always - a solitary activity. Also, people develop their own ideas for reducing data or observations, for various reasons. So good equipment, observatories, and opportunities are more available than one might first imagine. Persistance and initative sometimes wins out over experience.
Seems to me a reasonable goal is to get good equipment into the hands of those who will use it and share the results, raw and processed. Such procedures to insure the above are desirable. Archiving for instance is a tough business, mostly tedious, but I think it's very important. But it won't win any contests, it won't get a pretty picture into Sky and Tel.
Hope this mix of reactions helps. I'm reluctant to say much more, personal comments can become "targets", and I don't feel like being a target.
Meanwhile, speaking of software, I've been introduced to "Astrometrica" via this newsgroup. It's a shareware program for astrometric work on comets and asteroids. I've started to look it over and it looks promising! And, it runs under MS-DOS (sorry) which with Windows is my primary OS. Contests notwithstanding, I'm going to look at some TASS images with it and see what I can see. I'll probably snatch Richmond's reduced GSC and integrate it into this program if I can. The program also does some blink comparisions between images. So, I'd like to get some successive TASS image files and see what this does with them.
Arne Henden
aah@nofs.navy.mil
Feb 14, 1997
Jure started a discussion regarding possible output file formats for image analysis software, and I just wanted to pass on some comments.
While I am highly in favor of FITS for handling the images, I am less favorable towards using FITS tables for ASCII data. Sure, IRAF with the STSDAS extensions can read them, but in most cases I want to use the ascii data for input into small data analysis programs (plotting packages, matching programs, etc.), or edit them with a system editor like vi or DOS-edit. To me, if the output is ascii, it is easier just to have a pure ascii file rather than adding the complexity of FITS overhead.
I would recommend including the following information in the TASS output (based on the values we have found necessary with the FASTT telescope):
1 ... camera location flag
2 ... CCD frame in yymmddfc.xxx format (f,c are filter,camera)
3 ... date of observation (julian format)
4 ... UT time of observation in hours
5 ... CCD x position
6 ... CCD y position
7 ... fwhm in x
8 ... fwhm in y
9 ... peak DN in image
10 ... total DN in image
11 ... total DN in sky under image
12 ... conditions flag
Note: this is the first extraction from the raw FITS files.
The camera location flag will uniquely identify the source of the data for
those programs combining data from several locations. It also can be used in
conjunction with the date and time to determine the sidereal time of the
observation if the pointing directions of the cameras are known. The CCD x,y
are (as noted by Jure) used for checking any systematic differences in the
reduction of images trailed through different parts of the system, and are
of course the raw input to astrometry. The fwhm in x and y can tell you
whether an object is stellar, blended, fuzzy like a galaxy or trailed like an
asteroid. The peak Digital Number and the two totals tell you fundamental
information regarding the photometry. The conditions flag tells you about
the quality of the night (photometric or not, good seeing, etc.).
The camera location flag is used in a lookup table to obtain latitude, longitude, engineering parameters, etc. for a specific site.
Our second (intermediate) output file is used after an astrometric and photometric solution is made, and includes the extra fields RA (J2000), DEC (J2000), standard magnitude, and solution errors in RA, DEC, magnitude.
Our final output file is the combined results from many scans, and includes the fields:
1 ... internal star designation 2 ... mean J2000 RA in hours 3 ... mean J2000 DEC in degrees 4 ... mean V magnitude 5 ... mean V-I color 6 ... number of observations used to compute RA 7 ... number of observations used to compute DEC 8 ... number of observations used to compute V 9 ... number of observations used to compute V-I 10 ... mean error in RA (sigma*cosD) in arcsec 11 ... mean error in DEC in arcsec 12 ... mean error in V 13 ... mean error in V-I 14 ... mean epoch for the RA 15 ... mean epoch for the DECNote that this output format won't handle moving objects well, except that they can show up as objects with large RA,DEC errors. Variable objects are easily identified by looking at the mean error in the magnitudes, and then we look back in the second (intermediate) file to obtain the date/time magnitude data for period searching.
I hope this listing of what we find important for our use is helpful in determining your file formats.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 14, 1997
I am passing along a message from Marty Pittinger to you concerning hardware and systems debugging issues. We have been running the APL/TASS Observatory as a large project, with people who are primarily interested in telescope/observatory design and operation setting up the Observatory and checking out the camera, and people who are data and image analysts working up software and procedures, and processing the data that the operations guys have collected. I think you should treat Marty's e-mail as a reminder, that while the analysts among us have been sharing the ideas, software and results, the guys who have setup the camera and have run into unusual problems have not communicated as well. We have made great strides in understanding the care and feeding of a TASS Triplet. However, in the past, when there is a e-mail message describing a problem, it is buried under many times that amount of analysis type messages. It would be very useful for the people who have actually setup the TASS camera's to document the problems that they ran into, or at least subscribe to a sublist that will focus on those problems.
----Message From Marty Pittinger--------
Tom,
We've been working with Nick on the TASS #5 triplet since early December. We are nearing that goal, having TASS #5 perfectly focused and aligned. We appreciate all the work he has done, especially in image processing and file archiving. Without him we would still be struggling with our unit. We would like to participate, but we're not quit ready yet, maybe by the end of March.
Having seen the great TASS images from others, as driven us to succeed. We have had to overcome: bad weather, material problems, no time to work on TASS, software incompatibilities and the lack of documented guides/troubleshooting. (I'm sure everyone had these problems somewhere along the way). From our "First Light" image, we have pushed to get TASS #5 online and it's images accessible.
Tom, we continue to make progress towards these goals, but please keep the troops in the trenches in mind when you pick through the mail bag. I would like to know we are not alone when it comes to hardware and system problems. Would you consider splitting you listserv into "Programmers / Technicians" and put me in the technician pile?
Thanks,
Marty Pittinger, President
APL Amateur Astronomy Club
JHU/APL Laurel, Maryland
Glenn Gombert
ggombert@infinet.com
Feb 14, 1997
I have uploaded to Storm another example of photometry using the Sextractor program. I have also uploaded another test image M67v.fit which was taken with the SBIG ST-6 of the standard "M67" calibration area. The image is taken with a "V" filter in front of the ST-6. The output catalog produced is M67v.cat, the reference star magnitudes (in the V-Band) in the image are taken from the AAVSO standard calibration chart that was supplied by Dr. Mattei.
As can be seen from the calcualtions the output is within the +/-5% range that we need for measuring TASS images. If Arnie could supply us with a list of "standard" stars this would help to calibrate our images photometrically in the +/- 3 degree declination are that present TASS cameras operate.
PS. If anyone would like a copy of the M67 calibration chart I would be glad to supply it :-)
Glenn Gombert
ggombert@infinet.com
Feb 15, 1997
Marty, Nick;
Don't get discouraged over the "learning curve" in setting up and operating at TASS camera. Before Tom sent me Serial #1 to operate here in Dayton, I have spent 4-5 years doing convential ccd imaging with several Newtonian's and my ST-6 and it still took the better part of two month's to "get the hang" of setting up the Mark III here in Dayton. Don't be "shy" about asking questions!
Holler if we can help, those who have currently operate Mark III camera's all have gone throught the same "learning-curve"..
Herb Johnson
hjohnson@pluto.njcc.com
Feb 15, 1997
Summary: Some camera owners suggest seperate maillist communications on camera issues. I make some related suggestions: encourage Tech Notes on the Web site, use the maillist with some discretion. - Herb
Nicholas Beser
I suppose another solution would be simply a cc: list to TASS camera
holders and to the maillist. Are there that many out there? But I think
the "analysts" should be aware of "technical" problems so fixes can
be incorporated into software when appropriate. For that matter, while
I don't have a camera, I have worked on one and I'm (apparently) one
of the few electrical engineers on the list. I am sympathetic to the
sense of "being alone" among the large volume of software and systems
discussions that occur, but I don't think that is intentional on anyone's
part. But seperate lists may not be the best all-around solution.
We must keep in mind we share a common goal, even as we have different
skills and priorities. It helps me when I see "progress reports" posted,
summaries of results and problems, written for our general audience.
Hopefully they can be accumulated on the Web page for subsequent reference.
Conversely, as I've said before, messages that are highly detailed and for
a *very small* audience may best be handled via private email, followed by
a *public* summary or resolution for the general audience. Rule of thumb:
if a thread only have two-three participants, take it private and post
the RESOLUTION. This may well have happened already.
A reality check: what *are* these camera problems? Have you resolved them?
Have you offered problems and resolutions as "tech notes" to Richmond's
TASS Web site for future reference? It's easy to talk about problems,
harder to document them *and* their resolution, especially after the
problem is solved. But most of us would like to READ such notes, especially
if we have a problem in hand. You could post open problems as such:
just update the Web site when it's resolved.
Hope these suggestions are helpful. Bottom line would seem to be: make
"better" use of both Web site and maillist, and provide some tech notes
on camera setup and use to the Web site as both a resource and an
encouragement.
This also appears as
Technical Note 24
Herbert Johnson suggested that we summarize some of the hardware
problems that we have run into with TASS #5. The following is not a
complete list (that means I drew it from my memory):
Cooling Problems:
Our mount is about 14 feet above the observing room on the roof of
Building 40 (JHU/APL Complex in Laurel, MD). The facilities engineers
specified 1/2 inch tubing to go from the water tank to the roof, hook
into the camera and then 1/2 inch pipe coming down from the roof. We
noticed that the water flow was not very large due to the decrease in
diameter at the camera. This was fixed by threading a 1/4 inch tube
through the 1/2 tube up to the camera.
Water pump (submersible sump pump) was heating the water to about 95
degrees F, and needed to be primed before it would work. Solution: A
motorized external pump (rotory design) was substituted). The water flow
is about 1 Gal per minute. Water temperature is slightly below room
temperature. A mix of environmentally safe antifreeze was added to the
water to keep the water from freezing in the event of a power failure.
Housing Problems:
The housing was initially pointed to -10 degrees declination. This was
later adjusted to 0 degrees.
The camera was mounted too far forward in the box, so that the focus
adjustment had no room for the telephoto lens to come out farther. The
camera was slid back slightly. Note that we have optical windows in our
system that keeps the lens from moving too far out.
Remote control of the doors seemed to effect the control hardware of the
camera (ie The data collection could not happen when the doors were
being opened). Solution was to take dark current files, and then shut
software off, and open the doors. There seems to be some electrical
noise in the system (we have solved that by procedure rather than
design). The door control is also being modified so that the html home
page control of the telescope will control the powering on of the TEC
and opening/closing the doors.
This last one was wierd. We share the roof with some radar dishes. The
people doing some installation up there tied a crane to the railing
(same one where the telescope was mounted on). The wind (blowing the
crain) was causing visible motion effects on the data. Solution (the
crane tie down has been moved)
Telescope Control and Data Issues:
Twice our data collection has gone over to pre-dawn hours (about 5-6am.)
The data files indicate that the ambient light levels are too high to
continue recording stars. At the end of the run, the sensors completely
saturate including the dark current pixels on each line, and the
temperature gauges indicated a sudden shift in temperature. The program
eventually shuts down when it indicates a temperature of 135 C. The
temperature does not really happen, it seems to be a controller failure
brought on by the saturated system. (NOTE: At no time has our camer
viewed the sun).
Alignment and Focus of the camera reminds me of the problems I had
converging a color monitor (ie. I can never get a color monitor
converged). We have seen the following problems:
Alignment setting is not smooth, ie. it sticks and then overshoots the
setting. (Need coarse and fine adjustment) I know it has silicon greese.
I know it also sticks and then shoots past the setting.
VCO setting seems unstable. A camera that seems to be completely
aligned, in focus suddenly exhibits the symptoms of VCO setting errors.
We currently have CCD2 higher by 1 degree than CCD1 and CCD0. CCD2 and
CCD0 both need alignment adjustment. It is also possible that the VCO
may not be correct for these two camera, however, it seems correct for
camera CCD1. We are still investigating this problem.
We are still slightly out of focus. (Focus is very close on CCD1, and
can be improved on CCD0 and CCD2)
Saturated pixels on one camera become visible on the other cameras. We
have seen examples (Mars images) that have the specular pattern repeated
on the other cameras. This is a design issue, and there is nothing we
can
do about it.
Current Status:
Our primary problem right now is that the weather in Baltimore has been
very cloudy since Feb 9 (the last observation session). We have worked
up a way of turning on the TEC power remotely (so that we can have it on
1 hour before we start observing). We also can open the doors remotely
(we need to wire that in). This is being done by X-10 remote control
devices under control of a unix workstation. I also have a RPC program
that may run under windows 95, and can be used to cause the TASS data
collection machine to start collecting data remotely by rebooting itself
in MSDOS mode, running tm3get11 and then when it ends, come up in
Windows mode with a FTP server operating. We really would like to get
our hands on a linux version of TM3GET11. We also are investigating
workarounds (There is a patch just announce for the linux kernal that
will enable real time control interrupts.)
More after Marty and Bernie have a chance to look at this.
I've uploaded a file showing typical TASS astrometric errors to the
incoming directory on storm.fnal.gov. The file,
matched.txt
shows the
residual errors I got when matching a TASS image with the SAO catalog using
Michael Richmond's matching program.
In brief the standard deviation was 0.12 pixels in RA and and 0.19 pixels
in Dec. Some of the difference between RA and Dec is due to the incomplete
solution Michael's program used since it used only the 20 brightest stars
from the subset of the SAO catalog I used while there were 75 SAO stars in
the image. Analyzing the residual errors implies that the Dec standard
deviation could be reduced to 0.17 pixels.
Also included are errors between the calculated magnitude and the SAO
magnitude. The standard deviation for magnitude was 0.62 mag. Not
unexpected since the image was taken with the "I" filter and the SAO
magnitudes are either photometric or visual.
This is very good stuff, speaking as a hardware/software person. It would
seem that oversaturated pixels have a profound effect on the TASS Mark III
system, even between cameras! If this effect can be duplicated "on the bench"
it can be diagnosed. The other items mentioned are good operational issues.
I hope Nicholas et al will, after some offline or online discussion, write
this list up as a Tech Note. Even unresolved issues are a "flag" for other
sites to consider.
To the extent I can be helpful, I'll privately email Nicholas on this stuff.
I don't have a camera on hand so my inputs are limited.
So far, I have only received a few messages from people who want to
enter "The Contest". But I am undaunted.
I am thinking of changing the rules from a tass camera owners contest
to a contest everyone can enter. The prize would go to the best production
software that turned TASS images into star measurement lists. I would then
put blocks of data up on the net for practice and anyone could enter. There
would be a number of things to be judged for "best". These would include
things like ease of use, availability of the platform used, accuracy of
the results, included tools, etc..
What do you all think?
Nick and all,
Thanks for sharing the various problems. I often would rather hear of
problems and their solutions than to see great pictures or data. It
helps a lot on future designs.
It may be that the 0.916 line time is not the best one. I did some work
on this the other night and found a different number was better. I will
present this in a day or two. This just means that the lenses are not
exactly 135 mm in focal length. I would not expect them to be correct
to better than a few percent. If they do not match, then we are out of
luck to the extent of the match.
The operating scheme sounds neat. Some day we will get some clear skys.
Then we will all get some data.
Tom, myself, and now Nick have noticed that it's harder to get nice,
sharp images in the I-band images than in the V-band. Tom wonders
I hope that the observers who are currently getting lots of data
can provide more information here. There are good fields for
comparison with standard V,I magnitudes in
Another guess is that the lenses on current TASS cameras just
don't focus light well at wavelengths as long as I-band (around
8000 Angstroms = 800 nm). I _hope_ that's the problem, because
one might simply try a more expensive lens...
Oh, and you may recall that I was planning to make an observing
run this past weekend. Well, the weather may or may not have
been good -- I haven't the faintest idea, because I was flat on
my back with the flu. I hope to recover before Mardi Gras
(and no, I'm not really joking :-(
I have not commented on Tom idea of a contest so far before I was
trying to win another contest I have with myself ( I should
win this one, but I don't know when ) :-)
The way I see it is that Tom has long finished building all his
cameras, and that he also see very little coming out of it so far.
This is normal since this is not a large project with 30 full
time programmers, but it is also normal to get anxious, and to be
willing to see something coming out of it before the Mark VI comes
on line...
My european point of view ( I guess most of the readers of this list
are americans ) is that the idea of the contest is a way to speed up
the process and get nearer to the point where TASS will produce useful
results. The idea of a contest, with something to win, I appreciate
as mostly a cultural difference ( i.e. I found the idea a bit bizarre,
but understand why most people would consider it normal ).
If it can reach its goal, then I have no problem with it.
I guess we are now in the boring stage. Building new equipment is
always exciting, making new discoveries is also very exciting, and
the in between phase, were everything must be tested, making sure
it can achieve its goal, writing all the required software is much
less exciting time. But it is required. Maybe the winners of the
contests will be everyone, because TASS will be in a position to
produce data.
I must confess I haven't read thoroughly the technical messages on
the list since a long time, knowing that the people in charge will do
the right job ( and it is a complicated one ).
As some of you may know, I am mostly interested in asteroids so far.
The only positive comment I can make is that we are porting our
asteroid detection code on PC. We use sextractor 1.2 on a Unix
workstation and it works great ( it can digest a 122 megabytes scan
in less than 7 minutes on a quad processor Sun workstation ). Glenn
Gombert has done two successive ports of this program on a PC. We have
a matching program which takes 3 catalogs coming from scans of the same
regions, find asteroid candidates, let you blink them on the screen
to confirm or reject the candidates, and performs the final astrometric
reduction. It is likely that when it will be stable enough, we will
put it as freeware somewhere.
Also, I would like to point out AVE, a remarkable Windows program which
takes variable star data and let you find periods, with very nice
displays and the like at :
http://www.gea.cesca.es/~rbarb/aveint.html
It was written by the GEA, a spanish group who has some serious
interest in variable stars ( they have discovered 30 new variable stars
in 2 years, this is nothing compared to TASS of course, but is already
quite an achievment already ). Their link is quite slow, but the program
is worth the wait ( maybe we should find a copy of it on Mike's site ?? )
Ask Rafael Barbera about this ?? )
Also, the last version of QMIPS32 ( v1.8 ) has a lot of very interesting
routines to perform automated astrometry and photometry. Up to you
to look at it.
Wonderful comet isn't it ?
M. Richmond wrote:
I am a little confused. Looking at the images in TN0019, the V-band
images are far worse than the I-band. They show lots of coma. The
I-band images look, from these poorly reproduced frames, much cleaner.
Am I missing something? The V-band images will probably look ratty
because you don't have a red blocker. The I-band images will most
likely be poor because that is outside the normal range these lenses are
spec'd. Does the focus change in the right sense (to match the IR-marking
on the lenses)? Does the psf change depending on the radial distance in
the field...that is, can you ever get sharp images at the center? Does
the psf have an obvious shape, such as astigmatism or coma? Can you stop
the lens down and see if that makes an improvement in the image sharpness
(sacrificing light while improving optical quality)? If someone has additional
filters, such as R and perhaps something halfway inbetween R and I, it would
be very useful to get data taken through them as well to see if the change
in image shape is consistent with wavelength. You may have to switch to V & R
instead of V & I if the focus cannot be adjusted properly at I.
Before you can say that your V,I system closely matches the Johnson/Cousins,
you need to take some data in a standard field where you get a wide range
in color (yet well-exposed in your frames), especially including stars with
large (V-I) such as in SA111.
Meanwhile, with the nice weather in the Northeast, I am looking at building
my permanent observatory in my backyard. I have a modest GEM mount and an old
10-inch I can put on it. The mount is incomplete, and I need a building
to wrap around it. But the mount is in place and very roughly aligned.
Other options are available, and I have potential sites for a TASS
camera in a number of NJ locations near and far.
Herbert R Johnson wrote:
I posted something yesterday that I did not see on the TASS mail list.
basically I said that I thought the VCO (or scan rate) should match
the image scale not the focal lenght. I said that focus error effects
image scale.
I have to retract that posting.
I still think it is technically correct but the effect is very small
for distant objects. Now in the case of stars within say, 1/2 meter
of the lens, focus would have a huge effect on image scale but then
we'd have even bigger problems with cooling and saturated pixels :-(
I though I would put up the numbers I am getting from Norman's
focus table. The results below were taken with a clock period
of 0.9101 seconds. I do not guarantee that the stop watch is
that good. The period was adjusted for a minimum value for the
middle camera (V filter) down reading. The numbers were written
in the log by hand, so they are representative and do not indicate
that they were all taken at the same time.
Bernie removed the telescope to add a mount bar on the bottom (in order
to make alignment easier). He is also adding a photocell failsafe on the
remote doors to insure they will be closed by dawn. I expect the
telescope to be reinstalled by the end of the week. The earliest we will
be able to collect the numbers for you will be some time next week
(weather permitting).
Larry Marschall just sent this to me, and now I send it all to you:
Many amateur astronomers now have telescopes in the 0.2- to 0.5-meter range
equipped with professional-quality CCDs and powerful software. With plenty of
observing time, high-tech equipment, and a love of astronomy, a growing
number of amateurs are capable of doing first-class science. Yet few do
systematic research, and even fewer collaborate directly with professionals.
With the shutdown or imminent closing of many small national research
telescopes, caused by a reduction in funding for research, it is
difficult for many professionals to get the data they need.
This suggests the need to foster more collaboration between
professionals and amateurs. To that end Leif J. Robinson (
Those interested in presenting a paper should submit an abstract by
April 9th (late paper deadline is May 9th), using the form
available either on the World Wide Web at http://www.aas.org/
or by anonymous ftp to ftp.aas.org/meetings/aas190.
Registration fees for the weeklong AAS meeting are
$175 for members and $255 for nonmembers ($225 and $275, respectively,
after May 9th). One-day registration is $95 for
members and $125 for nonmembers ($120 and
$150 after May 9th). To obtain registration forms write to
In the most recent (last issue of CCD Astronomy) Lief Robinson had
some very interesting comments on the TASS Project in his comentary in the
back of the magazine...
I've uploaded to storm.fnal.gov under incoming the two files:
I have 6 nights on the 1.0m in March and will be continuing
my photometry in the E and I fields, and will upload additional results
for these fields if I get any photometric weather. I would consider my
data as intermediate between Landolt and Lanz: on the Johnson/Kron-Cousins
UBVRI system, but not good enough to be called 'standards'.
For those of you who are variable star observers: the E field has 800
new variables in it, and field I has 50 new variables. While many of these
are too faint for TASS, you should be able to test your detection software
in these two fields with good chance of finding a large number of variables.
I've been slowly reading through the archives. Lots of gems there --
you folks have done some good work!
Concerning the RA(hr) vs RA(deg) 'controversy': I may be mistaken,
but I would be surprised if RA is not defined as having the hr/min/sec
format. Contrary to the email, the hour format does have use. For
example, determining when something transits based on the
current sidereal time. However, I also agree that it can be a pain for
computers since it has to be converted each and every time. There are
two thoughts here. First, you use degrees instead of hours because you
say that humans aren't supposed to read the raw data files, and degrees
are more convenient for computers. I suggest that computers convert
numbers REAL easily, that the hr:mm:ss format converter only needs to
be written once, and that ANY ascii information should be in the most
convenient form for humans and let the computers do any necessary conversions
for their own use. Second, if you do strongly feel that a decimal form
is the final conclusion, then I would suggest radians rather than degrees
as radians are the more natural form for most trig libraries. Also, if
you keep either degrees or radians, then I would modify the comment field
to R.A.(radians) or R.A.(degrees) or RAR/RAD to strongly define your
coordinate system and isolate it from the normal.
I've suggested a format for the 'extract' part of the reduction procedure.
This file is the baseline for all subsequent reductions, and permits you
to throw away the raw data. While you can make the raw extract part of
a complete reduction package, I suggest that you should at least put something
similar to this out as an intermediate step, as you may change your astrometric
or photometric standards, algorithms, etc. later and need to rereduce.
We leave everything in ascii here, and create some pretty large files
during the extraction process. Even for TASS, I estimate that you will
obtain about 20,000 objects/camera/night, or about 60,000 objects/night
that will end up in the extracted file. There are a couple of redundant
fields in my proposal that could be removed. For example, the CCD frame
number can be calculated from the file name and UT time, and the camera
location flag can be included in the file name. Likewise, the date of
observation and UT time can be combined into one 'Julian Date' field.
The conditions flag should probably be left in, as the sky can change
through the night and you might want to indicate that. If you keep an
ascii format, then you need about 44 bytes/object, or 2.5MB/night. If
you use FITS binary tables, you can save about a factor of two in storage,
with the inconvenience that it is no longer human-readable. Even in the
ascii format, assuming 100nights/year of data collection, a single site
will only produce 250MB of extracted data, which I consider acceptable.
Just some thoughts.
> I've been slowly reading through the archives. Lots of gems there --
> you folks have done some good work!
> Concerning the RA(hr) vs RA(deg) 'controversy': I may be mistaken,
> but I would be surprised if RA is not defined as having the hr/min/sec
> format. Contrary to the email, the hour format does have use. For
> example, determining when something transits based on the
> current sidereal time.
Let me put in my two cents here. I have noticed that many of the
X-windows based data analysis tools can't read RA and DEC from TASS
formated FITS files. I think the problem is due to the way the data is
stored (degree in fractions). Unfortunately, since I am not at work with
ready access to X-windows systems, I can't verify this. I have tried to
read the files with camera (and do a matching correlation with GSC), but
I get the message that it can't read RA and DEC from the data file. I
have also tried with some of the PC based FITS readers, but they don't
seem to understand the header as well.
Users of Stardial have found an unexpected benefit of chromatic aberration:
red stars appear fuzzy (because the near-IR is out of focus with our
simple optical-light-optimized 50 mm lens). So if you are looking to
find some Mira or other long-period, large-amplitude variable star, the
likely subjects are the "fuzzy stars" on the images.
For more $ one can get pretty darn achromatic lenses (even all the way
across the CCD sensitivity from 0.4 um to 0.9 um), but the inexpensive
lenses' PSFs blow up in I band.
We have also come upon another somewhat unexpected result: the red stars
are very easy to see. Our limit is something like 12.5 in a "red" filter,
but this translates into something like V = 15 for moderately red stars
like the long-period-variables (Miras, ...). The near-IR bandpass (0.7-0.9 um)
also helps penetrate Galactic dust. So I suspect that the easiest "new"
variable stars to find will be the fainter red ones, where the CCD has
an inherent advantage over the long history of visual and photographic
study of the heavens.
Just my $0.02 for today.
Oh, one last thing. Simple photometry algorithm yields residuals of
0.063 magnitudes rms for differential photometry with Stardial images.
I think that agrees approximately with previously published (on this
email group) data of Richmond with TASS data. Of course, the residuals
grow for the fainter stars as sky noise begins to dominate star noise
and calibration errors.
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.
The "Batch Processing" program that I am in the process of putting
together will use the RA and DEC values that are contained in the TASS image
header to calcuate the WCS (World Coordinate System) parameters for each
image.This then
constitues a general Astrometric Solution for each Pixel in the Image
(see
TASS Technical Notes 22
and
23).
Once the WCS parameters are calculated for a
particular image the RA and DEC values would then lose a lot of their value.
The "Sextractor" data reduction program will then be able to use
these parameters to calculate the RA and DEC (instead of X & Y) values for
each object that is detected in the image and output it in the form of a
Star-List. I should have a program that does all this ready for "Alpha"
testing shrotly.
There is also a description of the ATFTOOLs package that also
perfroms these type of WCS calculation in the latest (last) edition of CCD
Astronomy.
Alain just pointed out a WEB site that has a very interesting ccd
Astrometric reduction package. It is:
It looks like I will have to get a Fortran compiler for Windows95 to
try this out...
I am putting up some data on storm.fnal.gov in the /incoming
directory. There is still some work to do lining up the
telescope, but I hope it will be useful to all of you that might
want to get a head start on the contest, or who just want to
look at real data. Note I tried to get repeated samples of the
same field in V and I and with two blocks of each so there is
a big overlap when two data sessions are not in time sync.
File G2493632.FTS did not make it. 18 out of 19 ain't bad.
You will find the data on
in the directory:
Those who wish can simply
click to get files via FTP
directly with their WWW browsers.
There are pieces from two evenings of data. 2 Feb 97 was not a
very good evening. There were both clouds and haze. It was also
run with a different clock timing. The middle camera was also in
need of rotation for the 2 Feb run.
For my set up (because of some tree limbs that grow leaves in the
summer), the E camera points due south, the M camera points due
south, and the W camera points 15 degrees west of south. The
declination is not correctly set for the files in Norman's
tass.rc file, so I assume it is not correct in the FITS header.
The E camera is 3 minutes off in RA. That is when the display
reads 3:43 it is pointing at 3:40. It covers from about +40 min
to - 2 degrees.
The M camera is pointing at 3:52 when it is reading 3:50. It
also covers from about +40 min to - 2 degrees.
The W camera is pointing at 3:08 when it reads 3:05. It covers
from about -20 min to - 3 degrees.
Note that I list the pointing directions as I have because I can
never get the signs straight on such things. The declination
directions are very approximate.
I have included one dark run. I have not studied these as much
as I would like, but I can see effects caused by the ADC being
out in the cold. For the colder runs there is an odd/even effect
in the ADC. This is within specs for the ADC, but may trouble
some of you. The sky brightness just swamps these effects for
real data. For example, for the three runs listed the sigma was
20, 16, and 17 counts. Taking one of the other runs and picking
out "quiet" spots produces sigma in the 50 - 60 range.
Conclusion, since we can probably assume that the sky background
and the dark current adds in quadrature, the dark current is just
not important. I note that when I look at a dark frame, I can
see vertical lines. When I look at two dark frames from the same
camera the vertical lines disappear, and the noise *increases*.
This is expected when subtracting two noise frames from each
other. What this says is that the systematic effects due to
"hot" pixels are less than the noise. This would seem to be good
news, as then we are limited only by the sky.
Center (M) camera not properly rotated.
Shift timing 0.9178 (by cheap stop watch, mean of two runs)
Someone should now be able to calibrate my stop watch.
Intermittent clouds at start of run, clear at end? Data taken
into dawn.
Center (M) camera adjusted at start of run.
Shift timing adjusted for minimum value of down in Norman's
focus table. Timing 0.9102 seconds per line.
There was some haze, but no obvious clouds. Entire night at
about the same conditions.
For the data in the table below, the run starts with a G for
good, D for dark, the next number is the camera number. Camera 0
points west, camera 1 and 2 point south. There are then 3 digits
of day and 3 digits of fractional day.
Here's a picture of the APL TASS #5 mounted at JHU/APL.
Located at 39 09' N & 076 53' W near Columbia, Maryland
and at 483' above MSL it has a clear view to the south.
Thanks to Bernie Kluga for all the hard work, it really looks great.
I would like to see other TASS units, I'm hoping to include
everyone's site in our new web page. Until then, here's ours
TASS.
ftp://storm.fnal.gov/incoming/apl-tass.jpg
Good news for TASS camera images!
I've just finished uploading a new version of the "star" program to the
TASS Cincinnati site
http://members.aol.com/MGutzwille/tass/index.htm
The new
version not only produces star lists but also matches the stars to the SAO
catalog. I have successfully processed all 15 image files Tom uploaded
yesterday into fully registered star lists. The results are packed into a
single file, "stars.zip", that I've uploaded to the incoming directory on
storm.fnal.gov. Some of the images were quite crowded with up to 2726
stars detected in a single image at the 5 sigma level.
The new version of "star" was created by folding in Michael Richmond's star
matching code and using a subset of the SAO catalog for matching candidates
to stars.
The "analyze sequence" command of "star" will automatically process all the
images in a night's run for a single camera after you supply dark and flat
vectors. On my home system (486 DX4 100, 32 Mb) an image takes about 1
minute to process. Here at work my system (Pentium 133, 32 Mb) takes about
25 seconds to process an image.
As before nearly all the processing is done in the IP library which now has
Michael's code included. The IP library is designed to be platform
independent though I haven't tested it lately on platforms other than
Windows 95.
Let me know if you have any questions.
I have uploaded a "pre-Alpha" version of a TASS Batch File
processing program to Storm /incoming. It is called "Batch.ZIP" and
containes the executable batch.exe along with the necessary configuration
files. It has had limited testing but seems to run OK on my DELL LapTop with
Windows95.
It does not (yet support dark-frame subtraction or calculation of
the WCS FITS header parameters) necessary for Astrometic solution from the
images. These will be added in the next few days, along with a few other
features.
I welcome comments and bug reprots (I am sure that there will be
some). It's input is the "raw" log file that is written out by Norman's
program. It is offered to spur along the interest in totally automated TASS
Data Processing.
I think it is just great news that Mike and Glenn have running
programs. Since I am so inept at software, I hope others will
grab the programs and the data files on storm and have at them
while they still have challenging bugs. ;^)
I think I will take on the role of providing data. I can send
data on a 2120 or TR3 tape, or on a ZIP drive. If we ever get
a clear sky without a full moon in it, I wll take more. Got
a few hours last night.
I'll recheck the ip.zip to make sure it's correct. Make sure you rebuild the
IP library before rebuilding star since many of the changes were to the IP
library, not just star.
I use the "flat" program to generate a flat vector from "typical" images.
Flat files still need some work. Make sure the image you select for the
flat file does not have variation in the background level over time.
The question has come up about what kind of accuracy taht could be
achieved with the TASS Batch processing program that I uploaded to Storm
yesteredy. If the mag_zero point is set carefully this sould allow
photometric accuracy of a few % using calibration with stabdard stars on the
same "V" band or "I" band. This may require a different parameter setting
for each "V" Band and "I" Band set of image taken.
I will try and generate a TASS Technical Note on this subject in the
next few days..
I have just uploaded a new version of the TASS Batch Processing
program to Storm (Batch.ZIP) which now automates the calculation of the
World Coordianate System (WCS) Parameters which are inserted in the FITS
image headers prior to the Star Catalog being calculated by the Sextractor
Program. This allows Sextractor to cacluate (directly) RA and DEC for each
object that is detected in a particlaur image. It should provide a complete
Astrometric and Photometric solution for generating Star-Lists from TASS Images.
Two things must be done to before the program is run:
I will generate several TASS Technical Notes on how these two items
can be accomplished in the next several days. To calculate the WCS paramters
the Hubble Guide Star CDROM is required or a compresses version of the HGSC
data can be downloaded from the University of IOWA at
"inferno.physics.uoiwa.edu".
The Batch processing program reads the output from Norman's data
acquision program and extracts the file names from a particular nights image
run. The progam is run by the command line input:
The "-w" switch is used to calculate the WCS Key Words for the FITS
image headers. The program does not (yet) provide the capability of
subtracting dark-frames from images but I will add this to the program over
the weekend.
If anyone has any questions please let me know.
There is very exciting news to report. Bohdan Paczynsky of
Princeton University and Gzegorz Pojmanski of Warsaw University
have just left after a weekend visit to the tass home base. We
are joining forces to go after variable stars in a serious way.
Princeton is submitting an NSF proposal. It is too long for me
to put up all of it, but the essence is to develop a plan to take
a lot of variable star measurements. I (as Environmental Optics
Inc.,) have made a contractual commitment as part of the grant
request. The net result is that money that I planned to spend
anyway engineering the Mark IV can be put into the proposal and
matched 70/30 by NSF. Note that I have made no commitment on the
part of the tass members. As a result of this agreement though,
you all will have a data base in which to put measurements.
There will also be a source for large area CCDs. It will be up
to you all as to whether you want to join in this effort.
To me the proposal appears to have a lot of the elements that
should make it successful. If it is, we will know by about
September. Meanwhile, data fans, we can help the whole process
by taking a lot of data and presenting it at the June AAS
meeting. I have had some nice discussions with BP about how this
can be done in a way that will be acceptable. Clearly we do not
want to present "bad" data. But it looks like we can do a
preliminary analysis that will establish our potential.
The Players:
How TASS fits in:
One always worries when joining up with someone bigger and more
powerful. Will tass disappear in the mix? I think not. At the
moment, we will be the largest data source (After OGLE-2 which is
more specialized.) We may just remain the largest data source.
In fact it is in the interest of everyone for us to do just that.
I certainly hope to get many cameras into the hands of amateur
operators. In any case, there is not commitment by tass. I
don't have that power. It is up to you to join in. But you will
be welcome and supported if you do.
There is great interest in NSF and other government agencies for
joint efforts like this. We could be a model for such work.
Part of the deal which is not directly written into the NSF grant
proposal is that it will supply some quantity of large area CCD
chips to EO to build into cameras to be shipped out to tass
observers. It is not clear that this can be directly promised,
but I already have 11ea 2k x 2k devices, so I don't think a
direct promise is necessary. It is also apparent that there are
a lot of such devices "floating" around in the hands of
University researchers. This gives us a path to get at them.
In all this, all software developed will be placed into the
public domain. The hardware designs will remain the property of
Environmental Optics. There may be some opportunities for say
the sale of combined hardware/software packages to the general
public. This is allowed by the agreement. It may be just
possible that we may be able to sell a LX-200 priced package that
would allow someone to join in this work. One of the goals is
certainly to get observers around the world feeding data into
OASIS. Who knows, an LX-200 buyer is hard pressed to find
projects of continued interest. An owner of one of these devices
could see the continued value of his observations. We will give
it a try. I think you all know that I am not much interested in
developing a business. However, if one of you wanted to perfect
a software package for such a system, we could price the package
so that you got a nice royalty. In any case, the proposal is
written with a completely straight face as if this is the reason
that EO has contracted to give a bunch of cameras to ASAS.
This is enough for now. It is however, the reason that I have
not been grabbing the new software and processing star lists. I
will want to do that too. Still I have a very heavy commitment.
I hope you all will help me by beating everything into shape so
it will be easy for me. Meanwhile, I am going to take all the
data I can in the hope that we will have some good stuff for the
June AAS meeting.
Until I get a camera I can't add to the data, but I can work with the data
and some of the software, looking for asteroids. And I can likely make other
contributions. I encourage the TASS members to ask me to assist
in such things as is reasonable to do via the Internet
while I sort out a more active place for me in the TASS project.
I have just been reviewing an excellent article from the 1996, Volume #24,
1996 Journal of the AAVSO. In this issue of the journal Stephen P. Cook from
the Physical Sciences Dept. at Arkansas Tech. University wrote an article on
"Variable Star Astronomy With A CCD Wide-Angle Lens System". In the article
Stephen Cook describes using an SBIG ST-6 attached to a 2-inch f/3.6 lens to
study eclipsing binary stars. He describes in some detail the photometric
techniques that he developed using this system while taking over 4500 CCD
images to study eclipsing variables. It is a very good article and I think
that I will see if I can get permission from the AAVSO to have a copy put on
the TASS Home Page. I feel that it had a lot of good insight as to some of
the problems that we might have making photometric measurements from TASS
Images.
Some of the key points of the article were as follows:
All-in-all the article made very interesting reading since he is using
equipment similar to the TASS Cameras from an Urban area and trying to get
the best possible photometric accuracy.
Glenn G. wrote about Cook's article in JAAVSO, an interesting article
that I am going to have to read this week! A couple of points regarding
the key points that Glenn reported:
Arne has made some good points that make for some further
discussion about the procedure for making TASS Photometric Measurements:
The "Sextractor" program (when making such measurements) is
able to detect this condition and set a status flag that this condition has
been encountered. This will probaly occur quite frequently and we will
probably have to "discard" these measurements when this situstion occurs.
Since the measurement process will probably be a "one pass" operation any
star that is has a "mereged" backgound star will probably need to be discarded.
Glenn has raised some additional points, and I'd like to do a quick reply
as I probably have not made myself clear (common fault with me).
Normal differential work assumes that you have nearby reference stars
(for photoelectric work, a COMParison and a CHECK star are common), whose
standard magnitude and color are known, and then you perform differential
calculations with respect to these reference stars. This allows you to
use non-photometric nights since the reference frame is observed essentially
simultaneous with the program object.
What I am proposing is, for the equatorial TASS survey, a master list
of reference stars (also called secondary standards) be generated for
the entire 6degreex24hr zone. This list will be much smaller than all
of the measured stars, as you want relatively high accuracy in the measurements,
but will be much denser than the available photometric standards.
The density will be such that several (say 6-12) secondary standards will
be nearby any given program object, and so observers in non-photometric
sites can perform differential photometry. The hard part is determining
the master list, and that typically requires 3+ photometric observations
per secondary standard (which is why either a camera needs to be installed
at a good photometric site, or else a composite list be made from the
photometric weather at multiple sites). Note that these secondary standards
can be blended objects, as long as the digital aperture always measures the
same centroid so that you get a constant reading.
Program objects (read: variable stars) should, in general, be free of
crowding so that you get an accurate measure of the true magnitude and
color of the object. Note, however, that you can get periods of stars even
if they are blended with other objects; you just can't get good light curve
shapes. There are techniques to handle blending which can involve some
sophisticated programming that I won't get into here. The first iteration
should be aperture photometry of uncrowded objects; then worry about the
fine details.
Arnie has again raised some excellent points that should be taken
into account,there are clearly some compromises that must be made in trying
to automate photometric measurments from TASS Data taken from "typical"
Urban Areas.
We probably have (very) few nights in the MidWest that would
correspond to classical "photometric conditions". That implies that probably
all of our TASS Photomertic Measurements will be referred to as
"differential measurments". Also we will probably have perhaps one refernece
star per 4-6 frames of TASS data (this is being optimisitc) , and that means
that these "differential" measurements are made on all the stars measured in
these frames based upon say one refernece star per 6, 3-degree square frames
of data. I am sure that this will lead to some inaccuracies in measurement
but that is why careful attention to flat-fielding and sky background
changes become of critical importance.
It is desired (I think) to make measurements on all the stars that
can be detected in an image (down to the detection limit of the software).
All of the detected stars would be "program objects" and thus be desirable
to be measured. There may be (as I mentioned above) one known refernece star
for 6 or more frames of TASS Data and thus is will lead to limits as to how
precise photometric measurements can be made and still keep the degree of
automation reasonably high.
Since every star that is detected in an image is a "program object"
we will have to deal (in an automated fashion) a way to tell when a star's
magnitude estimate is possibly corrupted by a faint background star and thus
be able to mark this measurement as being "bad" and being excluded from the
measuremnt set.We will probably only make "one pass" throught the data and
as such the measurement parameters that are setup in the software must be
able to deal with the various conditons that have been mentioned (and
perhaps many that we have not thought of) to make measurements as accurate
and automated as possible.
I want to thank Arnie again for his excellent comments and ideas, he
has brought a lot of good insight and discussion on the TASS measurment
problem in the last several weeks.
I have been looking a DAOPHOT for reducing TASS images. I think
it uses a different algorithm then Sextractor. I'd be interested
in expert opinion on the algorithms used by the two programs.
There are other differences between daophot and sextracter.
Namely that sextractor seems to be easy to setup and use and
(now) runs under DOS whereas daophot runs in an IRAF environment
and is an order of magnitude harder to set up and run. We can
disregard this difference. I am interested in the algorithms
underlaying both packages.
The way I understand it, daophot works like this:
I have run the program on TASS images. It seems to work well
even for overlapping stars. It will detect and measure stars
that are about 1/2 of a PSF apart. It turns out these are common
in TASS images.
I'd like to compare results with those people are getting with
Sextractor. If anyone has a TASS image and a matching list of
objects would they forward them to me or if already posted let me
know where.
Another question that sounds very basic: Given two object lists
created from the same image, how do you determine which is
``better''? Yes, I know once you define better then it is easy,
but how do we define better for our purposes? I would compute
the intersection between each list and the GSC then assume the
longer list is better.
Daophot was written to perform photometry in globular clusters.
I would tend to believe that it is a very precise program, but
maybe an overkill for the TASS images ( and also maybe much
slower ). If somebody has a valid comparison of processing
times, I'd be interested.
In order to quantify detection algorithms, there are several
parameters to take into account.
The way to compare detection packages I have tried
here is to compare the results of various packages running on a
single frame, compared to the results given on a much deeper image
made with several individual images. This let us know if a faint
smudge on the single image is a real object or a fake. The proportion
of real versus fake objects tells you how the software behaves when
you want it to go as faint as it can. And of course, this is what
you want to do, otherwise you have to use larger telescopes or expose
longer, i.e. cover less sky. I would not recommend using the GSC to
get an idea of how the software behaves ( too many stars missing, some
being galaxies, etc.. )
I think I understand one of Glenn's concerns regarding photometry, and
thought I would describe a generic reduction cookbook for the TASS data
that might answer that concern. By no means is this a formalized model,
just descriptive, and others will undoubtedly find better ways to handle
the data.
The CAT file would then contain the mean RA,DEC,magnitudes of all
objects seen in the strip. This file could have an extra 'link' field
for each entry. A LINK program could be run that plots all objects with
fewer than n observations; moving objects should be recognizable by eye
and their entries linked together in the CAT file.
All entries for a given object in the VAR file could be period-searched
to see if they are truely variable, and probably merged with data from
other sites to get better time resolution.
Chris has raised some excellent points, that is worth devling into
at some length. The "original" version of DAOPHOT was written to run on a
DEC-VAX as a combinaiton of "stand-alone" Fortran Program's. It was not till
much later that they were integrated into IRAF and MIDAS. These (FORTRAN)
program's probably be obtained from the author (Peter Stetson) and complied
to run on any platform desired (including Windows95/NT).
DAOPHOT probably has a more robuts "deblending" alorithum in the
program which is potnetially is able to seperate stars that are closer
together than can be done with Sextractor. It (as Chris has pointed out is
more difficult to setup and run) initially.
The one feature that I like about Sextractor is that it is able to
calculate directly RA and DEC from the WCS KeyWords in the FITS Header once
they have been calculated. I am sure that it is possible to perfrom the same
caclcuations with the X&Y Posiitons from DAOPHOT but this would require a
lot more programming effort.
In the interest of getting some measuremnts from the TASS data taken
here in Dayton, I have combined several programs that (1) subtract a
dark-frame (2) calculate the WCS Parameters for a FITS Image and store them
in the header, and (3) calcualte RA & DEC and Stellar magnitude from TASS
Star Lists in an automated fashion. This is doable with the present programs
that I have put together in a Batch processing program.
DAOPHOT is certianly worth persuing (and should be) but it would
take considerably longer than the approach I have outlined above to yield
the same result in the near future.
Chris wrote:
Let me join the fray! All this talk of detecting and measuring
stars makes my mouth water.
My opinion on how we can perform accurate _calibration_ of our
raw magnitude measurements (however we extract them) is just as
Arne mentioned: we should build up a large catalog of SECONDARY
standards, enough so that any TASS image contains at least 10-20 or
more. Here's one way to do this:
Keep in mind that one can improve this net of SECONDARY standards
more than once; there could be the 1997 version, the 1998 version,
and the "final" version, each more accurate than the previous ones.
Once we have this net of SECONDARY standards, we can use them
to perform "local" differential photometry for all stars in any
TASS image.
Building this net of SECONDARY standards is one aspect of
TASS which interests me very much, and to which I plan to devote
a lot of my time.
On to other matters, briefly:
For example, I've already uncovered about 5 or 6 different
bugs or inadequacies in my own software :-)
Michael wrote a good description of how to create the secondary standard
file. I have one exception to that. His idea was to use the Landolt
standards, create a set of secondary standards near the Landolt standards,
then use those stars to expand outwards and create a third set of secondary
standards.
Since the TASS cameras are actually running continuously, and the FITS
files are an artifact of the data acquisition system, the entire strip
is the unit of measure. Just like in all-sky photometry, the standards
do not have to be in the field of the program objects that you are
working with. The standards are used to determine the all-sky extinction
and zero point, and then that sets the magnitudes/colors for the program
object and secondary standards in the field of the program object.
Therefore, I don't see the necessity of step 4 and the second level
of standardization. Just use the Landolt standards for all of the
secondary standards.
it would appear to me that the first secondary will have certain errors
from the original landolts. as you go from 'secondary' to another more
remote 'secondary' the errors are increasing, cumulative . . . .
i think this should be 'shown' in the measurements, hence call them
secondar_1, 2 , etc, or some such to differentiate . then you will have a
relative value of expected incremental errors of one unto the other.
Mike Gutzwiller, Chris and others have been talking about better approaches
to handling blended images than straight aperture photometry. I've used
DAOPHOT with good results, but it is a strong learning curve. There are
several other packages, such as DoPHOT, Mike's star, the MACHO/OGLE/SDSS
schemes, etc. that can also be used.
I think that aperture photometry should be used for most of the work.
It is just a lot simpler and more reliable. Saying that, the big
caveat is crowded regions such as the galactic plane. Here you may want
to generate an automated psf-fitting version of the extraction program.
However, beware! Aperture photometry is reliable because you use the
same aperture for all measurements. Also, ALL of the Landolt standards
were generated using aperture photometry. If you start using psf photometry,
the effective aperture size changes on a frame-by-frame basis, and the
results generally have more absolute scatter than aperture photometry.
I find psf fitting to work well for differential photometry, but aperture
photometry to work better for 'standardizing' the secondary standards.
Arne argues that one can use the Landolt fields, spaced at 15-degree
intervals, to calibrate a set of secondary standards covering the
entire equatorial strip, in a single step. I don't disagree with
him.
My motivation in listing a multi-step procedure that expands outwards
from the Landolt fields was to avoid errors in transferring the
photometric solution defined by the Landolt fields over _time_.
It will be a full hour from one set of Landolt stars to the next.
Now, if one is at a good, clear, photometric site, the photometric
solution should be stable over one hour (maybe even over several
hours, or an entire night). If one is at a site with frequent clouds,
water vapor, and lots of lights from nearby houses, it might not
be true.
So, my idea was to assume that the photometric solution was valid
over, say, 10 minutes; one could then use the Landolt stars to calibrate
stars up to 2.5 degrees away with relative safety. And one could
gradually build up a set of stars, never applying a calibration over
a timescale of more than 10 minutes.
There's a simple means to check this, of course: you can follow
Arne's suggestion, and make a single photometric solution covering
several hours from several groups of Landolt stars.
If it _doesn't_ work, you can either try my labor-intensive
idea; or simply wait for some night which really does turn out to
be clear, and try the single solution again.
Of course, once ONE person, at a good site, calibrates a set
of SECONDARY stars, everyone else, at all sites, can use them!
Michael wrote:
Also, how do you do a good color transformation without including many
more stars than you might be able to measure in one Landolt field?
I MUCH prefer to average over many Landolt fields rather than select,
say, RU149 by itself.
Please excuse any spelling errors on this end, they are not
intentional. I am using a "freebe" E-mail program that does not include a
Spell-Checker and I try to contibute to the discussion during working hours...
I have posted the results from several images using the "Sextractor"
program in the last couple of weeks I will try and process several of Tom's
images and post the results in the next few days. (Probably over the weekend).
I am sure that all of the techniques mentioned will yield good
results if good calibration methods are used. I have a basic question about
all the effort that coming up with a good set of "secondary standard" data
would require. Is the future of the Phase III Camera's "long term" enought
to devote that much time to developing the list of secondary standards with
the new Mark IV Camera's that are going to be coming on-line that operate in
a different part of the sky?? This might be a good question to give some
careful thought to.What about developing such standards for new parts of the
sky?
The photmetric data from the new Hipparcos satellite will soon
becoming avaliable. Will this new source of data add significantly to the
current standard stars that we have? How will this affect the proposed
efforts to develop secondary standards in the +/- 3 degree stip of the sky
that we are presently looking at??
It is time to engage in some political activity to establish the
position of tass in the scheme of things. I consider it to be
essential to try to take some data to the June 10 AAS meeting on
combined amateur/professional projects. Note that I want to get there
before someone else presents something similar.
First the disclaimer. I know nothing about statistics. I may be
making a terrible error in my process below. I will, however, stick
with the goal.
I have been following as best I can all the discussions of photometry
and calibrations. I think there are two things we can try to do:
I cannot imagine getting any measurements in shape by June 10. It is
just too complex a process, and we are bound to make mistakes if we
hurry.
I think we can, however, explore the territory and identify a large
number of variable star candidates. Here is what I propose to do:
Present 9) as "evidence for the ability to detect variable stars" (I
worked at Fermilab on the Top quark experiment).
Present 10) as samples of probable variable stars.
This process was suggested to me by a conversation with Bohdan
Paczynski. He is not at fault if I have got it wrong.
Note that this is a purely relative measurement. It says nothing
about the absolute magnitude of the objects. It makes no attempt to
say that we can "measure" variable stars in the sense that the AAVSO
attemps to measure them. AAVSO attempts to collect single data points
from observers all over the world and to plot them in comparison to
each other. We have an advantage in that we have 22 (when I get them
all fixed) identical pieces of apparatus. The differences between
tass machines should be mostly first order and thus corrected by the
offset of step 3)/4).
While the cuts may bias the result, and thus bias the data as an "all
sky distribution of various types of variables", it does not create a
variable where one does not exist. The test is the magnitude vs time
plot with tells a completely independant story. (This is not without
its problems - aliasing etc. for some types of objects.)
Most of the science does not care what the absolute magnitude of a
variable object is. So we don't need the Landolt stars at all. We
can create our own reference set. Later we can tie in to the starndard
stars. But we can do a lot of good work before this is necessary.
I think we have a fighting chance to get plots 9) and a few 10s) done
by the 10 June meeting. I was going to do this withoug the RA/decl
processing just using a tass plate scale if the star fitting software
did not appear. Now that it has, the data is tied to the sky.
What do you all think??? Who wants to join me in this effort?
I got some nice data over the last several evenings. Of course, half
way throught the data set there is a BIG blob of light. But they look
pretty good near the ends.
Is anyone else taking data? Let's get as much as we can the next couple
of months.
In general, I agree with Tom that the near-term goal should be something
to present at the AAS meeting. Starting today, that leaves approximately
3 months to collect and analyze data. The scheme he proposes for finding
variable stars is pretty similar to what other groups do.
However, there are a number of problems, and that is what Michael and
I were alluding to. The main one is that Tom's scheme assumes photometric
weather. If, for example, a night was mostly photometric but had a band
of clouds move through for an hour in the middle of the night, then the
mean zero point for the night would be about right, but those stars that
were measured when the cloud went through would be fainter than the mean
and would show up as false variables. That is why the reference frame
of secondary standards was proposed.
I know reinventing the wheel is always enticing! However, I posted the
stars in FASTT fields 'E' and 'I' because I already know the answer there, as
we've discovered all of the variables accessible to TASS within those
regions. For example, if you worked with field 'I', then the astrometric
reference stars I gave are all constant and you can use them as your first
cut at a secondary standard frame. Then you should be able to show that
you are picking up all the variables you should, as a first test of the
reduction system, and perhaps cover a separate unknown field as a second
part of the AAS presentation.
This is not to belittle Tom's idea. I'm just suggesting a modification
that might be easier to implement.
It seems to me that this problem could be easily detected, because all stars
in the field that were recorded during that hour would be similarly effected.
Not all stars in any given one hour field are going to be variables.
I did not spell it out, but I was assuming that we worked with the present
data blocks that are about 15 minutes long. Each block would be processed
as a data set, or even cut up into smaller blocks. When clouds move through,
this would require a different "adder" for the best fit, and probably result
in a larger error. This could then be used to flag the block as to quality.
So I don't think I was assuming photometric weather.
Note that I am not against using the photometric references. I am just looking
for a way to strip down the process to its essentials. I already have software
that works from Mike Gutzwiller. This software would allow me to do what I
want (with great pain). With the next part (I don't have this working yet)
that converts points to RA, Dec., I could do the experiment. Possibly by
the time we all collect enough data, we will have something that automatically
ties in the reference stars. I may even be able to do this in QBASIC. I will
try if no one else steps up and says I will do this part.
I am single minded when is comes to getting something done. I will wait about
a month, furiously collectiong data. Then I will start processing it with
what I have at that time. I would be delighted if someone does a better job.
There is space for all the co-authors that want to work on this. But I am
setting out to do the whole job myself with tools that I have today. I would
very much welcome anyone who wants to join in the process.
Several of you have already said that you would like to join in this paper.
It is time to agree on what we will try to do. So I am posting these notes
to try to get an agreement as to what we will do *for the June meeting*.
I figure we have to be running the whole process in March (very soon) if we
are to plan to present something June 10. We can add new data, but the
process needs to be fixed very soon!
Following Tom's plan to present results at the AAS meeting
this summer, and Arne's suggestions on where to look, I wish
to put forth the following plan for the next 5 weeks.
It's just a suggestion.
I suggest that those people who have cameras try to make sure
that they get images of 2 or 3 "special fields" over the next
5 weeks. Suppose we pick
The field "B" is at a moderately low galactic latitude, so it will be
full of stars, and present more of a challenge to our reduction procedures.
It contains the Landolt field SA 100, which has many standard stars.
Both fields should remain visible for the next 5 weeks, I think ---
yes, field "B" will be on the meridian at twilight at the end of March.
So we can spend 5 weeks getting oodles of data for these areas,
and then another 8 weeks trying to reduce them before the AAS meeting.
It is my experience that _reducing_ a set of data takes much, much
longer than acquiring it.
Some people may say, "That's a piddling amount of sky!" Well,
I can provide the disk space for it, and I can also provide the time
and effort to analyze the results for this much area. If people
want to acquire and reduce more data, terrific! I'm just stating
that I think concentrating on these two areas will allow us to
present a paper(s) at the AAS meeting that contains airtight
results.
There's nothing magical about my choices for the areas -- if there
are good reasons to pick some other 2 fields, or 3 fields, let's
hear them!
So, that's my suggestion. If we concentrate on these two fields
(but of course, take as much data as we can), then I think we have
a good chance to present impressive results by June, 1997.
I am working on a system here at work and guess what. Our interface
spec
is wrong. Turns out the best spec is the system itself.
I will sign on to Michael's suggestion. But I would like to move
field B to later in RA. A few clouds at the wrong time and we get
almost nothing in March. I think I already have about 4 sets of B
though. It would be nice to have 50 or 100. How about moving B
to around 16:00 this is about the same distance from the galactic
equator, and is near dawn now??
I agree with Michael that it takes a long time to process the data.
But it might not be so bad to keep adding data right through May.
The tough part, I think, is getting the first few blocks through the
process, and to stop changing the process.
Thus I would propose that we have a cut off of process changes by
say 30 April. We should be able to keep adding data through May if
we have frozen the proceedure.
Michael's suggestion sounds good to me. Tom's suggestion of a later RA
for field B is ok, but to get roughly the same galactic latitude (20degrees),
you would need to pick, say, 16:30-16:45 RA, and that doesn't transit at
twilight until March 25. Michael's field B goes away around April 5 or so.
In other words, both are marginal for the June meeting. I would prefer
getting data earlier than later, and so would opt for Michael's field B
at 08:45-09:00, and if folks get clouded out or can't get running by
then, replace that field with RA 16:30-16:45 at the end of March. Note
that, even 20 degrees out of the plane, the star density is 3 times higher
than the 13h fields that Tom posted on storm.
Michael comments:
I'll supply whatever photometric support may be needed from here, using
the 1.0m telescope.
What do the rest of you on the maillist think of the SMSP concept?
Glenn G. wrote:
I saw some mentioning the DAOPHOT program. I don't know which
versions do you use, but there is also a version for MS Windows. You
can find it at
http://www.fiz.uni-lj.si/astro/index.html
Glenn was proposing a 'moving object' addition to the AAS presentation.
Sounds like a nice add-on to me! My concept is that the aperture
extraction, astrometric and photometric calibration should be a fixed
entity that is common to all of the TASS cameras, so that we know the
data is processed to the same level and with the same algorithms. After
that, folks have different ideas as to what they want to do with the
data. Obviously, I'm interested in variables and would want to search
the reduced data stream for such objects. Others might want to find
asteroids, or look for transient events (OTs are possible, for example,
and perhaps some 12mag novae), and I would assume these data analysis
programs may be specific to a given project. Examples of these ancillary
data products would be nice to have at the AAS meeting if they are
relatively mature. I think the goals should be (1)to impress the professionals
that amateur contributions can be of high quality, and (2) to stake out turf.
A side note: though I know all of the TASS-accessible variables in
the SMSP field A, I don't know the periods of the variables as we have
insufficient FASTT data for that task. Therefore, there is still good
science to be done even in this previously studied region of the sky.
I do have a good bit of data on Michael's B field since I have been running
most clear nights since mid October. Depending on the timing I might have
15 or 20 runs including the field.
I have one more idea to throw out to add to the measurement plan
that Michael has proposed. I am about ready to star testing a "Moving Object
Detection" program that will scan throught TASS (or any images) and look for
moving objects. This could be asteroids, comets, satellites, airplanes,
whatever and write the results out to a log file.
If we were able to get any interesting results with such a
technqiue, it might make an interesting addition to the proposed
presentation that Michael outline. This could be done "off to the side" with
the results presented if anything interesting was found..
Tonight I was starting in on the reduction process on Tom's Image
"G1493946.FTS" if anyone is interested the EXACT center of the field is:
I just received my replacement technical data sheet for the KAF-0400, which
helps me (anyway) in understanding the output of a typical TASS camera.
I have a couple of questions, which Tom (or equivalent) might answer.
According to the FITS headers, and comments in Norm's data acquisition
program, and the spec sheet, the long dimension is the 'horizontal' and
the short dimension is the 'vertical'. (Note: this is different from
most scientific chips such as the SITe variety, where the short dimension
is the horizontal to decrease parallel gate lengths and capacitance).
The first question is that Kodak says there are 4 extra rows at top and
bottom that they added for dark reference. I assume these are clocked
just like normal rows, and therefore each imaging line/row sees an extra
8 clocks of dark current before being read out?
During vertical clocking, the following pixels are read out (1-relative):
I've uploaded two nights worth of star lists that cover Michael's "B" field
from mid-December onto the Cincinnati TASS web page
http://members.aol.com/MGutzwille/tass
The field is covered by all
three cameras on both nights. Night 432's data is problematic with varying
cirrus clouds while night 433 is fairly good.
I'll upload more nights as I find and process them. (I have night 421
covering the "B" field but it was either clouded out or the moon was up.)
I'm trying to gather together the raw data, reduced images,
and star lists that people have made for the images which
Tom Droege recently uploaded to storm.fnal.gov.
You can find the _start_ of this archive just off the
TASS home page, at
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
If you have your own version of reduced data, and wish to make
it available to all, please contact me directly and we can arrange
to put it there. You must supply me with a short text describing
the format of your output!
If you want to start analyzing the results of others (for example,
to compare results of person A vs. person B, or program X vs. program Y),
you should be able to grab stuff from this location.
At the moment, you can find a table of the image properties,
raw images, and star lists generated by Mike Gutzwiller. I'll be
putting my results there this afternoon. Glenn Gombert's version
should appear sometime soon, and others are welcome.
We're in the midst of a major winter storm, so I won't finish my astrometric
processing of the Droege dataset until tomorrow at the earliest. However,
here are the calculated mean plate scales for the cameras on the night of
Feb 12/13, looking at the 13h-14h fields:
Tonight I have completed the data reduction of Tom's Image
G1493946.FTS and uploaded a complete catalog of the image to Storm. The
catalog is called
"C1t0493.946".
It show's how RA and DEC can be calculated directly from the WCS
Parameters in the FITS Image Header of a TASS Image. The output from the
program that calcualtes the WCS parameters is at the bottom on the star-list.
As can be seen 19 out of 25 stars aligned between the image and the
Hubble Guide Star Catalog stars which indicated good agreement between the
two. Also the stellar magnitudes that are calculated agree within +/- 0.2
magnitude or so. As Arne has pointed out these do not serve as good
photometric standards but they serve as one "metric" as to how well the
magnitudes were calculated as compared with the HGSC data.
I will try and post a detailed "finder chart" of this image over the
weekend and put several TASS technical notes together to show how this is
procedure is done.
I still have some fine-tuning to do of the procedure but think that
it was a very good exercise to test out technqiues on Tom's images that he
posted a few days ago. I will try and complete several other of Tom's images
over the weekend but will probably not do them all since I have other TASS
tasks's to perform (like sifting throught all the data that I have
collected) to find the fields that Michael is going to present at the AAS
meeting....
Michael and others have asked me to detail the contents of the star lists
my "star" program generates so here goes:
The star lists start with a header section containing the following fields
if the catalog match worked:
For each star detected a row is printed as follows:
I am currently looking at improving "star" to provide better photometric
results based on analysis of its performance. I also intend to fix a
couple of problems with the catalog (a) it should reside wherever you want
to put it, not where I happen to have it and (b) it needs to be based on a
better astrometric source than the SAO catalog.
If anyone has any suggestions about improving any of the programs, please
let me know.
Michael Gutzwiller wrote:
What was the detection threshold set at for the stars in the
lists posted on
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
Was it 3 sigma or what?
I am getting results a lot like yours with daophot but I can
make my lists either shorter or much longer then the ones you
posted by making small changes in the program's parameter file.
I am going to have to "tune" the algorithm but I'd like to
shoot for the same sigma above noise value as everyone else.
Also how do you define the background noise? I am simply computing
stats on "blank" areas of the image and comming up with about
50ADUs or less. Within 5% of your estimates.
Also could you explain briefly your approach to dark/flat
processing.
I am proceding through Tom's raw data files in parallel. Doing
all the dark/flat processing on each file then all the detections.
I now have star lists for all files. Takes about 45 seconds per
file to do the detection. (Intel P100. I'll try the Sun SPARC Ultra
later. I estimate 4x faster on Ultra)
Next I'll work on astrometric corection based on Hubble GSC.
I hope to have an independant data reduction chain working in the
next few weeks.
I take each pixel in the image except the last one, subtract the value of
the next pixel and store the difference in an array. The difference array
is then sorted and the noise is estimated as
Statistically the basis for this is that the difference between two
uncorrelated measurements of a gaussian distribution should also be a
guassian distribution with a sigma sqrt(2) times the sigma of the origional
distribution. The percentiles above are those at + and - one sigma.
Using the percentiles helps to ignore the tails due to stars. This formula
should work as long as the noise level doesn't change significantly over an
image and the sky background amounts to 68% or more of the image.
Flat vectors are more problematic and I don't feel I have a really good
solution yet. The "flat" program I created makes a flat vector by finding
the median value in each column of an image (ignoring any saturated
pixels). These vectors can become contaminated with stars however if the
sky background varies over time in an image. I usually find that a single
flat vector is not noise free enough and use DeepSky to average several of
them together. Flat vectors generally can not be created this way if the
moon is up during the image due to background gradients over the image
field of view. Supposedly the flat vector will be constant if the camera
arrangement is not disturbed though. I also worry about background
gradients even without the moon in the sky. All in all I'm trying to
determine a better way to get flat vectors. Anybody have suggestions?
I have had several requesets to post the Source files from the
"Sextractor" program that I complied under Windows95 using Microsoft Visual
C++ version 4.2.
I will try and do this in the next sevral days, only minor program
changes were made to correct minor differences between "UNIX" and the
Windows95/NT enviornment..
To All Data Munchers;
Seems to me it is time to start using a standard naming convention for
files? I can imagine a lot of things that could be coded into the file
name. But I am the wrong one to do this. Any one want to vonunteer?
How about it Chris? Or one of you other lurkers that has a lot of
experience manipulating data?
Mike Gutzwiller wrote:
I think the best way would be to hold a white card in front of the cameras
during twilight and use that as a reflected, diffuse source of light.
For standard CCD observing, you take flats every evening because they change
as dust falls on the filters, etc., and TASS may have to do the same since
the cameras are in a harsher environment than most observatories.
in a subsequent posting
Allen Gilchrist asked,
in a subsequent posting
Note that gradients in flat fields affect primarily the photometry. We
are talking 5-10percent max affects here, so it is not a big deal unless
you are trying for the best possible set of secondary standards. Differential
work within a smaller region should be in pretty good shape even with gradient-
affected flats; but flats with small-scale errors (such as stars peaking above
the median) will affect photometry badly.
For astrometry, you can have pretty miserable flats. We use a bed
sheet illuminated by an off-axis Kodak slide projector on the 61" for
astrometric flats, and get sub-milliarcsec parallaxes using this technique.
I had been assuming that the flat field that is used in the star program
is the result of the median filter (background determination). At that
point, the background is calculated and then anything below the
background is shunted to zero.
Are you talking about getting a dynamic range of the sensor? Dark
current to near saturation?
Nick Beser wrote:
My two cents,
I'm not an expert at this, so maybe I see it in a different light - A
Real Amateur.
If you're stuck on 8 characters, the following may work (I used a scheme
similar to food processing companies). The numbers 1-24 = the letters A
- Z (eliminate the letter "i" & "L", to reduce confusion { 67231l42.fts
should read 67231k42.fts). The previous example given would equal "TASS
Unit # 6, 1997, August 19, 1042 UTC . fts" . Below are variations on
the same scheme. This scheme would help in sorting data by TASS Unit# /
Year / Month or Day / Hour & minute. A Julian Calendar could easily be
modified, adding the appropriate letter to the month and/or day.
I have finished my (first pass at) analysis of Tom's
images. You can find my report in Technical Note 25:
http://www.astro.princeton.edu/~richmond/tass/technotes/tn0025.html
Be careful, it's pretty long (about 81K).
You can also find both raw and calibrated star lists from
my reduction in the archive for Tom's February data:
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
When you compare my lists to those of Mike Gutzwiller, you'll see
that he has gone deeper into the images than I have.
For those who are impatient, here are the conclusions from
my report:
http://www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
for easy reference and cross-reference.
Like Michael Richmond and others, I've been munging Droege's dataset and
have given Michael the first report on the astrometric performance.
I have similar conclusions to Michael. I am a little concerned that
the image fwhm is not better, and would propose taking some additional
test data to check where the degradation is occurring. With the current
fwhm numbers, I don't see astrometric accuracy per frame getting better
than 1.5-2.0 arcsec, which is pretty crude.
The camera 0 and camera 2 frames cover the same field, but camera 1
is an hour away, which, as Michael mentions, prevents a characterization
of the photometric performance. I will get some BVRI data in Michael's
field B on my upcoming CCD run to help in this characterization. In
the meantime, if Tom has camera 1 data taken on the Feb12/13 night that
was taken an hour earlier so that it covers the camera 0/2 fields, it
would be useful to post that data as well.
I just uploaded to Storm /incoming the reduced "raw" star-lists of
the data that Tom posted to Storm last week. The file is called
"rawstar.zip" and contains the following files:
The format of the star-lists is as follows:
I have also included the Sextractor parameter file that was used to
make the above measurments if anyone is interested in repeating the above.
It might be a good place to stat.
I will try and complete the Astrometric reduction of the above
images as time permits over the next several days..
The above files should be interesting for comparison purposes. I
would like to add this to the "data collection" on the TASS Home Page.
I just uploaded a "3-D" waterfall plot (g2493909.bmp) file to Storm
that shows how the point-spread function for each object detected in the
image varies as you move around the image.
The analysis was done for Tom's Image G2493990.FTS and is
interesting to note how the PSF varies as a function of position and time. I
will try and generate a similar plot for the other two camera's in Tom's
tripplet for comparison purposes.It may also be an indicitaion of how the
drift-scan system perfromance varies as s function of star position on the chip.
I have added two more night's runs of the "B" field to my web page. I also
zipped them to make it easier and faster to get a night's run.
I am working up a short DOS routine that will sample the TASS controller
to get the two temperatures (TEC and Liquid) and Voltage readings. We
are setting up a way to turn on the TEC power via remote control, and we
want to monitor the TASS camera before we start up the TM3GET11
software.
Is there as calling procedure that I should follow so that I can return
the temperatures and voltages? The TM3GET11 program has a routine
called GetValue(mux, value). I plan to call it with the four mux values
(0x008, 0x010, 0x018, 0x028) and then covert the 16 bit values into
temperatues and voltages. Is there any setup procedure that needs to
happen first for that to work?
As way of background, I have a remote procedureal call utility that
allows windows 95 to respond to a remsh or rsh from unix. We will turn
on the TEC power via a CGI script on our homepage. We will then perform
periodic rsh to the tass computer to sample the temperature and
voltages. If the temperatures and voltages don't look correct, we will
turn off the power.
Until we have a Linux version of tm3get11, I plan to copy a autoexec.bat
file that calls tm3get11, and then use rsh to force a reboot. After the
tm3get11 finishes, windows 95 will come back up. As part of reboot, I
will have the windows 95 system send a message to the homepage to
announce that it is up, and to start monitoring temperature and voltage.
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.
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.
Lets first look at what we need to be able to determine
from the filename alone.
We know that all TASS raw data was written by some version of
tm3getxx. This gives us a starting place. (quoted from the
doc) here is what tm3getxx writes:
It is still possible to mix up iles written by multiple sites
but isn't that what directories where made for.
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. A file called "FXXXXXXX.TXT would contain
an explaination of all other files starting with "F".
It would define the "F" type. This gives someone a quick
way to know that the text file applies to a batch of data
files. So yes the "XXX" are literay part of the filename.
So you have so new kind of data and want to call it "W".
just be the first to write a"WXXXXXXX.TXT file and you
have reserved the letter W for that purpose. It does
not count unless you post the WXXXXXXX.TXT along with your
data.
TASS Mk III is using a 135mm camera lens. Camera lens are not even
close to being defration limited. Photographers think of resolution
as lines/millimeter at the film plane. I would assume that the
lens used can resolve about 80 cycles/mm. How many pixels/mm does the
Kodak chip have? I think about 100.
Can anyone work these numbers better then me? the 80 figure is
giving a lot of credit to the lens and assumes good focus but I
think we are seeing about what I would expect.
*> We have made great strides in understanding
*> the care and feeding of a TASS Triplet. However, in the past,
*> when there is a e-mail message describing a problem, it is buried under
*> many times that amount of analysis type messages. It would be
*> very useful for the people who have actually setup the TASS
*> camera's to document the problems that they ran into, or at least
*> subscribe to a sublist that will focus on those problems.
**> [quoting Marty]
**> Tom, we continue to make progress towards these
**> goals, but please keep the troops in the trenches in mind
**> when you pick through the mail bag. I would like to
**> know we are not alone when it comes to hardware and system
**> problems. Would you consider splitting you listserv into
**> "Programmers / Technicians" and put me in the
**> technician pile?
**>
**> Thanks,
**> Marty Pittinger, President
**> APL Amateur Astronomy Club
**> JHU/APL Laurel, Maryland
Tom and I had an online discussion of this sort a few months ago. We suggested
a set of keywords to put into the "subject" header, so people could
easily seperate messages by category. Nothing much came of it. Maybe this
idea should be revived? I myself can quickly look at a message and
decide its disposition, but of course this takes time and I limit my
email: your mileage may vary. Seems to me a subject header should
clearly represent the message therein. For long messages, a summary
at the beginning would be helpful too.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 15, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 17, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Feb 16, 1997
*> Herbert Johnson suggested that we summarize some of the hardware
*> problems that we have run into with TASS #5. The following is not a
*> complete list (that means I drew it from my memory):
Tom Droege
droege@wwa.com
Feb 17, 1997
Tom Droege
droege@wwa.com
Feb 17, 1997
> Telescope Control and Data Issues:
> Twice our data collection has gone over to pre-dawn hours (about 5-6am.)
> The data files indicate that the ambient light levels are too high to
> continue recording stars. At the end of the run, the sensors completely
> saturate including the dark current pixels on each line, and the
> temperature gauges indicated a sudden shift in temperature. The program
> eventually shuts down when it indicates a temperature of 135 C. The
> temperature does not really happen, it seems to be a controller failure
> brought on by the saturated system. (NOTE: At no time has our camer
> viewed the sun).
This problem is well understood, and will be corrected on the next
design. (But not fixed on this one). I am using 5 volt multiplexer
chips on a system with op-amps that connect to +/- 15 volts. When there
are out of range conditions, the amplifiers can present more than 5 volts
to the multiplexer chips. In this case a big signal can "spill over" into
a different channel.
> Alignment and Focus of the camera reminds me of the problems I had
> converging a color monitor (ie. I can never get a color monitor
> converged). We have seen the following problems:
>
> Alignment setting is not smooth, ie. it sticks and then overshoots the
> setting. (Need coarse and fine adjustment) I know it has silicon greese.
> I know it also sticks and then shoots past the setting.
The idea here was that I was trying to build a simple and cheap system.
The rotation only has to be done once. I figure things done only once
can be a pain to adjust.
> VCO setting seems unstable. A camera that seems to be completely
> aligned, in focus suddenly exhibits the symptoms of VCO setting errors.
Yep. The VCO is marginal for this design. In my case, the computer is
in my basement which is pretty constant temperature. I just leave it
on all the time, or start it up several hours before I start a run. At
least mine seems stable to 1 part in 1000 when warmed up. This should
be good enough but not great.
> We currently have CCD2 higher by 1 degree than CCD1 and CCD0. CCD2 and
> CCD0 both need alignment adjustment. It is also possible that the VCO
> may not be correct for these two camera, however, it seems correct for
> camera CCD1. We are still investigating this problem.
I at least notice that the I filter data is pretty fuzzy compared to the
V now that I have things adjusted. This may be the result of there
being no IR block filter. I hope that Michael R., our filter expert,
will give this some thought. For me there is a point where adjustment
does no more good.
> Saturated pixels on one camera become visible on the other cameras. We
> have seen examples (Mars images) that have the specular pattern repeated
> on the other cameras. This is a design issue, and there is nothing we
> can do about it.
Yep, this is the problem above. I just hope this does not turn out to be
a big problem for data analysis.
Michael Richmond
richmond@astro.princeton.edu
Feb 17, 1997
> ... This may be the result of there
> being no IR block filter. I hope that Michael R., our filter expert,
> will give this some thought. For me there is a point where adjustment
> does no more good.
If the problem were caused by light on the long-wavelength
side of the I-band filter "leaking" through in our I-band images,
then I would expect the (V-I) colors of stars measured from TASS
images would not match the standard (V-I) colors very well.
However, the little comparison I've done (see Technote 19) shows
good agreement.
SA 101 centered on (2000) Right Ascension 9h 56m
SA 102 10h 56m
SA 103 11h 56m
(as well as other fields at roughly one hour intervals). I can
provide people with images of these fields with lists of standard
stars.
Alain Maury
maury@ocar01.obs-azur.FR
Feb 17, 1997
Arne Henden
aah@nofs.navy.mil
Feb 18, 1997
> Tom, myself, and now Nick have noticed that it's harder to get nice,
> sharp images in the I-band images than in the V-band. Tom wonders
Herb Johnson
hjohnson@pluto.njcc.com
Feb 18, 1997
*> Tom, myself, and now Nick have noticed that it's harder to get nice,
*> sharp images in the I-band images than in the V-band. Tom wonders
*>
*> Another guess is that the lenses on current TASS cameras just
*> don't focus light well at wavelengths as long as I-band (around
*> 8000 Angstroms = 800 nm). I _hope_ that's the problem, because
*> one might simply try a more expensive lens...
Camera lenses do have a signifigant focus shift for IR, as I recall.
Some older cameras are marked for this difference, for the use of IR
sensitive film. The "solution" is to change focus with film, or in
this case with filters. The "not as well" part I can't comment on,
except generically that a set of lenses are optimized for a small number
of frequencies, with nonvisible ones given "lower priority".
Herb Johnson
hjohnson@pluto.njcc.com
Feb 18, 1997
*> This problem is well understood, and will be corrected on the next
*> design. (But not fixed on this one). I am using 5 volt multiplexer
*> chips on a system with op-amps that connect to +/- 15 volts. When there
*> are out of range conditions, the amplifiers can present more than 5 volts
*> to the multiplexer chips. In this case a big signal can "spill over" into
*> a different channel.
Can the outputs be bridged with zener diodes and regular diodes for positive
and negative overruns, respectively? I recall 5.1 volt zeners are
an available value.
*>> VCO setting seems unstable. A camera that seems to be completely
*>> aligned, in focus suddenly exhibits the symptoms of VCO setting errors.
*>
*> Yep. The VCO is marginal for this design. In my case, the computer is
*> in my basement which is pretty constant temperature. I just leave it
I've heard of a fix for temperature stability of crystals: namely,
a thermisitor in contact with the crystal which draws a current. Temperature
changes will change the current draw in the thermistor, which will act
against the temperature change. I don't recall if you need a positive or
negative coefficient thermistor on this. I've also heard of incadenscent (sic)
bulbs used for temperature/current stabilization.
*> It may be that the 0.916 line time is not the best one. I did some work
*> on this the other night and found a different number was better. I will
*> present this in a day or two. This just means that the lenses are not
*> exactly 135 mm in focal length. I would not expect them to be correct
*> to better than a few percent. If they do not match, then we are out of
*> luck to the extent of the match.
This is an interesting point: different lenses requireing different scan
rates. Running three camera at three scan rates would be too complicated.
But there is likely some least offensive value for each triplet.
Herb Johnson
hjohnson@pluto.njcc.com
Feb 18, 1997
*> I'm thinking of changing the rules from a tass camera owners contest
*> to a contest everyone can enter. The prize would go to the best production
*> software that turned TASS images into star measurement lists. I would then
*> put blocks of data up on the net for practice and anyone could enter. There
*> would be a number of things to be judged for "best". These would include
*> things like ease of use, availability of the platform used, accuracy of
*> the results, included tools, etc..
*>
*> What do you all think?
I'll be interested in working with the data, but I've decided my interests
are primarily in asteroids. I'll be curious as to what others do with the
same data. I hope you have some consecutive days's data for comparisions.
I'm going to start with some subtractive comparisons and look for shifts
and changes: maybe some variables will fall out of this. And I'll spend
some time on the various TASS Web sites to see what has been done. I'll
be using Windows and MS-DOS based tools, simply for my own convenience.
I have Linux 1.2.13 and can use it, but I want to get my hands in the data
and not with configuring a Linux system. When I've mucked around enough
to know something I'll get better or smarter tools.
Chris Albertson
chrisa@wavenet.com
Feb 18, 1997
> Camera lenses do have a signifigant focus shift for IR, as I recall.
> Some older cameras are marked for this difference, for the use of IR
> sensitive film.
Yes there is a "focus shift" but a better way to describe it for our
purposes (drift scan imaging) is that
the lens' focal lenght is a function of wavelenght. Could it be that
the VCO (scan rate) has been tuned by eye, using the V-band as a
reference?
If so, and if the V and I lenses are both at thier optimal focus
the I-band image should trail. Trail by enough to see? I don't
know.
Tom Droege
droege@wwa.com
Feb 18, 1997
E (I) M (V) W (I)
Left 1.78 1.40 1.68
Down Left 1.35 1.28 1.57
Down 2.18 1.49 2.21
Down Right 1.43 1.29 1.54
Right 1.65 1.39 1.68
What do others see for these focus numbers?
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 19, 1997
Michael Richmond
richmond@astro.princeton.edu
Feb 19, 1997
-------------------------------------------------------------------
AAS TO HOLD SESSION ON AMATEUR/PROFESSIONAL RESEARCH COLLABORATION
International Conference Management,
4709 Montgomery Lane, First Fl.,
Bethesda, MD 20814,
or call 301-913-9338, ext. 308;
fax: 301-913-5452;
e-mail: aas97@conference.com;
WWW: http://www.conference.com/aas/register.html;
anonymous ftp: ftp.aas.org/meetings/aas190/prelim/regform.ps.
Sky Publishing Corp. may provide limited financial support for
attendance at the meeting by amateurs with exceptional results or ideas.
Contact Leif Robinson at
Sky Publishing Corp.,
P.O. Box 9111,
Belmont, MA 02178;
e-mail: lrobinson@skypub.com.
Glenn Gombert
ggombert@infinet.com
Feb 19, 1997
Arne Henden
aah@nofs.navy.mil
Feb 19, 1997
fielde.pht
fieldi.pht
These files contain published UBVRI photometry in the 'E' and 'I' fields
for which I uploaded astrometric standards earlier. The current two
sources of photometry are Landolt and Lanz. USE THE LANDOLT STANDARDS
FIRST. The Lanz data is a compilation of UBVRI photometry from various
literature sources, has no error bars attached to it, and probably uses
Johnson I anyway. However, for setting zero points, Lanz's data is
probably ok. I deleted those Landolt standards that had two or fewer
measurements, as I do not consider those good enough to be standards.
I have also included all of the observed stars, even if they are too
bright or too faint for TASS, since there are so few stars anyway and they
might be useful for other systems.
Arne Henden
aah@nofs.navy.mil
Feb 19, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 19, 1997
Peter McCullough
pmcc@astro.uiuc.edu
Feb 19, 1997
Tom Droege
droege@wwa.com
Feb 19, 1997
Glenn Gombert
ggombert@infinet.com
Feb 19, 1997
Glenn Gombert
ggombert@infinet.com
Feb 19, 1997
http://www.brera.mi.astro.it/~carpino/ccdar
Tom Droege
droege@wwa.com
Feb 19, 1997
storm.fnal.gov
/ftp/incoming
Feb 2 Run:
Feb 12 Run:
Date Run Dir Filter Start RA End RA Comment
2 FEB 97 G2483921.FTS S I 198.2 201.5 EQUATOR
G2483931.FTS S I 201.5 204.9 EQUATOR
G0483967.FTS W I 199.8 203.2 EQUATOR
G0483977.FTS W I 203.5 206.9 EQUATOR
12 FEB 97 G2493900.FTS S I 200.2 203.5 EQUATOR
G2493909.FTS S I 203.5 206.9 EQUATOR
G0493946.FTS W I 201.9 205.2 EQUATOR
G0493955.FTS W I 205.2 208.5 EQUATOR
12 FEB 97 G2493623.FTS S I 100.2 103.6 ECLIPTIC
G2493632.FTS S I 103.6 106.9 ECLIPTIC
G0493669.FTS W I 101.9 105.2 ECLIPTIC
G0493678.FTS W I 105.6 108.5 ECLIPTIC
12 FEB 97 G1493669.FTS S V 101.9 105.2 ECLIPTIC
G1493678.FTS S V 105.2 108.5 ECLIPTIC
G1493946.FTS S V 201.9 205.2 EQUATOR
G1493955.FTS S V 205.2 208.5 EQUATOR
19 FEB 97 D0500244.FTS DARK
D1500244.FTS DARK
D2500244.FTS DARK
Herb Johnson
hjohnson@pluto.njcc.com
Feb 19, 1997
*> Yes there is a "focus shift" but a better way to describe it for our
*> purposes (drift scan imaging) is that
*> the lens' focal lenght is a function of wavelenght. Could it be that
*> the VCO (scan rate) has been tuned by eye, using the V-band as a
*> reference?
*> If so, and if the V and I lenses are both at thier optimal focus
*> the I-band image should trail. Trail by enough to see? I don't
*> know.
As I understand this, you are correct. Lens systems are "optimized"
to provide the same focus at more than one wavelength, and minimal
shifts between these wavelengths. As I said, IR is not usually one
of these optimized points. IN any case, the lenses do what they do.
Martin Pittinger
PittiMJ1@central.ssd.jhuapl.edu
Feb 20, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Feb 20, 1997
*> Users of Stardial have found an unexpected benefit of chromatic aberration:
*> red stars appear fuzzy (because the near-IR is out of focus with our
*> simple optical-light-optimized 50 mm lens). So if you are looking to
*> find some Mira or other long-period, large-amplitude variable star, the
*> likely subjects are the "fuzzy stars" on the images.
...unless they are solar system objects with a bit of motion. So I think
this is a necessary but not sufficient condition. If they are in the
same position the next day or so, and still fuzzy, that would be a
better indicator.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 20, 1997
Glenn Gombert
ggombert@infinet.com
Feb 20, 1997
Tom Droege
droege@wwa.com
Feb 20, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 20, 1997
> I downloaded star.exe, starsrc, commsrc, sortsao and ip.zip. I tried to
> recompile star because the executible had trouble finding the sao data
> files. I got three errors (microsoft visual C 4.2). Unresolved external
> symbol, two for IPStarlist and one for IPProgressMeter. Is something
> missing?
>
> Where should the SAO files be stored?
>
> Is there a proper way of access flat files for batch processing?
The SAO file "sortsao.txt" should have the path "c:\tass\sortsao.txt".
Glenn Gombert
ggombert@infinet.com
Feb 21, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 21, 1997
> Mike Gutzwiller is currently using a subset of the SAO catalog for his
> astrometric solution. This may be true for others as well, and I just
> wanted to remind folks that the SAO catalog has many errors and that
> the overall accuracy is often 3-5arcsec. Your cameras should be better
> than that, and your catalog should not be the limiting factor. I'd
I didn't realize the SAO was that poor for astrometric data. As a check
I just looked at the correlation of 9 stars from one night's image to
the next (clear) night's image. I measured residuals in RA of about
0.08 pixels, much better agreement than with the SAO positions.
> recommend using a subset of the GSC or of the USNO-A catalog for now,
> and probably the Hipparcos/Tycho catalogs when they become available in
> June. In addition, there is the USNO-SA catalog that is available free
> of charge on one CDROM from USNO-DC;
> check http://www.usno.navy.mil under PMM.
> (I don't recommend the SA catalog in general for TASS because of its
> specific nature and fainter set of included stars, but it is free after all).
> Someone should have extracted a small subset of one of these catalogs
> that can be used in place of the SAO. If not, I can do so with some
> effort (but then, what is sleep anyway?).
I just ordered the SA catalog (I like the price!) and will extract a
subset usable for TASS and the "star" program.
Glenn Gombert
ggombert@infinet.com
Feb 21, 1997
"batch -w tasslog.tm3"
Tom Droege
droege@wwa.com
Feb 23, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Feb 23, 1997
*> Princeton is submitting an NSF proposal. It is too long for me
*> to put up all of it, but the essence is to develop a plan to take
*> a lot of variable star measurements....
*> .... As a result of this agreement though,
*> you all will have a data base in which to put measurements.
*> There will also be a source for large area CCDs. It will be up
*> to you all as to whether you want to join in this effort.
This has happened at a good time for me. I've recently ended some
other projects, and I've been looking for a serious project to
do in astronomy.
Glenn Gombert
ggombert@infinet.com
Feb 23, 1997
Arne Henden
aah@nofs.navy.mil
Feb 24, 1997
Glenn Gombert
ggombert@infinet.com
Feb 24, 1997
Arne Henden
aah@nofs.navy.mil
Feb 24, 1997
> ...And (B). We will probably have many fewer reference
> stars than he is using and this "built-in" compensation probably will not be
> available in many TASS calibration runs.We might be "lucky" to have several
> reference stars per Photometric band for each camera. (Say a total of 5-6
> per TASS Camera run /evening).
My terminology is at fault. The normal photometric process for all-sky
photometry is to observe a set of photometric standards, optionally
calculate transformation coefficients, then apply the calculated zero
points and extinction coefficients to calculate the 'standard' magnitude
and color from your instrumental values for all desired objects. For
a typical TASS scan of many tens of degrees on the equator, you will have
many photometric standards for performing this calculation. However, you
must assume a photometric night, because these standards you are observing
are not observed necessarily anywhere close to the same time (since you
have to wait for them to transit).
> ...Many TASS cameras are
> operated in MidWest suburban locations that have light pollution and sky
> brightness varations to contend with. This results in the sky "glow" from
> Dayton deminishing as the night goes on which I am sure will considerably
> affect out measurments.
True. Sites near/in major cities may have to be satisfied with measuring
the brighter stars in the survey region. Since approximately 1percent of
stars show variability, this still means hundreds if not thousands of
variables that can still be measured from places like Dayton. Note that you
will be able to work on the fainter stuff later in the night, but will be much
more affected by cirrus than a dark site.
Glenn Gombert
ggombert@infinet.com
Feb 24, 1997
> "Normal differential work assumes that you have nearby reference stars
> (for photoelectric work, a COMParison and a CHECK star are common), whose
> standard magnitude and color are known, and then you perform differential
> calculations with respect to these reference stars. This allows you to
> use non-photometric nights since the reference frame is observed essentially
> simultaneous with the program object."
> What I am proposing is, for the equatorial TASS survey, a master list
> of reference stars (also called secondary standards) be generated for
> the entire 6degreex24hr zone. This list will be much smaller than all
> of the measured stars, as you want relatively
> high accuracy in the measurements,
> but will be much denser than the available photometric standards.
> The density will be such that several (say 6-12) secondary standards will
> be nearby any given program object, and so observers in non-photometric
> sites can perform differential photometry. The hard part is determining
> the master list, and that typically requires 3+ photometric observations
> per secondary standard (which is why either a camera needs to be installed
> at a good photometric site, or else a composite list be made from the
> photometric weather at multiple sites). Note that these secondary standards
> can be blended objects, as long as the digital aperture always measures the
> same centroid so that you get a constant reading."
> "Program objects (read: variable stars) should, in general, be free of
> crowding so that you get an accurate measure of the true magnitude and
> color of the object. Note, however, that you can get periods of stars even
> if they are blended with other objects; you just can't get good light curve
> shapes. There are techniques to handle blending which can involve some
> sophisticated programming that I won't get into here. The first iteration
> should be aperture photometry of uncrowded objects; then worry about the
> fine details."
Chris Albertson
chrisa@wavenet.com
Feb 24, 1997
Alain Maury
maury@ocar01.obs-azur.FR
Feb 24, 1997
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
Glenn Gombert
ggombert@infinet.com
Feb 25, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 25, 1997
> I have been looking a DAOPHOT for reducing TASS images. I think
> it uses a different algorithm then Sextractor. I'd be
> interested in expert opinion on the algorithms used by the two
> programs.
> ...
> The way I understand it, daophot works like this:
> 1) It convolves the input image with a model of the system PSF
> to create an image that has enhanced stellar images and reduced
> noise and background.
> 2) Steps through the above to find local maxima, writes these
> to a file. This is a first approximation of the object list.
> 3) For each object detected in #2 it attempts to fit a
> parametric model of the PSF to the image data. The PSF model
> need not be constant over the frame. Daophot uses an iterative
> method to fit the PSF to a group of stars at a time. The PSF is
> allowed to have several parameters and the curve fitting could
> take a while so a limit may be placed on the number of
> iterations.
The "star" program I've created is similar to daophot. I need to create a
technical note to discuss the details but basically here's the algorithm
after the image has been dark and flat corrected:
> I have run the program on TASS images. It seems to work well
> even for overlapping stars. It will detect and measure stars
> that are about 1/2 of a PSF apart. It turns out these are
> common in TASS images.
>
> I'd like to compare results with those people are getting with
> Sextractor. If anyone has a TASS image and a matching list of
> objects would they forward them to me or if already posted let me
>know where.
Tom posted some images on storm.fnal.gov last week and the results I got with
"star" are packed in the file "stars.zip" in the "incoming" directory.
I think it would be good to compare the results obtained with different
packages against the same set of images to get a feel for each package's
performance.
> Another question that sounds very basic: Given two object lists
> created from the same image, how do you determine which is
> ``better''? Yes, I know once you define better then it is easy,
> but how do we define better for our purposes? I would compute
> the intersection between each list and the GSC then assume the
> longer list is better.
"Better" of course depends on the intended use of the object lists. I am
mostly interested in variable stars so for me "better" implies better
photometric results. For someone interested in asteroids "better" implies
more complete detection and better astrometric results.
Michael Richmond
richmond@astro.princeton.edu
Feb 25, 1997
At the end of this process, one has a dense set of many
stars that cover the ENTIRE celestial equator. Now, it is true
that there will be small systematic errors that build up as
one goes from Landolt stars to SECONDARY to SECONDARY' to SECONDARY''.
However, with enough relative measurements (say, 20-30) of
each set of stars _directly_ against each other, one can solve
for a large set of stars which are consistent with the primary Landolt
standards, yet do cover the entire equator.
I am currently extracting aperture photometry for Tom's images,
using my own software. When I'm done (today? tomorrow?), I'll
make some comparisons against the instrumental magnitudes that
Mike Gutzwiller has already provided. I'll also make my
measurements available for perusal by all. I hope that other
people will provide measurements made with other packages, so
that we can all take turns comparing our results to those of
other people. We will undoubtedly learn a LOT from this.
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
James Bush
jbush@shell.flinet.com
Feb 25, 1997
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
Michael Richmond
richmond@astro.princeton.edu
Feb 25, 1997
So I think Arne is right: give his suggestion a try -- if it works,
you are done! Hooray!
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
> My motivation in listing a multi-step procedure that expands outwards
> from the Landolt fields was to avoid errors in transferring the
> photometric solution defined by the Landolt fields over _time_.
> It will be a full hour from one set of Landolt stars to the next.
I don't disagree with this statement. In addition, with the TASS
cameras at a given site pointing 15 degrees apart along the equator,
there will be a time difference in the transits of a given star and
therefore a time difference between V & I measures. At the same time,
if you DO have a photometric night, you remove at least one level of possible
errors and get the reference frame directly. Plus, in your scheme,
you have to keep moving 3 degrees/time until the entire region is
filled in, which might be more than just one level of extra standardizing
and is certainly more work.
> Of course, once ONE person, at a good site, calibrates a set
> of SECONDARY stars, everyone else, at all sites, can use them!
I agree! You may have to vote as to whose data is better or how
to combine the datasets, but then everyone is on the same system.
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 25, 1997
> Mike Gutzwiller, Chris and others have been talking about better approaches
> to handling blended images than straight aperture photometry. I've used
> DAOPHOT with good results, but it is a strong learning curve. There are
> several other packages, such as DoPHOT, Mike's star, the MACHO/OGLE/SDSS
> schemes, etc. that can also be used.
>
> I think that aperture photometry should be used for most of the work.
> It is just a lot simpler and more reliable. Saying that, the big
> caveat is crowded regions such as the galactic plane. Here you may
> want to generate an automated psf-fitting version of the extraction
> program. However, beware! Aperture photometry is reliable because you
> use the same aperture for all measurements. Also, ALL of the Landolt
> standards
> were generated using aperture photometry. If you start using psf
> photometry, the effective aperture size changes on a frame-by-frame basis,
> and the results generally have more absolute scatter than aperture
> photometry.
>
> I find psf fitting to work well for differential photometry, but
> aperture photometry to work better for 'standardizing' the secondary
> standards.
The "star" program's aperture can vary from one frame to the next if the
size of the psf changes. Since TASS psf's are a function of the VCO timing
this can happen. The magnitude values that "star" outputs to the list are
the aperture sums, not the psf fitted values. The psf fitted values in the
correlated images are used for several purposes:
I expect that a good bit of tuning of all the packages will need to be done
before the "best" one can be selected.
Glenn Gombert
ggombert@infinet.com
Feb 25, 1997
Tom Droege
droege@wwa.com
Feb 25, 1997
Tom Droege
droege@wwa.com
Feb 25, 1997
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
Allen Gilchrist
gilchris@ipxpress.aws.waii.com
Feb 25, 1997
> those stars that
> were measured when the cloud went through would be fainter than the mean
> and would show up as false variables.
Tom Droege
droege@wwa.com
Feb 25, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 25, 1997
> Several of you have already said that you would like to join in this paper.
> It is time to agree on what we will try to do. So I am posting these notes
> to try to get an agreement as to what we will do *for the June meeting*.
> I figure we have to be running the whole process in March (very soon) if we
> are to plan to present something June 10. We can add new data, but the
> process needs to be fixed very soon!
The APL group will do all it can to help out. If our telescope is
aligned and focused in time, we will try to process the data to meet the
requirements of your project. I am still having problems with the star
program (can't seem to read SAO catalog). I suspect it is hard coded to
a particular disk drive.
Michael Richmond
richmond@astro.princeton.edu
Feb 25, 1997
Field A: RA = 12:30 - 12:45 Dec = +0
Field B: RA = 08:45 - 09:00 Dec = +0
Each field is about 4 degrees long, which means that it can be
covered in 15 minutes of scanning, and will make a strip about
1.5 times longer than it is wide (this is nice for display purposes).
A single image of each field
would be about 1.5 Megabytes in size. This seems reasonable for
several purposes; for example, a single image would fit onto a
3.5-inch floppy disk. Moreover, I can and will provide the disk
space to store
- all raw/reduced images of these fields people can send me
- all starlists from these fields people can send me
The Field "A" is at a high galactic latitude, so the stars are
widely separated. It covers the same area as the FASTT "I" field,
for which Arne has supplied astrometry, and in which Arne knows
the locations of all the variable stars. It contains the field
SA 104, which has many Landolt standards. In a sense, we already
"know the answers" for this field -- so we will realize we're
doing something wrong if we don't agree. Field "A" is also close
to the ecliptic, which means that asteroids will be whizzing
through it every night.
Chris Albertson
chrisa@wavenet.com
Feb 25, 1997
> Here is what Kodak says:
>
> Pixel 1-10 Empty Shift Register Phases
> Pixel 11-14 Non-imaging pixels
> Pixel 15-782 Photoactive pixels
> Pixel 783-794 Non-imaging pixels
> ...
> Note that there is nothing to restrict one from shifting a few extra times
> after pixel 794. Someone will have to look at the actual FITS line to see
> what is there. There is also a chance that the pixels are off one or two
> counts either way.
I did this and Normans documentation is correct execpt that he counts
from zero not from one. Here is a quote from the documetation:
NAXIS1 = 768 of these 800 pixels contain actual image data
pixels 0 to 9 are 10 dark reference pixels in ADUs
pixels 10 to 13 are 4 blind pixels (whatever that is) in
ADUs
pixels 14 to 781 are 768 image data pixels in ADUs
pixels 782 to 791 are 10 dark reference pixels in ADUs
pixels 792 to 793 are 2 blind pixels (whatever that is) in
ADUs
pixel 794 is a false pixel with CCD temperature in ADUs
pixel 795 is a false pixel with coolant temperature in ADUs
pixel 796 is a false pixel with peltier current in ADUs
pixel 797 is a false pixel with positive supply in ADUs
pixel 798 is a false pixel with negative supply in ADUs
pixel 799 is a false pixel with 0 (reserved for future use)
pixel 794: resi is the thermistor's resistance in kiloohms
pixel 795: resi is the thermistor's resistance in kiloohms
resi = (196592400 / (ADUs - 32768)) - 1000;
if (resi < 1300) resi = 1300;
temperature = 136.55 - 77.246 * sqrt (log (resi) - 7.1671);
pixel 796: curr is the current in amps (current sensing resistor: 0.12
ohms)
curr = (0.0000763 * (ADUs - 32768)) / 0.12
pixel 797: volt is the voltage in volts
pixel 798: volt is the voltage in volts
volt = (0.0000763 * (ADUs - 32768)) * 3.0
+++++++++++++++ end quote++++++++
> The Non-imaging pixels are not simple covered pixels. I think there is
> something done so that they have a preset charge - possibly zero and
> full scale. But the data sheet does not burden one with facts about
> what they might have done.
I looked at the "non-image" pixels in some detail a while back. Some
act as if they are covered but possably not the same size as the image
pixels. That is they collect dark current at a diferenct rate. Not all
colums act the same either.
I was looking for a way to estimate the dark current and thought
the "covered" pixels would be helpfull. I looked at how the non-image
pixels tracked the image pixels in frames taken with a lens cap on
My conclusion was that yes you can use (some of) them for that purpose
but it
is not so straight foreward as one would hope. . I was working on
procedure to scale a dark vector by a factor based on an estimate of
the dark current derived from the dark pixels. Works well to
within 1 ADU. I have details if anyone has interest.
> Michael, don't hold your breath while waiting for data from Kodak. First
> you will get something slick that tells you how great Kodak is. Much
> later you might get some real information.
Tom Droege
droege@wwa.com
Feb 25, 1997
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
> ..Some people may say, "That's a piddling amount of sky!"
However, each field is 12 square degrees, and that equals the largest
CCD surveyed region in the literature!
Arne Henden
aah@nofs.navy.mil
Feb 25, 1997
> ...What about developing such standards for new parts of the
> sky?
If you move off of the celestial equator with the TASS cameras, you
quickly run out of Landolt standards against which to calibrate the
secondary standards. One method is to have a conventional telescope,
such as the 1.0m here, provide a set of secondary standards at any given
declination zone, and then calibrate the secondary standard reference
frame (I guess they would then be called tertiary standards?) against
them. We get away with it on the FASTT telescope since it can slew in
Declination and pick up equatorial Landolt standards as they transit,
even though we are actually scanning some zone off the equator.
> The photmetric data from the new Hipparcos satellite will soon
> becoming avaliable. Will this new source of data add significantly to the
> current standard stars that we have? How will this affect the proposed
> efforts to develop secondary standards in the +/- 3 degree stip of the sky
> that we are presently looking at??
The Hipparcos and Tycho data will be B & V, and will not provide TASS
with any I data. Otherwise, it sounds good. Interestingly enough, the
DENIS near-infrared survey is surveying the Southern sky at IJHK, and
so could provide the I-band counterpart for the B&V Tycho data for TASS
cameras working in the southern hemisphere. Too bad we don't have such
a survey in the north.
Jure Skvarc
SKVARC@eros.ijs.si
Feb 26, 1997
Herb Johnson
hjohnson@pluto.njcc.com
Feb 26, 1997
*> I have been following as best I can all the discussions of photometry
*> and calibrations. I think there are two things we can try to do:
*>
*> 1) Explore the territory
*>
*> 2) Make measurements
In this context, I'll be working on some of the results that will
fall out of (other people's) processing of Tom's data sets
he recently posted. I think these can serve as a "reality check" across
the various programs and methods in use. So in general I'll encourage
folks to enhance the utility of this dataset as appropriate, and Michael
Richmond plans to keep it around for this reason. I'll contact individuals
on my findings. I'm not going to add much to the discussion, not from
lack of knowledge or experience but because those bases are already
covered!
Arne Henden
aah@nofs.navy.mil
Feb 26, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 26, 1997
> What do the rest of you on the maillist think of the SMSP concept?
Like Tom I would prefer a later field than Michael's B purely from an
operational point of view. I usually start TASS running near bed-time
since I'm using that computer for other purposes till then. I could
rearrange my systems so TASS runs on another computer with a little
investment though.
Glenn Gombert
ggombert@infinet.com
Feb 26, 1997
Glenn Gombert
ggombert@infinet.com
Feb 26, 1997
RA "14:36:28.5" DEC "-01:03:44" and the exact image scale is
13.63 arcsconds / pixel.
Arne Henden
aah@nofs.navy.mil
Feb 27, 1997
1-10 empty shift register phases (i.e., these shift register
pixels isolate the output amplifier from the array).
Looking at the FITS files, there is an exponential
ramp-down on these pixels (common to readout electronics),
and so I do not use these 10 pixels for anything. They
have not even reached dark level by column 10.
11-14 non-imaging or blind pixels. These do not seem to be usable.
The first pixel is considerably above sky level, and then
the remaining 3 pixels exponentially decay to about dark level.
Note: this is common, as the first column in an array usually
gets dark-current bleeding from the surrounding silicon (which
cannot be reset).
15-782 imaging pixels
783-794 non-imaging or blind pixels. I use these for setting
dark and bias levels. Michael has noted that the first
couple of these pixels are dependent on the signal level
on the imaging array (also common with most electronics),
so it is best to use the rightmost pixels and avoid the
first few columns. Kodak does not divide this into 'dark'
and 'blind' sections as the FITS header implies.
795-800 Various engineering parameters (added by the data acquisition
program and not included in Kodak's specs).
Therefore, my understanding is:
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 27, 1997
Michael Richmond
richmond@astro.princeton.edu
Feb 27, 1997
Arne Henden
aah@nofs.navy.mil
Feb 27, 1997
camera 0: 13.727 arcsec/pix +- .005
1: 13.733
2: 13.760
This actually should be pretty constant, since it is at least half-derived
from the clocking rate. The big trend should be in the x- or declination-
direction where the camera focus comes into play.
Glenn Gombert
ggombert@infinet.com
Feb 27, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 27, 1997
# Analyzing image "E:\TASS\ACQUIRE\432\30T0432.820"
# Image noise level was 65 ADUs
# PSF size was 9x7 pixels
# 1102 stars detected
the lines are:
If the catalog match failed or a psf couln't be found or the e-mail
option was selected the header will be slightly different but all
header lines will start with a "#".
186.877 105.149 220877 596 95.647 -0.234 7.640 0.003
^ ^ ^ ^ ^ ^ ^ ^
1 2 3 4 5 6 7 8
Each field is separated by spaces.
Chris Albertson
chrisa@wavenet.com
Feb 27, 1997
> Michael and others have asked me to detail the contents of the star lists
> my "star" program generates so here goes:
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 28, 1997
> What was the detection threshold set at for the stars in the
> lists posted on
> www.astro.princeton.edu/~richmond/tass/tom_feb97/tom_feb97.html
> Was it 3 sigma or what?
For the Tom's images I set star up with the defaults, i.e. a
sigma limit of 5.0 and a sum ratio limit of 1.75.
> I am getting results a lot like yours with daophot but I can
> make my lists either shorter or much longer then the ones you
> posted by making small changes in the program's parameter file.
> I am going to have to "tune" the algorithm but I'd like to
> shoot for the same sigma above noise value as everyone else.
>
> Also how do you define the background noise? I am simply
> computing stats on "blank" areas of the image and comming up with
> about 50ADUs or less. Within 5% of your estimates.
It's a little complex but here goes.
noise = (84.13th percentile value - 15.87th percentile value)/2.828.
> Also could you explain briefly your approach to dark/flat
> processing.
I use my "dark" program to create a dark vector from a dark image. Each
value in the dark vector is the average of all values in its column in the
dark image. Tom's temperature regulation is good enough that a single dark
vector for a camera is stable over an entire night's run and even runs done
on separate days.
> I am proceding through Tom's raw data files in parallel. Doing
> all the dark/flat processing on each file then all the
> detections. I now have star lists for all files. Takes about 45
> seconds per
> file to do the detection. (Intel P100. I'll try the Sun SPARC Ultra
> later. I estimate 4x faster on Ultra)
>
> Next I'll work on astrometric corection based on Hubble GSC.
> I hope to have an independant data reduction chain working in the
> next few weeks.
Performance of "star" is similar with reduction taking a little over 1 minute
per image on my home system (486 DX4 100, 32 Mb, Windows 95).
Glenn Gombert
ggombert@infinet.com
Feb 28, 1997
Tom Droege
droege@wwa.com
Feb 28, 1997
Arne Henden
aah@nofs.navy.mil
Feb 28, 1997
> ...I also worry about background
> gradients even without the moon in the sky. All in all I'm trying to
> determine a better way to get flat vectors. Anybody have suggestions?
Getting good flatfields with a drift scan system is probably the
hardest part of the data reduction. For FASTT, we point to the zenith
and take twilight flats; but you can't do that with TASS. Chromey and
Hasselbacher (PASP 108, 944, 1996) show that, near the zenith, there is
a zone where there is no gradient in the night sky. When you get off
the zenith, like on the celestial equator where TASS is working, the
twilight gradient is on the order of two percent per degree. This is
also the case for 'dark' sky flats, where the moon will give unacceptable
gradients, as well as any horizon light source like a town. Likewise, like
Mike mentioned, if the sky is varying (for instance, the Feb2 data), stars
will contribute even on median flats (evidenced by dark streaks in the
processed images where you are overdividing by the flat). I don't
trust any of the median flats from the raw TASS images because of errors
like this.
> Could milk glass (waxed paper?) diffusers be used to provide a source of
> diffuse transmitted light for twilight flats instead of white cards as
> reflectors? The mechanical arrangements might be simpler, and there would
> be no worries about different angles for each camera in the system.
The problem I see with just a diffuser is that it is diffusing transmitted
light rather than reflected light. I don't think it changes the basic
gradient (though I could be wrong - any optical designers out there?).
What you want is a 'Lambertian' surface, one where the reflected
light indicates no knowledge of where the incident light came from. That is
why I suggested a white card, though other surfaces are probably better.
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 28, 1997
> I think the best way would be to hold a white card in front of the cameras
> during twilight and use that as a reflected, diffuse source of light.
> For standard CCD observing, you take flats every evening because they change
> as dust falls on the filters, etc., and TASS may have to do the same since
> the cameras are in a harsher environment than most observatories.
I have some problems with this approach. First, we have noticed that
predawn sky is enough saturate the sensor. One problem with the TASS
design, is when the sensor is saturated (the entire field, not just
around a bright object), entire control board eventually bleeds the data
into all of the data being collected by the multiplexor, including the
thermocouples. When that occurs, the TM3GET11 program shuts down (it
sees a very high temperature). What time to you consider twilight?
Arne Henden
aah@nofs.navy.mil
Feb 28, 1997
> I have some problems with this approach. First, we have noticed that
> predawn sky is enough saturate the sensor. One problem with the TASS
> design, is when the sensor is saturated (the entire field, not just
> around a bright object), entire control board eventually bleeds the data
> into all of the data being collected by the multiplexor, including the
> thermocouples. When that occurs, the TM3GET11 program shuts down (it
> sees a very high temperature). What time to you consider twilight?
I usually take flats at half-well, as this is usually a linear region
with good signal/noise. For TASS, 'twilight' could be defined as that
time after sunset / before sunrise where the sky brightness is half-well.
Since the sky is constantly changing during this interval, You would
probably only use a few rows around that time, scale by the mean and
median filter them.
> I had been assuming that the flat field that is used in the star program
> is the result of the median filter (background determination). At that
> point, the background is calculated and then anything below the
> background is shunted to zero.
The median filter for flatfielding in the star program gives you a 'master
sky flat'. This is then divided into the raw data to correct for Quantum
Efficiency variations (column-to-column) and also to remove vignetting within
the camera. Both of these effects are multiplicative, which is why you do a
division. For calculating the magnitude of a star after flatfielding is done,
you sum the ADU within the aperture and subtract a mean background (a
subtractive event). But never shunt anything to zero -- negative numbers
after a background removal are just fine.
Martin Pittinger
PittiMJ1@central.ssd.jhuapl.edu
Feb 28, 1997
Unit -6
Year -7
Day -231 (Julian)
Hour -e (a-z = 1-24 [less I (i) & L (l) )
mm -23
Examples:
67231c15.fts
67231c28.fts
67231c42.fts
67231c56.fts
67231d09.fts
67231d21.fts
------------------------------or-----------------------------------
Unit -6
Year -h (a-n, less i & l)
Day -31
Hour -e (a-z = 1-24 [less I (i) & L (l) )
mm -23
Examples:
67h19b15.fts
67h19b28.fts
67h19b42.fts
67h19b56.fts
67h19c09.fts
67h19c21.fts
Michael Richmond
richmond@astro.princeton.edu
Feb 28, 1997
1. The pixels in columns (zero-indexed) 784-791 may be
good sources of a bias/dark level
2. There is a puzzling anti-correlation between CCD temperature
(as recorded in column 794) and bias/dark level
3. I goofed when constructing flatfield vectors for
this analysis (improperly removing the bias/dark contribution)
4. The FWHM of the images range from 2.2 to 4.4 pixels.
The V-band images all have smaller FWHM than any
I-band image, and there may be a tendency for the
focus to be best near the north edge of the frame
5. I used a 5-sigma threshold to find stars, which does not
find all the stars which one can see clearly by eye, but
nonetheless produces 400-1200 stars per frame
6. I measured instrumental magnitudes for each image, using
several apertures, the main one having a radius equal to the FWHM
7. Astrometric calibration against the GSC yields positions
with a precision of about 4-5 arcsec. This is about
one-third of a pixel, which is larger than one would expect.
The scatter is probably not due to distortion across the
wide field of view
8. There are Landolt standards in each pair of images
which can be used for simple, zero-point photometric calibration;
however, since the set does not include images in both
V and I of the same field, one cannot check for color terms
9. Comparison of instrumental magnitudes against each other,
or against the Landolt stars, reveals a precision of
about 0.05 magnitudes for bright stars,
about 0.10 magnitudes for faint ones
Again, anyone who works on these images, please send me copies
of your analysis and (if you include large data files) a description
of your data files. I'll put all of the information at
Arne Henden
aah@nofs.navy.mil
Feb 28, 1997
Glenn Gombert
ggombert@infinet.com
Feb 28, 1997
File Name: Number of Objects Detected:
R0483967.CAT 883
R0483977.CAT 787
R0493669.CAT 2819
R0493678.CAT 2932
R0493995.CAT 873
R1493669.CAT 2696
R1493678.CAT 2503
R1493946.CAT 830
R2483926.CAT 924
R2493623.CAT 2432
G2483931.CAT 987
G2493900.CAT 849
G2493909.CAT 852
X-Pos Y-Pos Aperture Mag Aperture Mag Error Star-FWHM Local_Background
where the "Local_Background" is given in ADU.
Glenn Gombert
ggombert@infinet.com
Feb 28, 1997
Mike Gutzwiller
Michael_Gutzwiller@AICI.COM
Feb 28, 1997
Nick Beser
beser@aplcomm.jhuapl.edu
Feb 28, 1997
Chris Albertson
chrisa@wavenet.com
Feb 28, 1997
> As way of background, I have a remote procedureal call utility that
> allows windows 95 to respond to a remsh or rsh from unix. We will turn
> on the TEC power via a CGI script on our homepage. We will then perform
> periodic rsh to the tass computer to sample the temperature and
> voltages. If the temperatures and voltages don't look correct, we will
> turn off the power.
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.
> 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.
Chris Albertson
chrisa@wavenet.com
Feb 28, 1997
> Seems to me it is time to start using a standard naming convention for
> files? I can imagine a lot of things that could be coded into the file
> name. But I am the wrong one to do this. Any one want to vonunteer?
> How about it Chris? Or one of you other lurkers that has a lot of
> experience manipulating data?
I assume many people are still limited by DOS's 8.3 filenaming
restriction.
30T9999.999
1st digit = 3 for TASS Mark III camera
2nd digit = 0,1,2 for CCD0 (west), CCD1 (center), CCD2 (east)
letter T for TASS: The Amateur Sky Survey
four digits: days since Julian Date 2450000
the dot separates the filename from the extension
three digits: fraction of day in 1000ths since 12h00 UT
I will propose a convention very close to what Tom used when
he posted his data to Storm's incoming directory.
TCdddttt.typ
T - Type code. "D" for Dark framme, X eXperimental.
F Flat, R normal Raw data, P Processed image.
I see this as an open ended list. We do not need many
diferent types. "B" for SMSP-B field data and so on.
It is not to bad for a letter to be used for two purposes
if it is clear from context and not ever used in the
same directory. (used a TXXXXXXX.TXT file. see below)
C - Camera, 0, 1, 2.
ddd - low order Julian Date from tm3get file.
ttt - fraction of day from tm3get file.
typ - fts, gif, obj (object list), txt and so on.
I think this is easy and close to what people are doing now so
we will not need any filename police to force the standard.
Chris Albertson
chrisa@wavenet.com
Feb 28, 1997
> I have similar conclusions to Michael. I am a little concerned that
> the image fwhm is not better, and would propose taking some additional
> test data to check where the degradation is occurring.
I suspect it is about as good as it can get given the optics,
pixel size and focal lenght.
> With the current
> fwhm numbers, I don't see astrometric accuracy per frame getting better
> than 1.5-2.0 arcsec, which is pretty crude.
How much astrometric accuracy is required to perform the
desired functions? I assume those functions are
