cspratt@islandnet.com Apr 25, 2001
--- In guide-user@y..., "Bill J. Gray" <pluto@p...> wrote:
> Re the Charon speed issues: there are a whole slew of parameters
that
> can cause speed troubles.
>
> First, as Bob mentioned, is the search distance. This should
be large
> enough to cover the CCD, but not much more than that.
>
> Also, check your scale tolerance. When you're setting up
Charon, you
> often have only a vague idea as to your true focal length
(especially with
> an SCT) and will set, say, a 50% scale tolerance. Once you've got
things
> up and running and Charon has measured your focal length, you can
enter that
> value and cut the tolerance down to, say, 1% (just enough to allow
for the
> fact that the focal length does vary a bit over time).
>
> Dropping the magnitude limit can help. It may also help evade
the fact
> that the fainter stars in most catalogs are also the least precisely
measured.
>
> You may also be able to drop your "Number stars used" parameter.
When
> this is set to, say, 7, it means that Charon will attempt to do
its
> initial pattern matching using the seven brightest stars found in
the image.
> If even two of them happen to correspond to actual catalog stars
(maybe
> one of the remainder is a target asteroid, two are artifacts, and
two
> are stars inexplicably missing from the star catalog), Charon will
still
> often be able to figure out the pattern match and will get correct
results.
> Dropping this parameter _really_ speeds up the program.
>
> Also: if your image is aligned north/south, try setting the
"Max tilt
> angle". If you expect the image to be offset from north/south by at
most,
> say, ten degrees, you'd set this parameter to be ten. By doing
so, you
> confine the orientation to a 20-degree range out of the full 360,
and
> therefore, Charon can instantly ignore 17 of 18 possible pattern
matches.
> Again, things speed up.
>
> And if worst come to worst, my standard offer: send me an
example image
> and the CHARON.DAT file you're using, and I'll see what I can find.
>
> Re "real-time" display: the version currently on the Web site
asks you
> to set the update frequency for real-time animation. You can set
this to
> a very long time frame if you wish, because the date/time will
still be
> updated every time you force a redraw (pan, zoom, go to object,
etc.)
> In that case, the need Pat Madden cited for lots of computing power
goes
> away. For more comments, see
>
> http://www.projectpluto.com/update7b.htm#realtime_freq
>
> -- Bill