Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://xmm.vilspa.esa.es/sas/5.4.1/doc/badpix/node9.html
Дата изменения: Fri Jan 10 22:26:30 2003
Дата индексирования: Sat Dec 22 07:37:23 2007
Кодировка:
The task was originally designed to handle RGS data also. The
BADPIX extension here contains the CHIPX/CHIPY chip-orientated
co-ordinates of the bad pixels. Though this functionality still exists, it is
recommended to use the task rgsbadpix.
The task checks for duplicity between any badpixfind
input and bad pixels contained within the CAL.
Irrespective of whether CCF bad pixels are required to be input into the
BADPIX extension or not, the task gives general information as to
CCF/badpixfind
double entries. If entries from the CCF and from
badpixfind
covering the same coordinates are required to be input
into the BADPIX extension, then the badpixfind
entries are
split and purged such that no RAWX/RAWY coordinate has more than one entry
(i.e. the CCF entries take precedent). Also the task checks whether the
badpixfind
entries themselves have any overlapping pixels. If so, the
badpixfind
data are purged, precedent being given to hot pixels over
dead pixels (over flickering pixels).
The task, via the parameter emptyextension=Y,
produces an empty BADPIX extension. Also, via the
parameter windowfilter=Y, the task filters the bad pixels for
those within the input file WINDOW range (entries are adjusted if they lie
across the WINDOW border). The default values for both parameters are `N'.
Information from the hardware groups is required regarding
how the bad pixels will be handled on board in timing and burst mode.
The badpix
task at the ground could, for example, use the same badpix
sets (1 and 2), as for the imaging modes, and add them as an extension to
the raw event file. Event flagging then has to be dealt with in the
events tasks.
