[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
troubles with matching
Tom and Rich write:
> Rich Knowles and I are struggling with a pair of images. The V image finds
> .ast files perfectly. The I images will find only one or two, and juggling
> values in make_list.out might make one image convert and another disappear
> from the .ast list. We only get one or two successful out of 56 with all
> 56 V images successful. I had this problem on DS20 7 and 8 and was able to
> fix it by modifying make_list.out.
[brief digression: DS 20 disks 7,8 have RA = 71.2, Dec = 7.4]
> OK, the thing special about this list is that it is taken at the equator
> and is thus dense.
> ...
> What values do we fuss with to try to get .ast files? Can you give us the
> values to change and some logic behind them? Possibly we can talk Rich
> into working on any code that is necessary to help make the process run
> smoother. How close do we have to be to get a match?
This is a complicated problem. There is no easy answer.
The problem is (probably) that there are a LOT of candidate stars
detected in the image. The reference catalog file is based on the
Tycho-2 catalog, which contains stars with magnitudes mostly V=8 to V=10.
The density of stars isn't very large: there are about 353,000 stars,
so, if they were spread evenly across the whole sky, there would be
only about 8 per square degree. Since the Mark IV field covers about 16
square degrees, one expects around 100-200 catalog stars per Mark IV field.
So, there are thousands of stars detected in the image, and only one or
two hundred catalog stars. How can we match them up? The pipeline
is designed to
- pick out the brightest 300 (by default) stars from the image
- pick out the brightest 200 (by default) stars from the catalog
- run the "match" program on these two subsets
If there are SO MANY stars in an image that the brightest 300 stars
in the I-band, say, are largely brighter than the stars in the
reference catalog, then there might only be 20 or 30 true matches
between the two subsets. The "match" program is likely to fail
if the number of false matches is much larger than the number of
true ones.
There are several parameters which one can set in the "match" program
which may help it work in these fields. You can read about them
in the "match" manual
http://spiff.rit.edu/match/match-0.5/match.html
The ones most likely to help are
- trirad (try making it smaller than the default)
- scale
It would take me too much time to explain exactly how these are
calculated and used. You might try reading the manuals, and then
the code in "astrom.tcl". But you could try fiddling with these
slightly to see if some particular combination helps the code
to discard false matches and keep only the good ones.
Brave people may edit the "atpmatch.c" file in the "match" directory
and change the #undef DEBUG to #define DEBUG, then recompile.
The program will print a LOT of diagnostic messages to stdout as
it runs. It will confuse the pipeline (which doesn't expect to see
all the extra messages), but allow a human to figure out why the
stars aren't matching properly.
It may help if I modify the pipeline so that instead of
using the brightest N stars from the reference catalog, it instead uses
a set of N stars which lie between two particular magnitude
limits. Unfortunately, we can't constrain the detected stars to
lie within a particular magnitude limit, because we don't (yet)
know the zero-point offset between the instrumental magnitudes
and calibrated magnitudes when we start the matching process :-(
Michael