Many G'MIC commands decide how to write an output pixel by accessing a neighborhood of input pixels, usually centered around the pixel in question. (See -convolve, -blur, -deriche). In principle, the neighborhood may be arbitrarily large, in practice it is a ball or sphere just a few pixels across.
All this is well and good so long as we deal with images of infinite extent, but computer manufacturers behave badly when asked to provide such capacity, so as a practical matter, images have both finite extent and, therefore, edges. Difficulties arise with edges. At some point, a part of a neigborhood won't exist because the pixels are off an edge. How does one access a pixel that is not there?
In the absence of data, one often reaches for policy. G'MIC commands which need to worry about boundaries generally sport a boundary parameter which specifies up to three possible policies:
|0||dirichlet||Off-border pixels are considered a constant black. Named for Peter Gustav Lejeune Dirichlet. In particular, see Dirichlet Boundary Condition.|
|1||neumann||The values of border pixels are presumed to extend infinity. Named for Carl Gottfried Neumann. In particular, see Neumann Boundary Condition.|
|2||cyclic||The right hand border wraps to the left, the top to the bottom, so that pixels on the opposite edge neighbor each other. The image is a torus. See Periodic Boundary Conditions.|
The flags 0, dirichlet, 1, neumann, and 2 cyclic are used consistently throughout G'MIC where the command in question performs some sort of operation entailing moving a kernel (a pixel and its neighborhood) over a surface, where it must, perforce eventually deal with edges and corners. These policies work well in some circumstances and poorly in others. There is no one 'right' approach; the choice usually depends on which set of limitations one can best live with. Many commands which operate on neighborhoods around input pixels do not fully implement the three policies; often the cyclic case is omitted.