Re: weak pixels, etc.

[<aah@nofs.navy.mil>]

I have been busy (as usual!) on other projects, one of which
is the arrival next week of our Scientific Director.  So I have
not been following the discussion of 'weak pixels' very closely.
However, I am kinda surprised at this discussion.  Andrew's technical
note shows two variables out of ~200K that transit 'weak' pixels;
that seems like a low hit rate to be worried about.  But what
bothers me more is just the concept of a weak pixel.
  Flatfielding is supposed to correct for pixel-pixel QE variations.
I might understand a dead pixel, which then cannot be flatfielded
(this might be either a real dead pixel, or one underneath a
dust speck directly on the surface of the CCD), but any other pixel
should be corrected by the flat.  The exceptions would be:  an incorrect
flatfield, where there is a 'bright' pixel in the flat that then undercorrects
the raw image; or an improper dark frame where a hot pixel is improperly
subtracted.
  Note that in both of Andrew's cases in the technical note, the magnitude
dropped by ~2mags, which is a decrease of about 90percent.  This sounds like
a dead pixel to me, not a weak one.  There should not be many dead pixels
on a CCD, even engineering grade. They can all be marked and just avoided.
Since you will have many datapoints for every star, you just throw out
any star image that touches a bad pixel; then there is no contamination
of either astrometry or photometry.
  Likewise, for cosmic rays, you just look at the image shape parameters like
roundness and sharpness.  If surrounding stars have different shape, then
you know you have a problem with this particular one and you flag it.
I did many of these statistical cuts when generating the FASTT variable
star list.  It is not hard!
  These are reasons why I continue to push for more information in the
database than just time, position and magnitude.
  I also still think that the Mark III method of 'seeding' a catalog is
the proper way to go here.  Use the UCAC catalog as your source of good
objects, then just match the known catalog when importing a new list.
The error that occurred in the Mark III database is that the seed catalog
was just used as an initial guess and the imported starlists overwrote
the position.  You should use UCAC as the absolute truth and leave its
positions alone.  When importing, you can do things like checking the
percentage of UCAC matches for a given import list; if not high enough,
then there is likely an error in the import list astrometry.
Arne