Author: Michael Richmond Date: 960223 Revision: #0 960223 Key Words: CCD, astrometry, observation, stars
This note contains my conclusions after looking at a set of 3 images of the same region of the sky, the Orion region, taken during early February, 1996, with the TASS Mark III camera. There are some pictures and graphs in the document, so you may want to turn off automatic image loading.
You may notice that this Note is a very close copy of Technical Note 9. The difference is that the images considered here were taken with an I-band filter in the camera, whereas those described in Technical Note 9. were taken with a V-band filter. I certainly did copy the HTML liberally in creating this document.
Here are some basic properties of the three images I considered. Each field is centered around the stars of Orion's belt, near RA = 5h37m, Dec = -0.5, and is roughly 3x3 degrees in size. These I-band images are offset about 1 degree north of those taken in the V-band.
image date filter weather moon properties -------------------------------------------------------------------------- orion9 Feb 3 I clear full-1 day, up, +52 degrees orion10 Feb 5 I clear full+1 day, up, +30 degrees orion11 Feb 8 I clear full+4 day, downI find the images very nice, considering how bright the moon-lit sky must have been.
I looked at the values of pixels in rows 0-6, several of which are covered by metal and so ought to be good measurements of the dark value. I measured the mean inside each column, excluding the first and last 10 rows.
column
0 1 2 3 4 5 6 stdev
-------------------------------------------------------------------------
orion9 -17457 -27476 -28515 -27646 -24335 -23641 -23545 36
orion10 -21405 -27998 -28682 -28160 -26146 -25728 -25669 14
orion11 -23571 -28276 =28769 -28446 -27165 -26905 -26869 13
As was the case with the V-band images,
column 2 is the lowest column, consistently.
I therefore chose to use the mean of column 2 as the dark
value, subtracting a constant value from all image pixels.
I list the standard deviation of the pixels in column 2 in the
stdev column in the table above.
I noticed that most images had an obvious pattern which ran parallel to the scan direction (along columns). I assumed that this was due to a change in sensitivity across the chip, and that it was multiplicative in nature. I created a flatfield vector for each image by finding the median value of each column. Thus, from an image with (800_rows_x_768_columns), I would create a (1_row_x_768_column) vector.
After I'd made them all, I compared them as a group. As expected, most of them showed a consistent pattern. In the plot below, I've normalized all vectors to have a mean value of 10,000, then offset them by 1,000 units in the vertical direction for clarity.
You can see that the three I-band vectors, for orion9, orion10 and orion11, are similar. Each has variations of only about 1.5 percent from peak-to-peak. The V-band images, on the other hand, typically had a much stronger variation; as the graph shows, the V-band image orion3 had a roughly 8% peak-to-peak variation across the chip.
The sharp peaks in orion10 and orion11 near columns 554 and 747 are due to very bright, saturated stars (around mag 3).
I subtracted a constant dark value from the pixels in each image. Next, I formed a flatfield vector, as described above, and divided each row of the image by a normalized version of it. I used these clean images for all further processing.
Here's a clean image of the frame orion11 for reference. In this image, North is up, East to the left, just as on star charts. You can click on the image to get a full-size version.
The three bright stars in Orion's belt, from southeast (lower left) to northwest (upper right) are Xi, Eta and Delta Orionis, respectively. The horsehead nebula isn't inside the field of view -- it would be, roughly, straight below Xi Orionis.
When I tried to determine a sky value, I had problems. The trouble was that in several frames, the sky brightness changed signficantly over the exposure time, so that a single sky value could not be determined. If the sky brightness didn't change, as in the image orion11, then a histogram of pixel values looked like this:
This nice, gaussian-like shape is what one expects in astronomical images. However, orion9 had a histogram skewed noticeably to higher pixel counts, and orion10 had two clear peaks in its histogram. These variations are almost certainly due to changes in the cloud cover over Tom's backyard.
For each of the I-band images, I estimated the sky value and the width of a fitted gaussian.
image sky sky sigma comments --------------------------------------------------- orion9 4980 83 skewed to higher pixel counts orion10 2930 154 double peak, not gaussian orion11 1842 23 nicely gaussian
Looking closely the histogram above, you may note the single, very high bin at 1842 counts. Now, the image does have quite a strong periodicity in its pixel counts, as a closeup of the histogram shows:
I don't understand why there is a single very high, and a single very low, bin of pixel counts; and why those aberrant bins always fall close to the peak of the histogram. Perhaps my image-processing software has a bug in it. The raw image shows a very regular pattern of counts in bins: low, medium, medium, high, low, medium, medium, high and so forth; but the raw images do not show this single, very high bin.
I examined the shape of stars in each frame, using a azimuthally-averaged profile to fit a 1-D gaussian to each star. I only looked a couple of stars on each frame, and didn't check for variation in the shape across the image. Here are my results -- the ellipticities and position angles are very rough estimates.
image FWHM ellip PA -------------------------------- orion9 3.5 pix 0.12 35 deg orion10 3.8 0.20 50 orion10 3.9 0.20 55
The position angles are measured relative to North/South. Thus, if a star is elongated in the scan direction, East/West, it would have PA = 90 degrees.
Overall, the PSFs are not as elongated as those in the earlier V-band images. That's good.
I didn't bother to measure the gain from these images; I just assumed that it still ahd the value k=5.4 which Tom describes in Technical Note 8.
From this point on, I discuss the image orion11 only; it was by far the cleanest of the 3 I-band images. I used a relatively simple method to find stars, one which
I hope someday to make the program, part of the XVista package that Dick Treffers and I have written, freely available.
I ran the program with various trial values for threshold, sharpness, roundness, etc. A sample run, with values
In order to find more stars, I varied my method to include convolving the image with a lowered gaussian filter, roughly the same size as the stars themselves, and THEN looking for candidates. As Peter Stetson describes in his big paper on DAOPHOT (PASP 99, 191, 1987), this method smooths over cosmic-ray hits and extended objects, emphasizing objects that are just the same size as the filter. Using rather liberal limits
Given a list of stellar positions, I ran another program to measure the amount of light inside circular apertures. The program used an annulus around each object to estimate a "local sky" value for it; the annulus had inner and outer radii of 15 and 25 pixels, respectively.
I used circular apertures of radii 3 and 6 pixels to calculate instrumental magnitudes. The figures below refer to the 3-pixel-radius magnitudes, unless otherwise noted.
I tried to match up the list of stars produced from orion11 against a list of stars from the Hubble Guide Star Catalog. Now, the TASS image was taken through an I-band filter, and GSC was made from plates taken through a V-band filter, so this is a little fishy ... but it was the best I could find. Certainly there ought to be a great deal of stars in common, including all the brighter ones (V <= 12, say).
I used a set of programs based on the algorithms described in a paper called "The Focas Automatic Catalog Matching Algorithms", by Valdes et al., published in PASP 107, 1119 (1995). When I wrote the code, I tried to avoid constructions that would prevent it from being ported simply to other environments. It possible that some of this code might become part of XVista (someday...).
My programs produced several results of interest. First, in order to cause the coordinates of objects from two images to match, one must (almost always) transform one set in some fashion. I assumed that the transformation could be written
x' = A + Bx + Cy y' = D + Ex + Fywhere (x,y) is the position of a star in one image, (x',y') is the position of the same star in another image, and A,B,C,D,E,F are all variables to be calculated by a matching program, Note that for a pair of images which have identical scales, but are simply shifted by 3 pixels in x and -5 pixels in y, we should find A=3, B=1, C=0, D=-5, E=0, F=1.
It is interesting to see how closely matched pairs of objects agree in their positions, and in their magnitudes. Finally, it's sometimes useful to consider the objects which didn't have any match in the other image.
Actually, for the tests described here, I used a slightly modified version of the very first edition of the GSC. Newer editions have fixed errors and included additional stars. In addition, I shrank the GSC drastically to make it fit onto a small disk, in the following way: I discarded all information except position and magnitude, and I slightly degraded the positions and magnitudes by binning them at roughly 1-arcsec and 0.1 mag intervals. Therefore, it's quite possible that people using more recent editions of the full GSC might reach slightly different conclusions than I did.
One further note on the "GSC" values: to ease comparison of star lists with entries from the GSC, I converted the positions of stars to positions relative to the plate center, in the following way. I choose a position near RA=5h37m50s, Dec=-00:30:00, and grabbed stars within a 3.1x3.1-degree box around it. There were a total of 3886 stars in the resulting catalog. Given the central position (ra0, dec0) for the field, I assigned to each star an "x" and "y" offset, where
x = (star_s.ra - ra0)*cos(star_s.dec*DEGTORAD)*3600.0;
y = (star_s.dec - dec0)*3600.0;
Thus, I squashed the spherical coordinates from the GSC
onto a plane, in a simple-minded manner.
Aside: I recently came across a description of the proper
way to project spherical coordinates onto a plane -- you
can find it in any book on "Spherical Astronomy". To convert
some positions from (RA, Dec) to planar coordinates (x, y),
using a projection around the point (ra0, dec0),
one should write:
cos(dec0)*sin(ra - ra0)
x = -----------------------------------------------------
sin(dec0)*sin(dec) + cos(dec0)*cos(dec)*cos(ra - ra0)
cos(dec0)*sin(dec) - sin(dec0)*cos(dec)*cos(ra - ra0)
y = -----------------------------------------------------
sin(dec0)*sin(dec) + cos(dec0)*cos(dec)*cos(ra - ra0)
I did perform this more complicated computation, and used it to match
against the stellar positions in orion11. However, I found
no significant difference in the residuals.
Here's what I found after matching the GSC against orion11:
GSC: 3886 star
orion3: 1407 stars
transform GSC -> orion11:
A = 396.1 B = 0.0719 C = 0.0004
D = 367.5 E = -0.0001 F = -0.0725
1242 matches
delta x = 0.02 +/- 0.70 pix (East-West)
delta y = 0.25 +/- 0.68 pix (North-South)
delta mag = -3.6 +/- 1.0 mag
Here is a plot of the differences in x (in the sense GSC - orion11):
Here is a plot of the differences in y (in the sense GSC - orion11):
Here is a plot of the differences in mag (in the sense GSC - orion11). Remember that the GSC has V-band magnitudes, and the TASS image has I-band.
And here, finally, is a plot of the difference in mag vs. the GSC V-band magnitude.
So, what do we learn? The coordinate systems are not rotated (much) relative to each other, as one would expect. The plate scale of Mark III images is given by the coefficients B and F in the transformation:
1 pixel = 13.90 arcsec (East-West)
1 pixel = 13.80 arcsec (North-South)
These are roughly the same scale factors found
in the V-band images, but the I-band EW factor
is larger than the NS, whereas the V-band EW
factor is smaller. I suspect that this may just be
due to uncertainties in the factors.
The scatter is positions is also roughly the same as found for the GSC vs. V-band TASS images.
The tests above, in which I matched my hacked version of the GSC against orion11, yielded a set of matched GSC stars with the following magnitude distribution:
GSC V mag 6 7 8 9 10 11 12 13 14 15
--------------------------------------------------------------------
#stars detected 9 19 31 40 104 191 270 319 240 19
#stars in GSC 14 25 39 47 120 265 481 923 1859 113
percentage found 64 76 79 85 87 72 56 35 13 17
One way to define limiting magnitude
is as the magnitude at which only 50% of objects
are detected. The numbers above show that
this point occurs at around GSC mag V~12.5.
This is comparable to the results of V-band TASS data.
As before, it may be due more to the ability of my
software to find objects than to the properties of
the image itself.
For those who might find it useful, I offer here a copy of my hacked-up version of the first edition of the Guide Star Catalog. It contains (a subset of?) the stars roughly within the area of the orion11 image. All magnitudes have been rounded to 0.1, and all positions rounded to 0.1 seconds or 1.0 arcseconds. The final two columns provide my calculated offset from the center of the field, in arcseconds.
Beware -- it's large: 3886 lines and 252,590 bytes.
Click here to download the ASCII catalog for the orion11 area.
Note that this is NOT the same catalog as that used to match the V-band orion3 image; this catalog is shifted slightly to the north, and is slightly larger.