The default prefix name for variables related to the ith input is im(i+1) (note the indexing from 1 to N, for N inputs). The user has the possibility to change this default behaviour by setting its own prefix.
In this document, we will keep the default convention. Following list summaries the available variables for input #0 (and so on for every input).
Variables | Description | Type |
im1 | a pixel from first input, made of n components/bands (first image is indexed by 1) | Vector |
im1bj | jth component of a pixel from first input (first band is indexed by 1) | Scalar |
im1bjNkxp | a neighbourhood (”N”) of pixels of the jth component from first input, of size kxp | Matrix |
im1bjMini | global statistic : minimum of the jth band from first input | Scalar |
im1bjMaxi | global statistic : maximum of the jth band from first input | Scalar |
im1bjMean | global statistic : mean of the jth band from first input | Scalar |
im1bjSum | global statistic : sum of the jth band from first input | Scalar |
im1bjVar | global statistic : variance of the jth band from first input | Scalar |
im1PhyX and im1PhyY | spacing of first input in X and Y directions | Scalar |
Moreover, we also have the generic variables idxX and idxY that represent the indices of the current pixel (scalars).
Always keep in mind that a pixel of an otb::VectorImage is always represented as a row vector inside the muParserX framework.
For instance, the following formula (addition of two pixels)
![]() | (4.6) |
is correct only if the two first inputs have the same number of bands. In addition, the following formula is not consistent even if im1 represents a pixel of an image made of only one band:
![]() | (4.7) |
A scalar can’t be added to a vector. The right formula is instead (one can notice the way that muParserX allows to define vectors on the fly):
![]() | (4.8) |
or
![]() | (4.9) |
if im1 is made of n components.
On the other hand, the variable im1b1 for instance is represented as a scalar; so we have the following different possibilities:
Expression | Status |
im1b1 + 1 | correct |
{im1b1} + {1} | correct |
im1b1 + {1} | incorrect |
{im1b1} + 1 | incorrect |
im1 + {im2b1,im2b2} | correct if im1 represents a pixel of two components (equivalent to im1 + im2) |
Similar remarks can be made for the multiplication/division; for instance, the following formula is incorrect:
![]() | (4.10) |
whereas this one is correct:
![]() | (4.11) |
or in more simple terms (and only if im2 contains two components):
![]() | (4.12) |
Concerning division, this operation is not originally defined between two vectors (see next section ”New operators and functions” -4.7.2-).
Actually, the different remarks above could have been summarized in a very simple manner: muParserX only addresses mathematically well-defined formulas.
Now, let’s go back to the first formula: this one specifies the addition of two images band to band. With muParserX lib, we can now define such operation with only one formula, instead of many formulas (as many as the number of bands). We call this new functionality the batch mode, which directly arises from the introduction of vectors within muParserX framework.
Finally, let’s say a few words about neighbourhood variables. These variables are defined for each particular input, and for each particular band. The two last numbers, kxp, indicate the size of the neighbourhood. All neighbourhoods are centred: this means that k and p can only be odd numbers. Moreover, k represents the dimension in the x direction (number of columns), and p the dimension in the y direction (number of rows). For instance, im1b3N3x5 represents the following neighbourhood:
. | . | . |
. | . | . |
. | . | . |
. | . | . |
. | . | . |
Fundamentally, a neighbourhood is represented as a matrix inside the muParserX framework; so the remark about mathematically well-defined formulas still stands.
Another last important remark is the following: the result of the evaluation of a formula can’t be a matrix, since it must be mapped to a itk::VariableLengthVector. So the result can only be: