Re: weak pixels, etc.

[Andrew Bennett <andrew.bennett@ns.sympatico.ca>]

On Thu, 7 Feb 2002 09:29:35 -0700, <aah@nofs.navy.mil> wrote:

>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. 

That's 2 out of 13 looked at ... I've just found another
one while developing code to flag them properly so that's
3 out of something under 3000 of which I have looked
at around 20 properly.

> But what
>bothers me more is just the concept of a weak pixel.

Right.

>  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.

Not in this case! The defect is hard to see on both the Darks
and the Flats but is much more obvious (i.e. I found it when I
knew exactly where to look) on an actual image. It looks as though
electrons smear out over the full affected length of the column
(or is that row? It's vertical on my plot: AXIS2 direction)

>  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.

Yes. Definitely the way to do it. But automatic detection of this
kind of defect is not a nice problem. The Pipeline is going to have
to have a human slave with better eyesight than mine built in ... as
somebody else posted "Does nobody ever actually LOOK at the images?"
(or words to that effect.)

>  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.

Absolutely essential!

>  I also still think that the Mark III method of 'seeding' a catalog is
>the proper way to go here.  Use the UCAC catalog

Where does one get this?

> 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.

Yes. I am using Tycho2 but this doesn't get me deep
enough so I have to add a lot of "found" stars with all
the problems they bring.

>Arne

Andrew Bennett, Avondale Vineyard