An NDF's shape is determined by its dimensionality (i.e. its number of dimensions) and the lower and upper bound of each dimension. In this respect, an NDF is exactly like a Fortran 77 array. It may have between 1 and 7 dimensions, each indexed by an integer lying between the lower and upper pixel-index bounds of that dimension. These bounds may take any integer values, so long as the lower bound does not exceed the upper bound. Each element of the array is termed a pixel.
All the array components of an NDF (i.e. its data, variance and quality components) have the same shape, so an NDF may either be regarded as a set of up to three matching N-dimensional arrays, or as an N-dimensional array of pixels each of which has a data (and optionally a variance and quality) value associated with it. In general, other non-array components may also be present, of course.
The usual notation can be used to refer to an NDF's shape. For instance:
describes the shape of a 3-dimensional NDF with pixel indices ranging from 0 to 255 in the first dimension, from -1 to 1 in the second dimension, and from 1 to 3 in the third dimension. The lower bound is taken to be 1 if not specified.
An NDF's pixel-index bounds and dimensionality may be determined from its identifier with the routine NDF_BOUND, as follows:
INTEGER NDIMX, LBND( NDIMX ), UBND( NDIMX ), NDIM
...
CALL NDF_BOUND( INDF, NDIMX, LBND, UBND, NDIM, STATUS )
Here, the integer arrays LBND and UBND are supplied to receive the lower and upper bounds of each dimension, and the number of dimensions is returned via the NDIM argument. The size of the LBND and UBND arrays is specified by the NDIMX argument and should normally be sufficiently large to ensure that all the NDF's bounds can be accommodated. The symbolic constant NDF__MXDIM (defined in the include file NDF_PAR) specifies the maximum number of dimensions which an NDF may have, and is often used when declaring the size of such arrays.
If the value of NDIMX is larger than the actual number of NDF dimensions, then any unused elements in the LBND and UBND arrays will be filled with the value 1. This allows an application to ``pretend'' that an NDF has more dimensions than it actually has, if that is convenient. For instance, suppose an application expects a 2-dimensional NDF and determines the pixel-index bounds as follows:
INTEGER LBND( 2 ), UBND( 2 ), NDIM
...
CALL NDF_BOUND( INDF, 2, LBND, UBND, NDIM, STATUS )
NDIM = 2
...
Although this application simply asserts that the NDF is 2-dimensional, it will nevertheless be able to handle 1-dimensional NDFs as well, because they will appear to the rest of the application as if their second dimension has pixel-index bounds (1:1).
Sometimes, this deception can also be practised if the NDF has more dimensions than expected. In this case, NDF_BOUND will return the expected number of pixel-index bounds and will discard the bounds information for any extra dimensions which are non-significant (i.e. for which the lower and upper bounds are equal). In the above example, the NDF would therefore appear 2-dimensional to the rest of the application. However, if any of the extra dimensions are significant (i.e. have unequal lower and upper bounds), then NDF_BOUND will report an error explaining the problem and return with its STATUS argument set to NDF__XSDIM (too many dimensions), as defined in the include file NDF_ERR. In the normal course of events, the application would then terminate and the error message would be delivered to the user.
The above simple program fragment will therefore ensure that an NDF is made to appear 2-dimensional if at all possible, and will correctly handle any difficulties which may arise.