Re: Bad pixel determination with better software

[Tom Droege <tdroege@veriomail.com>]

Rob and all,

One more thing.  To see what is going on, you need to take much narrower 
bins in the histogram below.  Compute the sigma of all the pixels, then 
make say 1/2 sigma bins.  OK this will be too many bins to look at on a 
plot.  So you should just plot it around the mean.  Look at the shape.  If 
the detector is cold, you will see a nice symmetrical shape.  If warm, you 
may see multiple bumps.  These are caused by pixels having integer numbers 
of defects which produce dark current.  If you are cold enough, most of 
these will go away.  If warm, the distribution will be skewed to the higher 
values of dark current.  There will always be a few pixels hit by cosmic 
rays.  These will produce a tail on the distribution to the high side.

To get rid of the cosmic rays, you can take a stack of darks all taken at 
the same temperature, and take the median.  5 or 7 will do a pretty good job.

Tom Droege

At 05:59 PM 12/7/00 -0700, you wrote:

>As some of you noticed, my previous histograms were incorrect.  Something
>about mixing the rows in the columns in CFITSIO routines...  Well anyhow,
>the question still stands, even though the data looks better (I also removed
>7 lead in/out pixels on each row/column).  Is there a "standard" way of
>determine the locations of bad pixels in the image?  Do you use the dark
>frame, fabricated flat field?  Or do you even not worry about the pixels
>being 'bad' unless they are at the extremes (0 or 65535) from a dark?  Will
>CCD's loose a single pixel, or row/column over time?
>
>% ./histo h3r1836.524 21
>     0 to  3120 =       0
>  3120 to  6241 =       0
>  6241 to  9362 = 4102506
>  9362 to 12483 =     123
>12483 to 15603 =       7
>15603 to 18724 =       6
>18724 to 21845 =       0
>21845 to 24966 =       2
>24966 to 28086 =       1
>28086 to 31207 =       1
>31207 to 34328 =       0
>34328 to 37449 =       0
>37449 to 40569 =       0
>40569 to 43690 =       2
>43690 to 46811 =       0
>46811 to 49932 =       0
>49932 to 53052 =       0
>53052 to 56173 =       0
>56173 to 59294 =       0
>59294 to 62415 =       0
>62415 to 65536 =       0
>
>% ./histo h4r1836.524 21
>     0 to  3120 =       0
>  3120 to  6241 =       0
>  6241 to  9362 = 4101496
>  9362 to 12483 =    1086
>12483 to 15603 =      63
>15603 to 18724 =       1
>18724 to 21845 =       0
>21845 to 24966 =       0
>24966 to 28086 =       0
>28086 to 31207 =       0
>31207 to 34328 =       0
>34328 to 37449 =       2
>37449 to 40569 =       0
>40569 to 43690 =       0
>43690 to 46811 =       0
>46811 to 49932 =       0
>49932 to 53052 =       0
>53052 to 56173 =       0
>56173 to 59294 =       0
>59294 to 62415 =       0
>62415 to 65536 =       0
>
>
>Robert S. Creager
>Senior Embedded Software Development Engineer
>Multi Platform Tape Library Development
>Ph:      303-673-2365
>Fax:    303-661-5379
>Pager: 888-912-4458
>StorageTek
>INFORMATION made POWERFUL