The bad-pixel flag value for an array component of an NDF may be obtained using the routine NDF_BAD. For instance:
LOGICAL BAD ... CALL NDF_BAD( INDF, 'Data', .FALSE., BAD, STATUS )
will return the logical bad-pixel flag for an NDF's data component via the BAD argument. This value might then be used to control the choice of algorithm for processing the data values. The selected algorithm must be prepared to handle bad pixels unless a .FALSE. value of BAD has been returned, in which case further checks for bad pixels can be omitted.
For example, a very simple algorithm to add 1 to each element of an integer array IA might be written to adapt to the absence or possible presence of bad pixels as follows:
INCLUDE 'PRM_PAR' INTEGER EL, IA( EL ), I LOGICAL BAD ... * There are definitely no bad pixels present. IF ( .NOT. BAD ) THEN DO 1 I = 1, EL IA( I ) = IA( I ) + 1 1 CONTINUE * There may be bad pixels, so check for them. ELSE DO 2 I = 1, EL IF ( IA( I ) .NE. VAL__BADI ) THEN IA( I ) = IA( I ) + 1 END IF 2 CONTINUE END IF
Note that this example is provided to illustrate the principle only, and does not imply that all applications should be capable of performing such processing. In fact, it is expected that many applications may choose not to support the processing of bad pixels at all, and this is considered in more detail in § and §.
Like other routines, NDF_BAD will also accept a list of array components, in which case it will return the logical ``OR'' of the bad-pixel flag values for each component. For instance:
CALL NDF_BAD( INDF, 'Data,Variance', .FALSE., BAD, STATUS )
would return a logical value indicating whether there may be bad pixels in either the data or variance component of an NDF.
Finally, note that the quality component of an NDF also has a
bad-pixel flag, but that its value is currently always .FALSE..
This behaviour may change in future.