badpixfind searches for pixels identified as containing no useful data, and uses this information to produce an output file. This output file can then be used by the task badpix to append the information to the events file. A bad pixel map (or mask) can also be produced.
An important point regarding the bad pixels is that there are essentially three separate (though not exclusive) sets of bad pixels that must be dealt with. These are (1) the bad pixels uplinked to the satellite and eliminated on-board, (2) the bad pixels identified in the Current Calibration File (CCF) but not uplinked, and (3) the bad pixels associated with the particular observation in question. badpixfind searches for this third set of bad pixels, which may of course, contain within it part (or all) of the other two sets.
There are two modes to badpixfind. Mode 1 involves all the searching and statistical techniques and makes up the bulk of the task. Within mode 1 (searchbadpix='Y', [=default]), the user can search for...
1 Hot and dead pixels. The user is able to specify maximum and minimum allowed values (via the parameters lothresh and hithresh) to screen for hot and dead pixels. These threshold levels can be input (via the parameter thresholdlabel) in terms of number of counts, count rate, or percentages of the peak value in the dataset. In cases of supposed hot pixels, the pixel in question and its neighbours are compared with the local PSF to check whether the pixel is genuinely 'hot' or may be due to a source [see comments]. Here the user can set the cellsize of the box around the hot pixel to be compared with the PSF (total box width = twice cellsize +1). Here, known uplinked bad pixels and previously found bad pixels are removed from the PSF comparison. The user can also set the parameter narrowerthanpsf. This is a measure of how much more compact the pixel and its neighbours are when compared with the PSF (1 means of similar width, greater than 1 means that feature is narrower than the PSF, and hence likely a bad pixel [if narrowerthanpsf is set to zero, the PSF comparison is removed and all hot features, whether sources, bad pixels or whatever, can be found]). Essentially, narrowerthanpsf is the ratio A/B, where A is the ratio of the target (bad) pixel to the total (twice cellsize +1 by twice cellsize +1) square, and B is the equivalent for the PSF. The user may also set a backgroundrate (ct/s/pix) here. A negative value indicates that the mean value over the whole field is to be calculated and used. In cases where very bright, extended sources exist (and thus the mean is not too representative of the true background mean), a typical backgroundrate value should be given (see comments).
2 Hot and dead whole columns (channels) (withsearchbadcolumn='Y'). Here a column may appear bad because of a small number of individual pixels that are bad (these perhaps, depending on the threshold levels, being detected by the previously described part of the task), or it may be bad because the entire column as a whole appears bad. Via the parameter columnsearchlabel, one can specify whether the minimum and maximum column threshold values (locolthresh & hicolthresh) refer to the total counts/count rate of the column or to the median value within each column. The median choice is more sensitive to finding bad whole columns with no particularly bad pixels within them. Again, the threshold levels can be input (via the parameter thresholdlabel) in terms of number of counts, count rate, or percentages of the peak value in the dataset.
3 Flickering pixels. The parameter flickertimesteps sets the number of `timesteps' into which the dataset can be split (if flickertimesteps is set to 1, no attempt is made to seach for flickering pixels). Here, each pixel is searched for significant variations. In the case of low count pixels, the distribution of counts per timestep is compared with a Poisson distribution, and a Kolmogorov-Smirnov (KS) test is applied. Pixels with a KS-statistic above the input threshold flickerksthresh are deemed flickering. In the high count pixel case, a chi-squared statistic about the mean counts per timestep is calculated. Pixels with a reduced chi-squared statistic above the input threshold flickerchisqthresh are deemed flickering. [see comments]
The whole of mode 1 above can be performed between user-defined energy bands, via the parameters loenergythresh and hienergythresh (in keV). Also, the high threshold values hithresh and hicolthresh can (in the thresholdlabel = COUNTS or RATE cases) refer to either a total count or countrate value or to a count or countrate value above the (either set or calculated) background (backgroundrate). This choice is set via the parameter threshabovebackground.
Within mode 2 of badpixfind, the user can explicitly flag invalid pixels or sets of pixels via the list parameters rawxlist, rawylist, typelist and yextentlist.
After searching for pixels which may contain double (or more) entries, and warning the user thereof, a final output file is constructed, containing for each bad pixel (or, to be precise, for each set (in RAWY-extension) of bad pixels), the position RAWX/RAWY, any extent in the Y direction, and the type of fault; 1 Hot, 2 Flickering, 3 Dead. Statistics as to the input file values are provided also by the task, before and after the individual sections of the task.
A badpixfind map may be produced via the parameter withbadpixmap. Here an image is formed whereby bad pixels (and if desired, surrounding neighbours [chosen via the parameter mappixcellsize]) are assigned a value of zero, good pixels a value of one. This map includes the pixels found by the current badpixfind run, and the XMM-uplinked bad pixels contained within the CCF. Furthermore, regions outside the field of view (FOV) can be set to zero in the map via the parameter withfovmask. This map can be used in evselect to select images, spectra or time series with these pixels ignored (e.g. to produce a background [source and bad pixel/column-removed] lightcurve).
