The need to handle bad pixels inevitably adds to the amount of programming required when writing an application and can also adversely affect the execution time (although usually not as badly as might be feared). Nevertheless, most programmers recognise the need to handle bad pixels as an unfortunate fact of life that often has to be catered for.
When possible, however, it can be useful to determine whether or not bad pixels are actually present in an array, so that a more streamlined algorithm can be used if there is no need to check each pixel explicitly for a bad value. Indeed, in some cases, an algorithm may depend upon the absence of bad pixels, so a method of checking for this condition is required. Each array component of an NDF therefore has a logical value associated with it called its bad pixel flag, which is intended to indicate whether or not bad pixels may be present in that component.
Unfortunately, certainty in this matter comes at a price, because there are many operations (including those performed by the NDF_ system) which might introduce bad pixels into an array component, but there is no way of being completely sure without performing additional checks. In many cases this will involve examining every array element, and the time taken to do this may mean that the test is hardly worth performing if the resulting knowledge only results in a small saving of execution time in the main algorithm.
The NDF_ system takes a pragmatic approach to this problem, by allowing a slightly ``fuzzy'' interpretation of the bad-pixel flag's value, but providing the option to make it more precise (at additional cost) if required. The normal interpretation of the bad-pixel flag's value is therefore as follows:
|.FALSE.||There are definitely no bad pixels present|
|.TRUE.||There may be bad pixels present|
(See § for how this may be changed.)
The NDF_ system goes to some lengths to keep track of bad pixels, but if
any doubt exists it will cautiously set the bad-pixel flag to .TRUE..
Thus, a .FALSE. bad-pixel flag value expresses a definite fact, while
a .TRUE. value only ``suggests'' the presence of bad