Bill Gray
168 Ridge Road
Bowdoinham, ME 04008
ph (207) 666 5750
(800) 777 5886
Internet: pluto@projectpluto.com
CompuServe: [71736,3544]
13 Jan 97
~TCONTENTS~t
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
1
2
2
3
6
7
8
9
10
12
Description of CHARON
Reasons why CHARON was written
Current status of the software
Starting and using CHARON
Settings in CHARON
Making reports to the MPC
Use of FITS files
The future
Method used to find stars in image
Reduction methods
Following is some information concerning the CHARON
astrometric data collection software. The purpose of CHARON is
to enable users to extract positional (and, eventually,
photometric) information from CCD images and scanned images
with a minimum of work; preferably, zero work. The current
version is on the enclosed floppy.
As will rapidly become apparent, CHARON is a work in progress.
To my knowledge, it currently does a good job of measuring
positions on CCD images. If you find any problems, or have
_any ideas for improvement_, please let me know!
DESCRIPTION OF "CHARON" ASTROMETRIC SOFTWARE
With CHARON, one must provide an image, specifying either
the object or an approximate position in the sky. Charon will
then examine the image you've taken, and will search through
the GSC database on the Guide CD-ROM, and find stars in the
GSC corresponding to those in the image. It then will
calculate the transformation between J2000 RA/dec and positions
in the image.
Once it has done this, it has registered the image to the
sky, and will show you the image with GSC stars superimposed
as an overlay. You can move the cursor around and collect
information concerning the RA, declination and magnitude of
objects in the image. You can hit Tab to immediately zoom in
on the target object; CHARON will show both the computed,
"expected" position of the target object, as well as its
actual observed position in the image, and the difference
(observed - computed, or "O-C", or "residual") between them.
Finally, one can produce a report on the measured position
of the object in a format suitable for submission to the Minor
Planet Center (MPC) or International Occultation and Transit
Association (IOTA).
REASONS WHY "CHARON" WAS WRITTEN
There is a fairly serious need for better follow-up on newly
discovered asteroids. Once an asteroid is found, it takes a
bare minimum of three observations to determine its orbit;
in
reality, it generally takes more observations, made over a
longer period of time, to eliminate uncertainties. Quite a few
Guide users have asked me about the subject of astrometry
software. As things stand today, many observers spend much
more time analyzing the data than they do in collecting it.
Software to remove most of the "drudgery" would let them spend
more time doing something more interesting.
This seemed a logical task for me to untake; I already had
most of the required software components, as well as all the
data handily compressed to one CD. I felt it would be a useful
contribution to astronomical data collection, and I also
thought it would just make an interesting project.
CURRENT STATUS OF THE SOFTWARE
As of this writing, CHARON is in beta testing. I'm working
to collect as many images as possible in an effort to find
where the software breaks down. So far, it doesn't. As long
as the image contains at least three or four GSC stars (three
usually works, four always does), the software always finds a
match, and is then able to improve it by doing a least-squares
fit to all GSC stars in the area. It generally does this in
one to three seconds on my 486 DX2/66, depending on the number
of GSC stars it has to check.
It is quite tolerant of poor input data. The images I have
provided have had many extra stars not in the GSC, and the GSC
has shown objects not found in the images. Giving it a poor
input position doesn't confuse it; tilted and inverted images
are not problems. One does have to provide at least an
approximate image scale. (As you will see, this is not
_absolutely_ necessary, but without it, the software is much
slower.) Fortunately, most images provide some data on the
physical size of the pixels and on the focal length that was
used to acquire the image; the approximate image scale can be
easily computed from that data.
I have tested it with a variety of SBIG images (ST4, ST5,
ST6, and ST7), as well as with .PIC files generated by MIPS
(which are not in the "normal" .PIC format). I've tested a
very few FITS files, and their use is described in a further
chapter. Support for ST8, Starlight Xpress, and Cookbook CCD
Camera images will probably be added. I'm still in the
process of adding new types of images; if the software
doesn't work with your image format, please send me some
sample images on a floppy, and I'll add support for them. In
fact, I'd appreciate any images you can send me; I'd like to
test the software with as diverse a set of images as possible.
A sampling of images is included on the Guide 5.0 CD-ROM, in
the IMAGE subdirectory.
STARTING AND USING CHARON
You'll want to start by copying this floppy into your Guide
directory. For want of a good, descriptive name, the software
is currently called CHARON (as in the name of Pluto's moon). It
requires the same mouse driver as the DOS versions of GUIDE, and
the Guide 5.0 CD has to be in the CD-ROM drive. For demonstration
purposes, I asked Dan Kaiser for some sample .ST6 images, and
they're already on the CD-ROM. To see the software in action on
one, run
charon f:\image\hbaug22.st6 -ocHale-B
where:
f: should be replaced by the CD-ROM drive letter.
hbaug22.st6 is,
of course,
the name of the .ST6 file.
-ocHale-B tells it that the object in question is comet
(hence the c) Hale-Bopp. (You don't need the entire name;
just enough to uniquely specify the comet you want.) When
combined with the date and time stored in the .ST6 file, this
specifies where in the sky the target is. There are several
other -o switches for different classes of objects; for
example,
-oa4179
-oaToutatis
-oa1992 CM
-ocHale-Bopp
-osao 123456
-oppm 234567
-ovru cam
-onsv 13211
-ongc 4565
-om57
-oic 456
-osn 1993J
-ogsc 1234 5678
-p132.2,-21.2
Object is asteroid 4179
Object is asteroid Toutatis
Object is asteroid 1992 CM
Object is comet Hale-Bopp
Object is SAO 123456
Object is PPM 234567
Object is the variable star RU Cam
Object is NSV 13211
Object is NGC 4565
Object is Messier 57
Object is IC 456
Object is the supernova 1993J
Object is GSC 1234 5678
Object is at RA 132.2 degrees,
declination -21.2 degrees
The software will pause for a bit while it figures out
Hale-Bopp's position as seen at that date and time. It
will then pause some more while it grabs GSC data for that
region and looks for a match. All this may take a few
seconds. When it's done, it will spit out the results of
its match. For the Hale-Bopp image, CHARON finds 9 Guide
Star Catalog stars in the image that match within a
tolerance of 1 arcsecond. It spits out some details of
the match, such as residual values. It also computes the
focal length using both the computed height and width of a
pixel; these values should match fairly closely. The
angle between the axes is also computed, and should be
very close to 90 degrees.
Hit a key, and the software will clear the screen and
show you the entire image. Superimposed on this are green
crosses showing the GSC stars (remember Green=GSC), and
red circles showing the stars CHARON found in the image.
Also, the cursor appears as a yellow cross.
As you move the cursor around, its position in RA/dec
is shown in the upper left corner in yellow (same color as
the cursor). The position and identifier for the nearest
GSC star are shown in green (matches the GSC stars in
question), and the position for the nearest image star is
shown in red (matches the image star).
The calculated target position option is shown with the
full-screen red cross. In theory, the actual target
should appear near that position, and sure enough,
Hale-Bopp lies right on the cross (you may need to adjust
the contrast to see it, though.) A small red circle marks
CHARON's idea of the center of Hale-Bopp in the image;
move the cursor there, read the position in red from the
upper left, and (in theory) you're done.
You can pan by clicking with the mouse or using the cursor
keys. (Cursor keys alone pan half a screen; Ctrl+cursor
keys pan one image pixel at a time.) Key commands are as
follows:
? to bring up a "help screen" listing these keys (MOST
IMPORTANT, since it can spare you constant referring to
this page)
* to increase contrast
/ to lower contrast
+ to brighten the image
- to dim the image
These four controls roughly follow the user
interface of a TV set, which provides "brightness"
and "contrast" controls. We can worry
about something fancier later, if needed.
5 (center of numeric keypad) to zoom in twofold
Insert to zoom out twofold
Space bar to return to full-image view
Tab to center on the target object (as marked by the big
red crosshairs)
i to produce a position report in IOTA format
o to produce a position report in MPC format
f to change the format of RA/dec positions
r to toggle the image from white stars on black to black on white
g to toggle the display of the GSC stars
t to toggle the display of the "target" (image) stars
c to add a new star at the position of the cursor
Delete to delet a star from the image
You can also measure distances and position angles in the same
manner as in Guide: click with the left mouse button and drag the
mouse. The distance and position angle are updated in the legend
area as the mouse is moved, and a "rubber band" shows the line
being measured.
SETTINGS IN CHARON
The easiest way to get to the settings menu is to run Charon
with absolutely no command line arguments at all. Change the
needed settings and hit Escape, and your changes will be saved.
Also, you can access the settings menu while Charon is running
by hitting the Enter key.
In either case, you're presented with a list of about a dozen
settings. You can move from line to line with the arrow keys,
and edit the values in the fields. There is some help provided at
the bottom of the screen for each line.
Report file name: This defaults to MPC.LOG, and is the name
of the ASCII text file to which MPC and IOTA reports will be
appended.
Cutoff point: This defines the percentage of the image
considered to be "background". It defaults to .97, meaning
that 97% of the image is assumed to be background, with 3% of
it being valid stars. You will probably never have to change
this setting.
Image offset: This setting is used for images where processing
may have created pixels with negative values (after dark fields
have been subtracted, for example.) It defaults to zero.
Scale tolerance: By default, this is set to .01, and means
that CHARON will handle up to a 1% error in the approximate focal
length. This is usually far more than enough to allow for the
slight changes in focal length. If you have no real idea what
the focal length is, or if the focal length is not set properly
in the image file, you may wish to increase this value to, say,
1, to indicate that the focal length may be off by 100%. Once
CHARON has successfully matched an image, it will show the
computed focal length, and you can set the correct value in
future images. Setting a wide tolerance does force CHARON to
consider more possible matches between stars in the image and
stars in the GSC; if possible, set the focal length accurately
and use a low scale tolerance.
Search distance: By default, CHARON examines stars within
.5 degree of the target position. If you think the target
position may be inaccurate, you may wish to increase this value.
If you expect the target position to be accurate, but know
that the field of view of your camera is greater than (or less
than) 1 degree, you may want to modify this value. Increasing
it means CHARON must consider more possible matches, so it can
slow the program down; decreasing it too far may cause it to
ignore stars that are actually valid.
Observer code: The MPC assigns 3-digit codes to observers.
Set yours, and CHARON will use that code in MPC and IOTA reports.
It will also use the latitude/longitude corresponding to that
observer code.
Time offset: If your imaging software assigns a consistently
biased time to images, you can use this value to "un-bias" the
time. I've also used it in cases where someone has used local
time instead of UT in their images!
Maximum residual: By default, CHARON considers that if a
star's position in the image matches a star in the GSC to within
one arcsecond, they must be the same star. This is almost
always a valid assumption, but I have seen one image, gathered
at very low altitude, where this value had to be raised to 3
arcseconds.
Video mode: By
mode. This option
The sole advantage
not all cards will
default, CHARON starts up in 320x200 (low-res)
cycles to 640x480, 800x600, and 1024x768 modes.
of 320x200 mode is that it _always_ works;
be happy with all of the high-res modes.
INITIAL SETUP FOR YOUR POSITION/MAKING MPC REPORTS
If you wish to correct for the effects of parallax, you'll
need to make sure that Guide has your correct latitude and
longitude set in its Settings menu. This normally is not
terribly important, of course, but it can cause large
positional errors for closer objects: up to a 20 arcsecond shift
for objects 1 AU away. Even a sub-arcsecond shift could cause
problems, so entering an accurate lat/lon or MPC observer code
is important.
If you're going to provide data to the Minor Planet Center
(MPC) or the International Occultation and Transit Association
(IOTA), you need to tell CHARON your MPC observer code. You do
this inside the settings menu (reached by hitting Enter, as
described above).
The next problem is actually getting the object position.
Generally, the best way to do this is to hit Tab. This causes
CHARON to center on the computed object position (as marked by
the red crosshairs); the target object should be close by, with
a red circle on it. Move the cursor near the target object, and
its RA/dec will be shown in red, with residuals (O-C, or
observed-computed coordinates) in arcseconds underneath.
Hit 'o', and CHARON will append the object position and other
data to the ASCII file MPC.LOG. Alternatively, you can hit 'i',
which will append the same data in IOTA format. You can then
send the data to the MPC or IOTA. (The formats are mostly
identical, but IOTA requires an extra digit of precision for
three data fields.) There are three small details that must be
mentioned:
(1) CHARON's object-finding system may not succeed in finding
the target object and marking it with a red circle. This is
particularly common in dealing with faint or extended objects.
In such a case, you must move the cursor over the object and
hit 'c' (for 'centroid'). Given this hint that "yes, there is
an object here", CHARON will find the object's position and add
a red circle there. You can then make an MPC report as before.
(2) The MPC report for comets will not contain the comet
designation. The COMET.DAT file on the CD-ROM doesn't contain
the new-style designations. I expect to fix this.
(3) The reported position in the MPC or IOTA report is _not_
adjusted for parallax, and shouldn't be. Both organizations
need "raw", measured positions for orbital computations.
USE OF FITS FILES
One reason using ST6 files is so simple is that their format
is very standardized. Most of the required data, such as time
of observation, pixel size, focal length, and so forth, is
contained in the header.
Unfortunately, no such standards exist for FITS. All of the
above data may be contained in a FITS image, but more likely, it
will not be. Also, FITS data comes in various "bit depths";
CHARON at present handles only the most common, 16-bit integer
data.
Some FITS images contain the image scale ("pixels in this image
are 1.207 arcseconds wide and .981 arcseconds high"). These are
set using the CDELT1 and CDELT2 tags (which give pixel size in
degrees) or the CRDELT1 and CRDELT2 tags (which give the size in
radians). If the image doesn't contain that data, you'll have
to enter the settings menu (either by hitting Enter while Charon
is running, or by just running Charon with no command line
arguments at all), and entering the focal length and pixel
size in the appropriate fields.
Some FITS images contain the date and time of the observation,
in the tags DATE-OBS and TIME-OBS. (In theory, _all_ 'standard'
FITS files will contain this data; in reality, one cannot
depend on it.) If the image lacks these tags, or if the tags
contain erroneous data, you can set the observation date with
-b(day/month/year hour:minute:second)
For example, if the previous example was imaged on 28 Aug 1995
at 3:14:16 UT, one would use
charon crzywd.fit -f40 -y9,9 -ongc7001 -b28/8/1995 3:14:16
This should allow one to handle all 16-bit integer images. But
I have not had a large number of images to test; if you run into
problems, please send me a sample image or two. I will probably
find that I've failed to handle some hitherto-unencountered field,
and can fix it readily.
THE FUTURE
Please let me know of any problems or points of interest you
find with this software! That's the main reason I'm sending you
this floppy. There are a few things that I know absolutely Must
Be Done before I can consider this software truly complete;
I'll list them so that you'll know that yes, they are being
considered:
Allow one to discard or add stars to the fit.
Allow one to reset the assumed background level.
Handle other formats:
.ST#, .TIF
Fix handling of new-style comet designations.
Better handling of stars near the edges of Schmidt-camera plates.
Possible use of PPM catalogue data when available, as well
as the 90,000-star PPM supplement. (More likely, use the Hipparcos
and Tycho data when they become available in June 1997.)
Possible (not likely) use of Luyten Two-Tenths proper motion
data, or of the Northern Proper Motion data.
Ability to blink-compare two (or more) images. One would say,
"Here are _two_ images of object XYZ (or near RA/dec X,Y);
correlate both to the GSC, then blink-compare them." This could
be extended to allow mosaicking of two (or more) images. If time
permits, I might also try adding some automated detection:
"This object appears to have moved slightly between images, or
appears in all three images in straight-line motion." I regard
this as a riskier process, of course.
Similarly, if one can blink-compare two images, one can
mosaic any number of images without much more effort.
Ability to show images in Guide, matched and registered to the
chart. This is not so major a hurdle as one might think. See the
updated Guide software on the Web page for examples as to how this
process works.
METHOD USED TO FIND STARS IN IMAGE
The current "usual" method for finding the position of a star
in an image uses a centroiding process. One defines a cell size,
usually around 5x5 or 7x7. After finding the brightest pixel in
the star, this cell, or "centroiding box", is centered on that
pixel. CHARON also has a centroiding box; you can currently set
its size in the settings menu.
With simple centroiding, one does a weighted average of pixel
values in the cell, such as:
~c
~c
~c
~c
~c
~c
~c
~c
~c
x_star = y_star = total_intensity = 0;~t
for( i=0; i<number_of_pixels_in_cell; i=i+1)~t
(~t
x_star = x_star + intensity[i] * x[i];~t
y_star = y_star + intensity[i] * y[i];~t
total_intensity=total_intensity+intensity[i];~t
)~t
x_star = x_star / total_intensity;~t
y_star = y_star / total_intensity;~t
This is the method that I used in CHARON for some time
before deciding to try a more complex system.
The above centroiding system works on the assumption that
the target star can be modelled as a Gaussian. That's not a
generally a bad assumption; the only change I make to it is
to assume that there is also a "background level", i.e., the
target star is a Gaussian plus a constant.
However, the simple centroiding scheme runs into problems
if some pixels are saturated or dead, or if the background
level is high compared to the intensity of the star, or if
the object is close to another object. All of those objections
can be met by simply rejecting such objects, since there are
usually an ample number of perfectly useful stars that can be
considered instead. My chief reason for abandoning the simple
scheme was that it doesn't deal well with comets.
I assume that the intensity at a pixel (x, y) is given by
~c
2
2~t
~cI(x,y) = I
+ I
exp( -dist /sigma )~t
~c
back
star~t
where
~c
2
2~t
~cdist = sqrt( (x-x_star) +(y-y_star) )~t
(This is the mathematical equivalent of the constant-plusGaussian assumption.) For a particular star, I have five
unknowns: the star coordinates x_star and y_star, the star's
intensity Istar, the background Iback, and the star's "size",
sigma. I do have approximate values for the position and
intensity, based on the simple centroiding, and if I start
with an assumed zero background and a "guessed" sigma, I can
do a least-squares fit to get accurate values for all five
unknowns.
The above process goes by the name of "point-spread function
fitting", or "PSF fitting". I've been happy with its ability
to deal with close pairs of stars, poor data, and in particular,
its ability to get good positions for comets, where Iback may
turn out to be unusually high. It can also extract valid positions
for objects containing saturated, dead and "hot" pixels; the major
problem here is simply identifying those pixels so the software
knows not to include them in the fit.
The 'centroid size' in the Settings menu allows you to determine
the area CHARON uses for the PSF fit. By default, it uses a 5x5
grid cell; in theory, a 7x7 or even a 9x9 would produce better
results. In practice, larger areas often result in including
parts of stars other than the one being measured.
ASTROMETRIC REDUCTION METHOD &
DETERMINATION OF PLATE CONSTANTS
I have used the most common method for astrometric reduction.
The first step is to find the positions of stars in the image
in pixel coordinates. I do this by assuming the star (or
satellite) forms a Gaussian peak in the image, and fitting a
Gaussian curve to each star. This provides me with the pixel
position (x, y) of the star, and an estimate of its magnitude,
as described in the previous chapter.
So in this manner, I have computed (x, y) pixel positions for
all stars in the image. Next, I need to match some stars in the
image to stars in a reference catalog, usually the Hubble Guide
Star Catalog. If I can match N stars, then I have
x(i), y(i) corresponds to RA(i) , declination(i),
i=1,2,....N
I start with an assumed plate center (RA0, declination0),
compute "pseudo-plate coordinates" (u, v) for each RA(i),
declination(i). Then I assume that
x(i) = A u(i) + B v(i) + C + x_residual(i)
y(i) = D u(i) + E v(i) + F + y_residual(i)
and
The six values A, B, C, D, E, and F (plate constants) are
determined with a least-squares fit, which minimizes
sum( x_residual(i) ^ 2 + y_residual(i) ^ 2),
('^' means 'raised to the power of',
i = 1,2,....N.
similar to the FORTRAN **.)
Therefore, at least 3 known stars are necessary for a fit to
be determined. But with only three, all residuals are always
zero, no matter how poor the fit really is; extra stars are
essential to ensure that errors are detected. Using the plate
constants, I can take the (x, y) pixel coordinates of an
unknown object, compute its (u, v) pseudo-plate coordinates,
and from these, compute its right ascension and declination.
This is a "first-order" or "linear" fit, and is one of three
kinds of fits that can be selected in the Settings menu.
If I know the size of a pixel in microns, I can also compute
the focal length from the plate constants. (CHARON displays the
focal length as computed from the pixel height and width; this
provides another check for errors. The focal length initially
provided in the image serves solely to enable CHARON to make its
initial match of image stars to GSC stars.)
If there are at least 7 stars,
quadratic fit:
I can consider the use of a
x = Au + Bv + C + Gu^2 + Hv^2 + Iuv + x_residual
y = Du + Ev + F + Ju^2 + Kv^2 + Luv + y_residual
This uses 12 plate constants instead of 6. Going further,
if there are at least 11 stars, I can consider the use of a
cubic fit, where terms in u^3, vu^2, uv^2, and v^3 are
included and we have 20 plate constants. I am not entirely
convinced yet of the usefulness of quadratic and cubic fits,
except in cases where the image covers a wide area of the sky
and distortions are pronounced. However, I do know that some
people will be using the software with wide-angle Schmidt
cameras, and for them, cubic fits will be a necessity.
All three types of fits are available in the Settings menu.
I suggest avoiding the use of higher-order fits unless you know
that either your optics or your large field of view are causing
non-linear distortions in the image. The reason I suggest using
the linear fit is that it can be difficult to tell if the higher
order fits are really "working" properly. They will _always_
result in some "improvement" to the residuals, which can fool
you into thinking you have better data than is actually the case.