In the above examples, the third (CHECK) argument to NDF_BAD was set to
.FALSE., indicating that no additional checks for bad pixels were to
be performed.
In this case, the normal interpretation of the returned bad-pixel flag
value (as described in §) applies.
However, if this CHECK argument is set to .TRUE., then NDF_BAD will perform
any additional checks necessary to determine whether bad pixels are
actually present, for instance:
CALL NDF_BAD( INDF, 'Data', .TRUE., BAD, STATUS )
This may involve explicitly examining every pixel, which could take a significant time to perform, although this will not always be necessary. If explicit checking is requested in this manner, the meaning of a .FALSE. bad-pixel flag value is unchanged, but the interpretation of a .TRUE. value changes to become:
.TRUE.
There is definitely at least one
bad pixel present
Requesting an explicit check in this way can therefore convert an otherwise .TRUE. value for the bad-pixel flag into a .FALSE. value, but the opposite effect cannot occur.
The main value if this feature arises whenever there is a substantial cost involved in dealing with bad pixels within a processing algorithm. For instance, a considerably less efficient algorithm may be required to take account of bad pixels, or a suitable algorithm may not even exist (such as in a Fourier transform application). In this case, the extra cost of explicitly checking whether bad pixels are actually present will probably be worthwhile. In the following example, an application which cannot handle bad pixels checks whether there are any present, and aborts with an appropriate error message if there are:
INCLUDE 'SAE_PAR'
CALL NDF_BEGIN
...
CALL NDF_BAD( INDF, 'Data,Variance', .TRUE., BAD, STATUS )
IF ( BAD .AND. ( STATUS .EQ. SAI__OK ) ) THEN
STATUS = SAI__ERROR
CALL NDF_MSG( 'DATASTRUCT', INDF )
CALL ERR_REP( 'FFT_NOBAD',
: 'The NDF structure ^DATASTRUCT contains bad pixels which this ' //
: 'application cannot handle.', STATUS )
GO TO 99
END IF
...
99 CONTINUE
CALL NDF_END( STATUS )
END
Here, the cost of an explicit check is justified, because the cost of not
performing the check (i.e. of the application having to abort) is even
greater.
Note that if the bad-pixel flag is .FALSE., then NDF_BAD will not
need to check all the pixel values, so this approach does not hinder the
normal case where bad pixels are flagged as absent.
A simpler method of performing the same check is given in §.