RE: Focus indication

["Creager, Robert S" <CreagRS@LOUISVILLE.STORTEK.COM>]

Well, I've addressed some of your concerns.  The nominal location will be a
central 200x200 square, I'm only using sources which are non saturated, and
the outliers will be eliminated by using 1/2 of sorted lists.

Now, understand that I'm playing fast and loose with the 'rules' of image
processing, by doing the spirit of the steps, not necessarily the law.  So
I've got a couple hundred lines of code and 1 weekend put into this, so not
too much lost yet :-).  Of course, when I get the FWHM spit out, it may show
just how many shortcuts I took.  For instance, I've no checks for blended
stars or streaks (artificial, CCD or other).  What I'm hoping is that by
removing 'outliers' at various steps along the way, the final values of the
few stars left will give a reasonable idea of what's going on.

One problem I have is that most of the images I have are 'good' images.
Anyone have a stash of out-of-focus, dew'ed lenses, cloud cover, etc... from
1 camera (basic fits headers)?

This is a quote from a message Tom sent me recently as what he would like
from this program:

Let me tell you the problem for the focus program.  It needs to tell you 
what the conditions really are.  Things fog up, people bump the camera, the 
RA drive runs into a hose and hangs up, clouds come over, etc..   So the 
stars change from nice focus to blubs and streaks and who knows what 
else.  A thin fog and they just swell up.  Possibly this is something that 
you will not be able to do well until you have a camera.  But now you 
should be able to detect a "good" focus.  Later the same program will want 
to develop intelligence that says things like "turn on the lens anti-fog 
heater".  Even do such things automatically.


> -----Original Message-----
> From: aah@nofs.navy.mil [mailto:aah@nofs.navy.mil]
> Sent: Thursday, August 02, 2001 12:52 PM
> To: tass@listserv.wwa.com
> Subject: RE: Focus indication
> 
> 
> Rob wrote:
> >Anyone have thoughts on how to determine when the "background tail is
> >wagging the star-dog" for Michael's method?  Since I'm not 
> going to present
> >information on an individual star basis, but rather a mean 
> of a subset of
> >behaved data, this might not be an issue.
>   As I suggested to Tom, an automatic determination of fwhm 
> for a frame
> is not a trivial matter.  Mike mentioned the variation of the 
> psf across
> the field.  Many of the frames have thousands of stars; you have to
> somehow select which subset you want to use for your 'behaved' data.
> Because of the many stars, the background is *not* well behaved, and
> an accurate determination of the sky level is not easy.  You have to
> avoid saturated stars and also stars with low signal/noise.  You have
> to avoid dots on airplane and satellite trails, CCD cosmetics, etc.
> You have to avoid stars that are blended.
>   For our non-automated system at the 1.0m, we hand-pick a single star
> in a frame for which to acquire statistics at the end of an exposure.
> That fwhm is reported in the computer-generated log file.  For my
> pipeline, I determine fwhm for all stars, then start paring based on
> the points mentioned above, and finally determine the modal value for
> the remaining stars and report that value in the extracted 
> starlist header.
>   If Tom really wants an automated fwhm report that he can trust, then
> you have to do a fair amount of coding.  Pick only the central part of
> the image to avoid the coma problems.  Then you have to somehow find
> all stars within that window.  Reject all stars with peak DN
> above the saturation level.  Reject all stars with peak DN less than
> some threshold.  Check to see if any stars remain!  Then find fwhmx,y
> for the remaining stars.  Find median fwhmx,y.  Reject stars that are
> obvious outliers (probably blends).  Find median fwhmx,y of 
> the remainder.
> Once you have done all of these steps, you are almost at the 
> full pipeline level.
>   If this goes into a log somewhere, then the reader will 
> have to hand-check
> files with deviant fwhm to see if it is truly deviant or whether the
> automated code had problems.  While the determination of fwhm is
> useful at the beginning of a night to ensure everything is working
> correctly, I fail to see the value for such a feature for the rest of
> the automated night.  The data will be fed into a pipeline shortly
> thereafter and accurate values obtained; a night with problems will be
> indentified at that step.  Perhaps I am not understanding the problem
> and someone can give me some reasons.
> Arne
>